INTERNET DRAFT P. Engelstad Telenor R&D Expires February 2002 August 14. 2001 IPv4 over 6to4 and 6to4 mobility. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft. 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 document is an individual submission for the NGTRANS Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ngtrans@sunroof.eng.sun.com mailing list. Abstract This draft outlines how a 6to4-enabled host can be provided with transparent IPv4 and IPv6 connectivity and mobility no matter if the host is located in a 6to4 network or is roaming an IPv4-only network. 1. Introduction 6to4, which is specified in [6to4], is one of the most powerful transition mechanisms we have today. It is designed to let IPv6 hosts in one 6to4-enabled IPv6 domain ("6to4-domain") communicate with other IPv6 hosts in other 6to4 domains. The IPv6 packets are tunneled Engelstad [Page 1] INTERNET DRAFT 6to4 v4v6 mobility by a 6to4-router over the IPv4 Internet to the 6to4 designated 6to4-router that is located on the border of the 6to4 domain where the recipient is located. The IPv4 address of the designated router is encoded into the prefix of the IPv6 address ("6to4 address"). Section 3 of this draft shows how a dual stack host can be reachable for incoming IPv4 traffic from anywhere on the IPv4 Internet and how it can send outgoing IPv4 traffic back to the IPv4 Internet, although it is located in a 6to4 domain. One definitely does not want to route such IPv4 communication inside the IPv6 domain based on the IPv4 addresses of the nodes in the domain: We do not want to import the well-known IPv4 routing table size problem into the IPv6 domain. Instead, we let IPv4 traffic be relayed by a home agent located in the IPv4 domain. This will solve this routing problem for the limited time of transitioning from IPv4 to IPv6. It is assumed that the obvious negative sides of this approach (e.g. single points of failure, non-optimal routing etc.) can be tolerated for the same limited period of time. All incoming traffic is relayed through a Dual Stack Mobility Agent ([DS-MIP]) that is enhanced with 6to4 capabilities. It takes advantage of the 6to4 infrastructure that already is in place and reaches the dual stack host by means of appropriate encapsulation. Section 4 demonstrates how a dual stack mobile node can get full, transparent, layer-3 mobility for both IPv4 traffic and IPv6 traffic by combining the mechanism in section 3 together with Mobile IPv6 (MIPv6). This mobility is offered no matter if the dual stack mobile node roams IPv4-only networks or 6to4 networks. [MOB-REQS] treats this problem in more detail. 2. Terminology TBD 3. IPv4 communication over 6to4 by means of a Dual Stack Home Agent The dual stack host uses a Dual Stack Mobility Agent (DSMA), specified in [DS-MIP], to accommodate IPv4 communication with any correspondent node on the IPv4 Internet. DSMA is located somewhere on the IPv4 Internet while the dual stack host is located in some 6to4 Engelstad [Page 2] INTERNET DRAFT 6to4 v4v6 mobility domain. To make this draft simple, we assume that the DSMA operates as an IPv4 home agent for the dual stack host, i.e. it receives un-tunneled IPv4 packets destined for a dual stack host's IPv4 home address that are sent from any correspondent IPv4 node on the IPv4 Internet. (How DSMA can operate as an IPv4 foreign agent is shown in [DS-MIP].) 3.1. IPv4-to-IPv6 bindings in the Address Translation List DSMA have an Address Translation List (ATL), which keeps a permanent fixed binding between the IPv4 home address and the IPv6 6to4 address of a dual stack host. The binding is used to reach the dual stack host in the 6to4 domain. (If the dual stack host implements Mobile IPv4 (MIPv4) it may register this binding dynamically and on the fly, using the MIPv4 registration mechanisms specified in [DS-MIP]. This may be required if the dual stack host does not have a permanent IPv4 address with DSMA and has to do IPv4 home address discovery as outlined in [DS- MIP]. Otherwise, the dual stack host is not required to implement MIPv4.) DSMA implements also a binding cache that contains IPv6 address mappings. It is updated by means of regular MIPv6 binding updates, as specified in [MIPv6]. 3.2. Packet forwarding DSMA uses the Address Translation List to forward IPv4 packets to the dual stack hosts, as explained in [DS-MIP]. The entry in the Address Translation List includes a binding between an IPv4 address and an IPv6 address and a binding type that indicates how the IPv4 packet shall be forwarded to the IPv6 address in the binding. This draft is concerned with the "6to4-binding type" ([DS-MIP]), The "6to4-binding type" mandates that when DSMA receives an IPv4 packet destined for the IPv4 home address of the host, it encapsulates the IPv4 packet in an IPv6 header using the 6to4 address found in the Address Translation List for that IPv4 home address. After the Address Translation List lookup, DSMA checks the IPv6 address registered in the Address Translation List with the MIPv6 binding cache: Engelstad [Page 3] INTERNET DRAFT 6to4 v4v6 mobility - If DSMA has an entry for the registered IPv6 address in the cache, DSMA will use the IPv6 care-of-address from the binding cache as the destination address, while the IPv6 address registered in the Address Translation List is put in the IPv6 Routing Header of the packet. This mechanism is explained in [MIPv6] and [IPv6]. - If DSMA has no binding cache entry for the IPv6 address, on the other hand, the destination address is the IPv6 address registered in the Address Translation List, and no IPv6 Routing Header is needed. Finally, when forwarding the resulting IPv6 packet, DSMA acts like any other 6to4 router: It encapsulates the 6to4 packet into the corresponding IPv4 header (i.e. the IPv4 destination address is derived from the 6to4 destination address). The resulting IPv4-in-IPv6-in-IPv4 packet is forwarded over the IPv4 Internet to the designated 6to4 router, which decapsulates it and forwards the resulting IPv4-in-IPv6 packet to the dual stack host. The host decapsulates the packet and hands the remaining IPv4 packet over to the IPv4 protocol stack. The architecture for incoming communication is illustrated below. +------------------------+ | IPv4 Internet | | | | +------------+ | +----+ | |6to4-enabled| <-- | <-|CNv4| | | DSMA | | +----+ | +------------+ | | | | | V | | +------------+ | | | 6to4 | | +-----+ designated +-----+ | | router | | | +------------+ | | | | | V | | +----+ | | |host| | | +----+ | | | | 6to4 enabled IPv6 | | Network | Engelstad [Page 4] INTERNET DRAFT 6to4 v4v6 mobility +------------------------+ Figure 1. The figure illustrates how incoming IPv4 traffic can be run over a 6to4-enabled DSMA to reach a dual stack host in a 6to4 network. This figure illustrates the case where DSMA operates as the MIPv4 home agent of the dual stack host. 3.4. Backward Tunneling The dual stack host may use any appropriate transition mechanism to get reverse (outgoing) IPv4 traffic back onto the IPv4 Internet from the 6to4 domain where it is located. However, if no such mechanisms are available, it may tunnel the IPv4 packets back to DSMA over the 6to4 domain and the IPv4 Internet. It encapsulates the IPv4 packet in an IPv6 header. The dual stack host forms a 6to4 address from DSMA's IPv4 agent address and uses this as the destination address of the IPv6 header. The lower 80 bits are set to an appropriate value - it depends on ongoing work in the NGTRANS working group. The packet will be encapsulated by a 6to4 router and forwarded over the IPv4 Internet to DSMA. The DSMA must be able to receive and recognize such packets. It decapsulates the packet and sends the packet into the IPv4 domain. We refer to this as "backward tunneling". If the inner IPv4 packet is not destined for DSMA itself, DSMA should check that DSMA has registered a binding for the IPv4 and IPv6 source addresses of the two inner IPv4 and IPv6 headers. If the packet passes the security check, DSMA chops off the outer IPv4 and IPv6 headers, and the inner IPv4 packet is injected into the IPv4 domain. 3.5. Route optimization When the dual stack host moves to a new 6to4 address, it sends a binding update to DSMA. It may use the same mechanism as for backward tunneling, but the inner IPv4 datagram is naturally not necessary. The binding update will change the binding cache, and ensure that the incoming IPv4 packets are forwarded to the new 6to4 address. 3.6. Location of 6to4-enabled DSMA Note that neither forward tunneling nor backward tunneling requires Engelstad [Page 5] INTERNET DRAFT 6to4 v4v6 mobility that DSMA have an IPv6 interface, although it must be capable of intercepting IPv6 headers and binding updates. Packets are received and sent on the IPv4 interface. Thus, our scheme allows DSMA to be located anywhere on the IPv4 Internet. (The IPv6 address of the internal IPv6 interface is the 6to4 address that is formed from the IPv4 agent address.) 3.7. A dual stack host that roams an IPv4-only network When a mobile dual stack host roams an IPv4-only network, it may still use the scheme described in this draft, although it does not implement Mobile IPv4: - It acquires an IPv4 care-of-address by some means that are outside the scope of this draft. - It forms a 6to4 care-of-address from the IPv4 care-of-address. - It sends a binding update that ensures that DSMA will forward incoming IPv4 packets to its IPv4 care-of-address. - The dual stack host decapsulates the IPv4-in-IPv6-in-IPv4 packets destined for itself. MIPv4 is naturally more efficient. Nevertheless, this scheme provides connectivity in cases where the mobile node does not implement MIPv4. 4. 6to4 Mobility As this section is concerned with mobility we will denote the dual stack host as the "mobile node". The mobile node can get full, transparent, layer-3 mobility for both IPv4 traffic and IPv6 traffic by combining the mechanism outlined above with Mobile IPv6 (MIPv6). This mobility is offered no matter if the dual stack mobile node roams IPv4-only networks or 6to4 networks. There are 4 cases to consider: 1) The mobile node wants IPv4 connectivity and roams a 6to4 network. This case was covered in section 3.1 through 3.6. 2) The mobile node wants IPv4 connectivity and roams an IPv4-only network. This case was covered in section 3.7. 3) The mobile node wants IPv6 connectivity and roams 6to4 networks. The mobile node simply gets the traffic forwarded by the MIPv6 home agent. Engelstad [Page 6] INTERNET DRAFT 6to4 v4v6 mobility 4) The mobile node wants IPv6 connectivity and roams IPv4-only networks. The solution to this is outlined below. Scenario 4 requires no protocols and no new changes to 6to4 or MIPv6. [DUALSTACK-MOVING], on the other hand, which uses a similar mechanism to solve the same problem, requires changes to the MIPv6 protocol: They require that traditional MIPv4 and MIPv6 home agents are dual stack and announce their IPv4 addresses in MIPv6 agent advertisements. We argue that it is better to keep existing mobility protocols unchanged, and let the transition-mobility problem be handled entirely by DSMA. DSMA does not require any changes to MIPv4 or MIPv6, although its own specification is based on code re-use from the existing MIPv4 specification. The remainder of section 4 shows how a dual stack mobile node can communicate by means of 6to4 and MIPv6, even while connected to IPv4-only networks. 4.1. Assumptions We assume that the mobile node implements Mobile IPv6 (MIPv6) and that the MIPv6 home agent has an IPv6 6to4 address (i.e. 6to4 is implemented in the home domain). The mobile node may acquire the 6to4 address of the home agent through regular MIPv6 agent advertisements. We also assume that the dual stack mobile node is able to encapsulate and decapsulate outgoing and incoming packets: While connected to IPv4-only networks, the mobile node operates as its own designated 6to4 router. 4.2. Registration of 6to4 address with Mobile IPv6 home agent The dual stack mobile node registers as follows: - When the mobile node connects to the IPv4-only network, it acquires an IPv4 care-of-address by some method that is outside the scope of this document. - The mobile node forms an IPv6 6to4 address from its IPv4 care- of-address. This 6to4 address is used as the mobile nodes IPv6 care-of-address. - The mobile node constructs a MIPv6 binding update with this IPv6 Engelstad [Page 7] INTERNET DRAFT 6to4 v4v6 mobility care-of-address. - The mobile node tunnels (IPv6-in-IPv4) the IPv6 binding update to the MIPv6 home agent. The IPv4 destination address of the outer header is extracted from the IPv6 6to4 address that is the agent address of the MIPv6 home agent. Thus, the binding update will be tunneled to the designated router in the home domain. - The designated router decapsulates the packet and sends it to the MIPv6 home agent. The mobile IPv6 home agent does not need to have any knowledge of the fact that the mobile node is not directly connected to a 6to4 domain. 4.3. Outgoing traffic to the 6to4 correspondent node In order to send outgoing traffic to the 6to4 correspondent node, the mobile node inspects the 6to4 address of the correspondent node. It extracts the IPv4 address of the designated router of the correspondent node from the correspondent node's 6to4 address. The mobile node tunnels (IPv6-in-IPv4) all packets to the designated router of the correspondent node. 4.4. Incoming traffic before route optimization The MIPv6 home agent will receive the incoming traffic from the correspondent node. It encapsulates the packets in a new IPv6 header that carries the 6to4 destination address of the mobile node. A 6to4 router in the 6to4 domain of the home agent will receive the packet, inspect the 6to4 destination address, and tunnel the packet over the IPv4 Internet to the mobile nodes IPv4 care-of-address, in line with the 6to4 specification. The mobile node must decapsulate the incoming IPv6-in-IPv6-in-IPv4 packet. 4.5. Incoming traffic after route optimization The mobile node performs route optimization by sending a MIPv6 binding update to the correspondent node. The correspondent node will thereafter send the packets directly to the new 6to4 address according to the MIPv6 specification. A 6to4 router in the domain where the correspondent node is located will receive the packet, and tunnel it over IPv4 directly to the mobile node. Engelstad [Page 8] INTERNET DRAFT 6to4 v4v6 mobility 5. Security Considerations The scheme presented in this document relies on the same security mechanisms that Mobile IPv4, Mobile IPv6 and 6to4 use. To our knowledge, it does not introduce new security exposures beyond these protocols. References [MIPv4] C.E. Perkins, "IP Mobility Support", IETF RFC 2002, October 1996. [MIPv6] D.B. Johnson and C.E. Perkins, "Mobility Support in IPv6", , March 2000, Work in Progress. [DUALSTACK-MOVING] s. Tsao, G. Tsirtsis, and W. Boehm, "Moving in a Dual Stack Internet", , July 2001, Work in Progress..br [6to4] B. Carpenter and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", IETF RFC 3056, February 2001. [DS-MIP] P. Engelstad, "Transitional Integration of Mobile IPv4 and Mobile IPv6", , August 2001, Work in Progress. [MOV-REQS] P. Engelstad, "Requirements to mobility while transitioning from IPv4 to IPv6", , August 2001, Work in Progress. Author's address Paal E. Engelstad Telenor R&D, Palo Alto 399 Sherman Ave. Suite #12 Palo Alto, CA 94306, USA Tel.: + 1-650- 714 7537 e-mail: paal@telenorisv.com Feel free to contact me directly on this e-mail address, or through NGTRANS WG's mailing list on ngtrans@sunroof.eng.sun.com, if you have comments or opinions regarding this draft. Your comments are welcome! Engelstad [Page 9]