Network Working Group I. van Beijnum Internet-Draft IMDEA Networks Expires: January 14, 2010 July 13, 2009 Shim6 with IPv4 locators through 6to4 draft-van-beijnum-shim6-shim6to4-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 14, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract A limitation of Shim6 is that it only works with IPv6. With 6to4, it is possible for hosts that only have IPv4 connectivity to still enjoy Shim6's multihoming benefits. van Beijnum Expires January 14, 2010 [Page 1] Internet-Draft Shim6 with 6to4 July 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Basic operation . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Possible enhancements . . . . . . . . . . . . . . . . . . . . . 4 3.1. Source address dependent routing . . . . . . . . . . . . . 4 3.2. REAP address pair test order . . . . . . . . . . . . . . . 5 3.3. Tunnel optimization . . . . . . . . . . . . . . . . . . . . 5 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 5 5. Security considerations . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 6 Appendix B. Document and discussion information . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 van Beijnum Expires January 14, 2010 [Page 2] Internet-Draft Shim6 with 6to4 July 2009 1. Introduction There are two problems with extending Shim6 ([RFC5533]) to use IPv4. The first one is that there are insufficient IPv4 addresses to provide hosts with multiple IPv4 addresses as a matter of course. The second problem is that the HBA security mechanism [RFC5535] needs a 64-bit interface identifier, which obviously isn't available with IPv4. This document outlines how to use 6to4 tunneling ([RFC3056]) to make Shim6 available to hosts that only have IPv4 connectivity, or more generally, that have 6to4 IPv6 connectivity. The use of 6to4 resolves the HBA issue while maintaining the ability for every locator to be an identifier. Because multiple hosts can share the 6to4 connectivity provided by a single address (per ISP), it also somewhat addresses the IPv4 address scarcity issue. A downside of using 6to4 is that hosts must still be able to function as IPv6 hosts; IPv4-only hosts and/or IPv4-only applications can't use Shim6 over 6to4. 6to4 can be useful as a means to provide multihoming for IPv6 hosts that only have a single non-6to4 IPv6 address, as well as a mechanism that may be able work around ingress filtering issues in some cases. Note that it is equally possible that native IPv6 connectivity on the one hand and IPv4 connectivity and 6to4 IPv6 connectivity on the other hand share or not share single points of failure. A single point of failure common to all protocols will exist if a site only has a single connection to the internet. 2. Basic operation Basic operation is for a Shim6 host to generate HBA interface identifiers based on all the available IPv6 addresses, including any 6to4 addresses, and initiate and/or respond to Shim6 negotiations as per [RFC5533]. If the host has multiple instances of native IPv6 connectivity as well as 6to4 connectivity, it may either only publish two or more non-6to4 addresses in the DNS, or publish both types of addresses. By not publishing 6to4 addresses the situation where hosts that don't implement [RFC3484] connect across the public 6to4 gateways unnecessarily is avoided. (This can be from a non-6to4 address to a 6to4 address or the other way around.) The [RFC3484] policy table ensures that hosts implementing it prefer to connect in the following order: non-6to4 to non-6to4, 6to4 to 6to4, non-6to4 to 6to4. (However, IPv4 may be preferred either before or after non-6to4 to 6to4.) On the other hand, by publishing the 6to4 addresses in the van Beijnum Expires January 14, 2010 [Page 3] Internet-Draft Shim6 with 6to4 July 2009 DNS, a client has more opportunities to successfully connect to a server when there are connectivity problems. When Shim6 is negotiated, the 6to4 addresses are exchanged as usual, and when the primary address pair (the "identifiers") stop working, the 6to4 addresses will be tested by the REAP protocol ([RFC5534]) and subsequently used if they work. 3. Possible enhancements The following enhancements may allow for successful operation in a larger number of cases, or may improve performance. 3.1. Source address dependent routing In the situation where a host receives router advertisements containing different prefixes from different routers, the likelihood of packets successfully leaving the site can be increased by sending packets with a source address in the prefix advertised by a certain router to that router, and not to another router. (Assuming that both routers are valid default gateways and there are no more specific routes in the local routing table.) In the case where two or more routers advertise 6to4 subprefixes derived from different IPv4 addresses, sending packets towards the "correct" router has two advantages: 1. If the 6to4 router or a 6to4 gateway performs 6to4 sanity checking, it may reject packets with 6to4 source addresses that don't match the IPv4 source address in the outer header of the packet. With source address dependent routing this situation is avoided. 2. If one of the routers can't successfully transmit packets, for instance, because there is a problem in the IPv4 network between the 6to4 router and the 6to4 gateway or the remote 6to4 router, using source address dependent routing will select a different outgoing router when using a different source address. Without source address dependent routing, the host could use the router with broken connectivity exclusively and hence be unreachable. Source address dependent routing is a general purpose mechanism that can also be helpful with non-6to4 connectivity. It can also be applied if multiple addresses are configured manually, by matching a source address to a default gateway address. If multiple DHCPv6- derived addresses are present on the same interface, prefixes in router advertisements must be used to correlate the addresses with a van Beijnum Expires January 14, 2010 [Page 4] Internet-Draft Shim6 with 6to4 July 2009 router, as DHCPv6 doesn't provide the information necessary for this. With DHCPv6 on multiple interfaces the interface provides the correlation. If a host performs 6to4 tunneling locally, the source address dependent routing must extend to both the 6to4 tunneling (so that the IPv4 source address in the outer header matches the 6to4 IPv6 source address in the inner header) and IPv4 routing. Because IPv4 DHCP provides both an address and a default gateway address, there is no issue having multiple DHCP-derived IPv4 addresses on the same interface with regard to source address dependent routing, although typically, DHCP clients will not obtain multiple addresses on the same interface. 3.2. REAP address pair test order Although specific instances can easily be different, in general native IPv6 to native IPv6 or native IPv4 to native IPv4 are faster than native IPv6 to IPv6 tunneled over IPv4. This is especially true of 6to4, where often public gateways are used that are not geographically close to either the source or destination. Also, 6to4 packets are filtered or misrouted more often than native IPv6 packets. This problem doesn't exist in the case where the two hosts communicating both use 6to4. However, in that case, there is additional encapsulation overhead compared to the native IPv6 case. As such, the REAP protocol should test address pairs in the following order: 1. Native IPv6 to native IPv6 2. 6to4 to 6to4 3. Native IPv6 to 6to4 (or the other way around) 3.3. Tunnel optimization In the future, the Shim6 protocol may be extended to negotiate the ability to leave out the inner IPv6 header. I.e., only the IPv4 header and the Shim6 context tag would be present in data packets. However, the implications of such an optimization haven't been explored at this time. 4. IANA considerations None. van Beijnum Expires January 14, 2010 [Page 5] Internet-Draft Shim6 with 6to4 July 2009 5. Security considerations The security considerations are those relevant to 6to4 as noted in [RFC3056] itself as well as in the separate 6to4 security considerations document [RFC3964], the anycasting of public 6to4 gateways [RFC3068] and those relevant to Shim6: [RFC5533], [RFC5534] and [RFC5535]. 6. References [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001. [RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009. [RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", RFC 5534, June 2009. [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June 2009. Appendix A. Acknowledgements This draft is based on a discussion with Erik Nordmark. Brian Carpenter provided useful suggestions. Appendix B. Document and discussion information The latest version of this document will always be available at http://www.muada.com/drafts/. Please direct questions and comments to the Shim6 mailinglist or directly to the author. van Beijnum Expires January 14, 2010 [Page 6] Internet-Draft Shim6 with 6to4 July 2009 Author's Address Iljitsch van Beijnum IMDEA Networks Avda. del Mar Mediterraneo, 22 Leganes, Madrid 28918 Spain Email: iljitsch@muada.com van Beijnum Expires January 14, 2010 [Page 7]