Network Working Group I. van Beijnum Internet-Draft IMDEA Networks Expires: January 7, 2010 July 6, 2009 Shim6 with IPv4 locators through 6to4 draft-van-beijnum-shim6-shim6to4-00 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 7, 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 7, 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 . . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Appendix A. Document and discussion information . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 van Beijnum Expires January 7, 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. 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 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, van Beijnum Expires January 7, 2010 [Page 3] Internet-Draft Shim6 with 6to4 July 2009 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 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 van Beijnum Expires January 7, 2010 [Page 4] Internet-Draft Shim6 with 6to4 July 2009 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. 5. Security considerations None at this time. van Beijnum Expires January 7, 2010 [Page 5] Internet-Draft Shim6 with 6to4 July 2009 6. References [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [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. 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. 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 7, 2010 [Page 6]