INTERNET DRAFT P. Engelstad Telenor R&D Expires February 9. 2002 August 9. 2001 Transitional Integration of Mobile IPv4 and Mobile IPv6. 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 dual stack mobile node can be reached and communicate by means of both IPv4 and IPv6, even in situations where the mobile node is in reach of only either IPv4 or IPv6 networks. A Dual Stack Mobility Agent accommodates mobility and translates between IPv4 and IPv6 traffic. It may operate as a mobility agent in its own right or as a module that relays traffic between existing single stack Mobile IPv4 and Mobile IPv6 home agents. 1. Introduction When a dual stack mobile node roams IPv4 and IPv6 networks, it may Engelstad [Page 1] INTERNET DRAFT Dual Stack Mobile IP use a Dual Stack Mobility Agent to accommodate IPv4 connectivity and mobility, even while in reach of only IPv6 networks. The problem of maintaining IPv4 communication while roaming IPv6 access networks has also been addressed by [SIIT-DSTM] and [NGTRANS- MOVING]. The former of these proposals, however, do not offer transparent IPv4 mobility, because incoming traffic destined for a mobile node's IPv4 home address will not reach it. The latter is only restricted to DSTM ([DSTM]) and requires changes to the Mobile IPv4 and Mobile IPv6 protocols, although transition mechanisms will be used (hopefully) for only a limited period of time. The Dual Stack Mobility Agent that is defined in this draft, on the other hand, provides full transparent layer3 mobility and IPv4 connectivity while roaming IPv6 access networks, without requiring any changes to existing protocols. A mobile node uses an IPv4 home address (or care-of-address) with a network prefix that assures that the Dual Stack Mobility Agent can receive it. The agent keeps a binding between the IPv4 home address and an IPv6 address that can be used to reach the mobile nodes in the IPv6 domain. It receives un-tunneled IPv4 packets destined for a mobile node's IPv4 home address (or tunneled IPv4-in-IPv4 packets destined for the mobile node's IPv4 care-of-address). The Dual Stack Mobility Agent tunnels the (inner) IPv4 packets to the IPv6 address in the binding. The mobile node can set the address bindings in the Dual Stack Mobility Agent dynamically and on the fly. To register a binding with the agent, it uses nearly the same registration messages and registration procedures as for Mobile IPv4. The mobile node adds an "IPv6 Address Extension", which is specified in section 5 of this draft, to the Mobile IPv4 Registration Request. The Dual Stack Mobility Agent can either relay traffic between existing single stack home agents, or it can operate as a mobility agent in its own right. The Dual Stack Mobility Agent, like any other mobility agent, shows its strength during the initial stage of communication: It offers transparent connectivity to fixed IPv4 and IPv6 home addresses - just like Mobile IP does. However, it also introduces additional overhead, as well as potential bottlenecks and single points of failure (like also Mobile IP does). Thus, it might be favorable to perform Route Optimizations during the initial stages of the communication session. The communication may be "handed over" to another transition mechanism - preferably one that is stateless and efficient. Engelstad [Page 2] INTERNET DRAFT Dual Stack Mobile IP The Dual Stack Mobility Agent modularizes the integration of Mobile IPv4 and Mobile IPv6. One may plug it into or take it out of a Mobile-IP-enabled network without influencing the functionality of existing mobility agents. It may also shield the single stack Mobile IP agents from all knowledge of dual stack functionality and of existing transition mechanisms. All such functionality is located in the Dual Stack Mobility Agent without adding additional requirements to existing IPv4 or IPv6 mobility agents. Note that this draft focuses on how to ensure IPv4 connectivity when the mobile node is attached to only IPv6 networks. Maintaining IPv6 connectivity while only in reach of IPv4 networks, on the other hand, is not yet treated. This requires that the Dual Stack Mobility Agent perform IPv6-to-IPv4 address mapping, which may be embedded into this draft at a later stage. Table of Content 1. Introduction .............................................. 1 2. Terminology ............................................... 3 3. Overview .................................................. 4 3.1. DSFA located in the home domain ......................... 4 3.2. DSHA located in the home domain ......................... 6 3.3. DSFA located in the visited domain ...................... 7 4. Dual Stack Mobility Agent Functionality ................... 7 4.1. Address Translation List (ATL)........................... 8 4.2. DSMA Packet Forwarding .................................. 9 4.3. ATL Registrations ....................................... 9 4.4. DSMA Backward tunneling ................................. 10 4.5. DSMA Reverse tunneling .................................. 12 4.6. DSMA Discovery .......................................... 12 4.7. DSMA Capability Discovery ............................... 13 5. New message extensions .................................... 13 6. Correspondent Node Functionality .......................... 14 7. Mobile Node Functionality ................................. 14 8. Security Issues ........................................... 15 9. IANA considerations ....................................... 15 References ..................................................... 16 Author's address ............................................... 16 APPENDICES: A. DSFA Functionality ........................................ 17 A.1. DSFA Registration ....................................... 17 A.2. DSFA Packet Forwarding .................................. 18 B. DSHA Functionality ........................................ 19 B.1. DSHA Registration ....................................... 19 B.2. DSHA Packet Forwarding .................................. 20 Engelstad [Page 3] INTERNET DRAFT Dual Stack Mobile IP 2. Terminology This draft uses the same terminology as introduced in [MIPv4] and [MIPv6]. In addition the following terms are defined: Dual Stack Mobility Agent (DSMA): A dual stack node with a conceptual Address Translation List (ATL) that is able to map IPv4 addresses to IPv6 addresses. DSMA receives IPv4 packets from an IPv4 correspondent node or IPv4-in-IPv4 packets from the Mobile IPv4 home agent of a mobile node. DSMA tunnels the packets to the IPv6 address that the mobile node has registered in the Address Translation List. ("Transition Agent" was chosen as an alternative name for DSMA in the first version of this draft.) Dual Stack Home Agent (DSHA): A Dual Stack Mobility Agent that acts as the IPv4 home agent of the mobile node. It receives un-tunneled IPv4 packets destined the IPv4 home address of the mobile node. DSHA tunnels the packets to the IPv6 (home or care-of-) address that the mobile node has registered with DSHA. Dual Stack Foreign Agent (DSFA): A Dual Stack Mobility Agent that acts as an IPv4 foreign agent of the mobile node. It receives IPv4-in-IPv4 packets tunneled to the IPv4 care-of-address that DSFA has provided the mobile node with. DSFA decapsulates the packet and tunnels the inner packet to the IPv6 (home or care-of-) address that the mobile node has registered with DSFA. Address Translation List (ATL): A conceptual data structure that contains bindings between IPv4 and IPv6 addresses. The following acronyms are used in this draft: DSMA Dual Stack Mobility Agent. DSHA Dual Stack Home Agent DSFA Dual Stack Foreign Agent ATL Address Translation List. MIPv4 Mobile IPv4 ([MIPv4]). MIPv6 Mobile IPv6 ([MIPv6]). HAv4 IPv4 Home Agent ([MIPv4]). HAv6 IPv6 Home Agent ([MIPv6]). CNv4 MIPv4 Correspondent Node (Communicates by IPv4.) CNv6 MIPv6 Correspondent Node (Communicates by IPv6.) MN Mobile Node (Dual stack node, implements MIPv4 and MIPv6). Engelstad [Page 4] INTERNET DRAFT Dual Stack Mobile IP 3. Overview 3.1. DSFA located in the home domain The Dual Stack Mobility Agent (DSMA) may be situated in the home domain of a mobile node (MN). In that case the MN probably has been configured with the knowledge of the DSMA; it knows its IP addresses and capabilities, and there are mobility/binding security associations established between MN and DSMA. A DSMA located in MN's home domain may - from IPv4's point of view - serve as MN's foreign agent, i.e. it operates as a Dual Stack Foreign Agent (DSFA). MN has already a single stack Mobile IPv4 home agent (HAv4) located in the home domain and wants to use DSFA as a means to reach MN even in situations where MN is in reach of only IPv6 networks. MN binds its IPv4 home address to its IPv6 address, and registers the IPv4 care-of-address that is associated with DSFA's IPv4 interface with HAv4. HAv4 tunnels the packet to DSFA, which decapsulates it and tunnels the inner IPv4 packet towards MN's IPv6 stack. MN may register either its IPv6 home address or its IPv6 care-of- address with DSFA. In the former case, MN may use an existing Mobile IPv6 home agent (HAv6) to ensure connectivity and mobility while away from its IPv6 home network. In the latter case, the IPv4 packets are tunneled directly to MN's IPv6 care-of-address. Mobile IPv4 (MIPv4) is run on top of Mobile IPv6 (MIPv6), so to speak. How this is envisioned to work, is shown in figure 1 below. +------------------------+ | IPv4 Internet | | | | +----+ | +----+ | |HAv4| <----- | <-|CNv4| | +----+ | +----+ +-----------------+ | | | | V | | | +----+ | | IPv6 +---------+DSFA+---------+ MN |(Visited network)| +----+ | +---------+ | | (a) / | (b) | |MIPv4 <- | | | / V | +-------|-+ | | / +----+ | + - -+ |MIPv6 <--|<- | <---------- | <----- |HAv6| <- - - | <-|CNv6| +---------+ | | +----+ | +- - + +---------------- + | Engelstad [Page 5] INTERNET DRAFT Dual Stack Mobile IP | IPv6 Internet | +------------------------+ Figure 1. DSFA: A Dual Stack Mobility Agent that operates as a foreign agent. Incoming traffic from CNv4 is forwarded towards MN. (a): Traffic is sent directly to MN's IPv6 care-of-address. (b): Traffic is sent via MN's IPv6 home agent. (IPv6 communication with CNv6 is simultaneously maintained.) 3.2. DSHA located in the home domain MN may also use a DSMA located in its home domain as an IPv4 home agent, i.e. DSMA operates as a Dual Stack Home Agent (DSHA). In that case DSHA receives IPv4 packets destined for MN's IPv4 home address directly from CNv4. It tunnels the packets to the IPv6 (home or care- of-) address that MN has registered with DSHA. How this is envisioned to work, is shown in figure 2 below. +------------------------+ | IPv4 Internet | | | +----+ +-----------------+ |---------- | <-|CNv4| | | V | +----+ | | +----+ | | IPv6 +---------+DSHA+---------+ MN |(Visited network)| +----+ | +---------+ | | (a) / | (b) | |MIPv4 <- | | | / V | +-------|-+ | | / +----+ | + - -+ |MIPv6 <--|<- | <---------- | <----- |HAv6| <- - - | <-|CNv6| +---------+ | | +----+ | +- - + +---------------- + | | IPv6 Internet | +------------------------+ Figure 2. DSHA: A Dual Stack Mobility Agent that operates as an IPv4 home agent. Incoming traffic from CNv4 is forwarded towards MN. (a): Traffic is sent directly to MN's IPv6 care-of-address. (b): Traffic is sent via MN's IPv6 home agent. (IPv6 communication with CNv6 is simultaneously maintained.) Many MNs do not need a permanent IPv4 address, because they need not be permanently reachable for incoming IPv4 traffic initiated by other Engelstad [Page 6] INTERNET DRAFT Dual Stack Mobile IP nodes on the Internet. Due to the scarcity of IPv4 addresses it is desirable to let these MNs acquire IPv4 addresses dynamically. Thus, if MN has no fixed IPv4 home address, but is configured with a security association with the DSHA, it may use home address discovery [HADDR-DISC] to get an IPv4 home address assigned by DSHA for the limited period of time that it is needed. 3.3. DSFA located in the visited domain MN may also use a DSFA in the visited domain, to play the role as a MIPv4 foreign agent. The mechanisms that MN uses to discover DSMAs in visited domains are beyond the scope of this draft. How a DSMA can serve as a foreign agent in the visited domain is shown in figure 3 below. +------------------------+ | IPv4 Internet | +-----------------+ | | IPv6 | | MN |(Visited network)| | +---------+ | | | |MIPv4 <- | | | | +-------|-+ | +--+--+ +----+ | +----+ |MIPv6 <--|<- | <--------- |DSFA | <---- |HAv4| <---- | <-|CNv4| +---------+ | +--+--+ +----+ | +----+ +---------------- + | | | +------------------------+ Figure 3. The mobile node uses the Dual Stack Mobility Agent as a foreign agent. Traffic from CNv4 is forwarded towards MN. While some other transition mechanisms (e.g. DSTM) tend to allocate a separate IPv4 address to each user that wants to have traffic relayed through the border node, DSFA allows all visiting MNs to share the same IPv4 care-of-address. It is the MN's IPv4 home address in the incoming decapsulated IPv4 packet (i.e. in the inner IPv4 header) that determines the corresponding IPv6 care-of-address of the visiting MN. 4. Dual Stack Mobility Agent functionality DSMA is a dual stack router that is located on the border between an Engelstad [Page 7] INTERNET DRAFT Dual Stack Mobile IP IPv4 domain and an IPv6 domain. Seen from the IPv4 side, DSMA behaves like a MIPv4 Mobility Agent. If it plays the role as a Foreign Agent, it receives IPv4-in-IPv4 packet that are tunneled from the Mobile IPv4 home agent, destined for the IPv4 care-of-address that DSMA has provided MN with. DSMA decapsulates the packet and tunnels the inner IPv4 packet to the IPv6 address that MN has registered with it. If it plays the role as a MIPv4 Home Agent it receives (un-tunneled) IPv4 packets directly from the IPv4 correspondent node (CNv4), which it tunnels to the IPv6 address that MN has registered with it DSMA's main conceptual data structure is the Address Translation List (ATL), which binds an IPv4 address to an IPv6 address and stores other control information associated with the binding. DSMA uses the bindings to tunnel the IPv4 packets to the IPv6 address that MN has registered in the ATL. From the IPv6 side, DSMA is perceived as any other IPv6 Correspondent Node (CNv6) that behaves according to the MIPv6 specification ([MIPv6]). Thus, when for example a HAv6 receives IPv4-in-IPv6 packets, it is only concerned with the encapsulating IPv6 header. The packets are tunneled to MN's IPv6 stack in line with the specifications in [MIPv6]. Like any other CNv6, DSMA has a MIPv6 binding cache associated with its IPv6 interface, and it may receive MIPv6 binding updates on this interface, too. Thus, packets may be route optimized and forwarded directly to MN, circumventing the IPv6 address that MN has registered in ATL. The MIPv6 binding cache can naturally be implemented as part of the ATL. 4.1. The Address Translation List (ATL) The Address Translation List (ATL) is comparable with a Mobile IPv4 binding cache. It binds an IPv4 address to an IPv6 address and stores other control information associated with the binding including flags, lifetime and binding types. The binding type determines how the IPv4 packets shall be forwarded towards the IPv6 address that MN has registered in ATL. An entry in ATL includes: - MN's registered IPv4 address - MN's registered IPv6 address - Binding type (indicating how IPv4 packets shall be forwarded to the registered IPv6 address) - Identification field from MIPv4 registration Engelstad [Page 8] INTERNET DRAFT Dual Stack Mobile IP - Remaining lifetime of current or pending registration - A bit that indicates if DSMA serves as a home agent or foreign agent for MN - Other flags (S,D,T,G,M, etc.) DSFAs should also include: - Home agent address - UDP source port (for pending registrations) - Requested registration lifetime (for pending registrations) 4.2. DSMA Packet Forwarding Both DSFA and DSHA use the ATL to forward the IPv4 packets to MN. (DSFA, however, must decapsulate the incoming IPv4-in-IPv4 packets first, while DSHA receives un-tunneled packets directly from CNv4.) The binding type mandates how IPv4 packets that DSMA receives will be forwarded towards MN. For example: - If the binding is of Binding Type 1 (section 5), the IPv4 packet is encapsulated in an IPv6 header and forwarded towards MN. Other binding types may be defined at a later stage. After the ATL lookup, DSMA checks the IPv6 address registered in the ATL with the MIPv6 binding cache: - 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 ATL 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 ATL, and no IPv6 Routing Header needs to be used. (DSMA may be configured with filters to prevent routing loops and infinitely nested tunnels.) 4.3. ATL Registrations If MN wants to configure the IPv4-to-IPv6 address binding in DSMA's ATL on the fly, there are two different scenarios to consider: 1) MN has already a MIPv4 home agent and wants to use DSMA as a DSFA, Engelstad [Page 9] INTERNET DRAFT Dual Stack Mobile IP i.e. as a foreign agent that receives IPv4-in-IPv4 packets. 2) MN wants to use DSMA as a DSHA, i.e. as an IPv4 home agent that receives IPv4 packets directly from CNv4. In both cases MN may use MIPv4 registration messages [MIPv4] with the "IPv6 Address Extension" defined in section 5. The extension contains the IPv6 delivery address that DSMA is requested to bind to MN's IPv4 address. MN may use backward tunneling (section 4.4) to tunnel the requests over IPv6 to DSMA's IPv6 interface. 4.3.1 Case 1: DSFA Registration If MN registers with DSFA (case 1 above) it adds the "IPv6 Address Extension" (section 5) as a non-authenticating Mobile-Foreign extension. DSFA examines the extension and acts as a MIPv4 foreign agent: - If the registration request cannot be accepted it sends a negative Registration Reply back to MN (tunneled over IPv6). - If it can accept the request, it notes the relevant information in a pending registration record, chops off the Mobile-Foreign Extensions and relays the remaining standard MIPv4 Registration Request to HAv4. This registration procedure is treated in more detail in appendix A of this draft. Unless otherwise stated in this document, the registration procedure is as specified in [MIPv4]. 4.3.2 Case 2: DSHA Registration If MN registers with DSHA (case 2 above) it adds the "IPv6 Address Extension" (section 5) as a non-authenticating Mobile-Home extension. DSHA examines the extension and acts as a MIPv4 home agent: - If the registration request cannot be accepted it sends a negative Registration Reply back to MN (tunneled over IPv6). - If it can accept the request, it sends a positive Registration Reply back to MN (tunneled over IPv6). This registration procedure is treated in more detail in appendix B of this draft. Unless otherwise stated in this document, the registration procedure is as specified in [MIPv4]. Engelstad [Page 10] INTERNET DRAFT Dual Stack Mobile IP 4.4. Backward Tunneling MN may use any appropriate transition mechanism ([NGTRANS-MECH]) to get reverse (outgoing) IPv4 traffic onto the IPv4 Internet. If no such mechanisms are available, MN may tunnel the IPv4 packets back to DSMA over the IPv6 domain. DSMA decapsulates the packet and sends the packet into the IPv4 domain. We refer to this as "backward tunneling". All DSMAs must support backward tunneling. This ensures that a MN is able to send IPv4 packets into the IPv4 domain even in situations where it is only directly attached to IPv6 networks (- assuming that the visited IPv6 network and the DSMA are interconnected by an IPv6 internet). How backward tunneling is envisioned to work, is shown in figure 4 below. +------------------------+ | IPv4 Internet | | | +----+ +-----------------+ >---------> | <-|CNv4| | | | | +----+ | | +----+ | | IPv6 +---------+DSMA+---------+ MN |(Visited network)| +----+ | +---------+ | | ^ | |MIPv4 >- | | | | | +-------|-+ | | | | |MIPv6 >--|-> | ----------> | --------->| | +---------+ | | | +---------------- + | | IPv6 Internet | +------------------------+ Figure 4. Backward tunneling of outgoing IPv4 traffic from MN. MN uses DSMA to reach a CNv4. If the inner packet is not destined for DSMA itself, DSMA should check that it has registered a binding for the IPv4 and IPv6 source addresses of the tunneled packet. DSMA must take into account that MN's actual IPv4 home address may be placed in the IPv6 Home Address Option instead of in the IPv6 source address as explained in [MIPv6]. DSMA may also let IPv4 multicast addresses pass as IPv4 source addresses. DSMA may require AH authentication. When MN sends MIPv4 registration messages to DSMA in order to update Engelstad [Page 11] INTERNET DRAFT Dual Stack Mobile IP a binding in ATL, it may tunnel the messages over IPv6. After decapsulation, DSMA will push the registration message in the inner IPv4 packet up the protocol stack in the same way that it will do with un-tunneled registration messages. Normally the destination address of the IPv4 header in the registration request is DSMA's own IPv4 agent address, and the source address is MN's IPv4 home address. However, when MN tunnels the registration message to DSMA, it may use the "All-mobility-Agent" Multicast Address as the IPv4 destination address. MN may use the unspecified 0.0.0.0-address as a source address in tunneled requests if MN performs home address discovery [HADDR-DISC] and has not yet received its IPv4 home address. Note that the IPv6 headers of any of the backward-tunneled packets may contain MIPv6 Binding Updates that may update entries in the MIPv6 binding cache of DSMA. (One may consider DSMA as an IPv4 mobility agent that uses the entire IPv6 Internet as its L2 link, and delivers IPv4 packets to MNs over this link. In this model backward tunneling corresponds to using DSMA as MN's default router.) 4.5. DSMA Reverse Tunneling Reverse Tunneling [REVERSE-TUN] lets packets be tunneled back to the IPv4 home agent, which decapsulates the packet and sends the inner IPv4 packet onto the Internet. For a DSHA, Reverse Tunneling is the same as backward tunneling (above). If MN requests Reverse Tunneling from an DSFA, on the other hand, backward tunneled packets that have been decapsulated are re-tunneled back to the home agent, instead of being sent onto the IPv4 Internet from DSFA's own IPv4 interface. DSMAs should support reverse tunneling. 4.6. DSMA Discovery DSMA discovery is for further study. DSMAs may for example broadcast some special MIP Agent Advertisements on home networks, and other places DSMAs may be discovered by other mechanisms such as DHCP. Dual Stack Transition Mechanism [DSTM] Engelstad [Page 12] INTERNET DRAFT Dual Stack Mobile IP includes an example of such an address acquisition method. Many MNs, however, will probably not need to discover the DSMA. They have been configured with a list of one or more DSMAs; it knows their IPv6 addresses and maybe also their capabilities. 4.7. DSMA Capability Discovery If MN knows the IPv6 agent address of a DSMA but not its IPv4 agent address, it may tunnel a MIPv4 Registration Request to DSMA with the Home Agent Address field containing the "All-Mobility-Agent" multicast address. DSMAs must respond to such a request by tunneling back to MN a negative Registration Reply (code 133) that contains the agent address. If MN knows the IPv6 and IPv4 agent addresses of a DSMA but not its capabilities or care-of-address(es), it may tunnel an Agent Solicitation containing an "IPv6 Address Extension" (section 5) to DSMA. DSMA responds by tunneling a MIPv4 Agent Advertisement containing an "IPv6 Address Extension" (section 5) back to MN. (The details of this are for further study.) If MN has a network address identifier (NAI), knows the IPv6 and IPv4 addresses of a DSMA that may serve as a home agent (DSHA), and has Mobile-Home Security Association with this DSMA, it may use the mechanism described inn [HADDR-DISC] to discover its own home address. In the remaining of this draft we assume that MN knows DSMA's IP addresses and its capabilities. MN may have been configured with a specific DSMA or acquired the information by other means. 5. New message extensions MIPv4 registration requests that are directed at DSMA in order to set an IPv4-to-IPv6 binding MUST include the "IPv6 Address Extension" defined in this document. It has the following format: IPv6 Address Extension: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Binding Type | (reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address | Engelstad [Page 13] INTERNET DRAFT Dual Stack Mobile IP + + | | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD. The extension type must be given a number between 0 and 127 to ensure that a recipient that does not understand the extension silently discards the registration message. Length: 20 Binding Type: Indicates how DSMA shall forward IPV4 packets towards MN's IPv6 address. The first bit from the left denotes binding type 1, the second bit from the left denotes binding type 2 and so forth: - Binding Type 0: Unspecified. - Binding Type 1: IPv4 packets are delivered by means of standard IPv4-in-IPv6 encapsulation. IPv6 address: The IPv6 (home or care-of-) address that MN wants to bind to its IPv4 address in DSMA's ATL. If DSMA is requested to act as a home agent (DSHA), the extension is added as a mobile-home non-authentication extension, and the IPv4 home agent address in the Registration Request is DSMA's own agent address. If the registration message requests the DSMA to act as a foreign agent (DSFA), the extension is added as a mobile-foreign non- authentication extension, and the IPv4 home agent address in the Registration Request is not DSMA's own agent address. TBD: New registration reply codes (if necessary). 6. Correspondent Node Functionality Correspondent nodes are unaffected by the scheme specified in this draft, although they may be affected by the requirements in [MIPv4] and [MIPv6]. 7. Mobile Node Functionality Engelstad [Page 14] INTERNET DRAFT Dual Stack Mobile IP IPv4 and IPv6 communication can be maintained independently: IPv4-in- IPv6 packets destined for MN are decapsulated and the inner IPv4 is handed over to the IPv4 protocol stack, while pure IPv6 and MIPv6 traffic, on the other hand, is handed to the IPv6 protocol stack. Therefore, the MIPv4 module can chose between MIPv4-over-MIPv6 and pure MIPv4 connectivity, depending on the IP-version(s) run on the network(s) in reach. MIPv6 works more or less transparently to MIPv4. When running MIPv4-over-MIPv6, for example, the MIPv6 tunnel is perceived as a fixed connection from MIPv4's point of view. The MIPv4 module does not need to worry about agent detection, acquisition of IPv4 care-of- addresses, FA registrations, HA registrations, binding updates and so forth. Mobility is entirely handled by MIPv6. Note that the details of how MIPv4 and MIPv6 is integrated inside MN, and how it works in conjunction here, is beyond the scope of this draft. The idea of an address-mapper, which was outlined in [ADDRESS- MAPPER], might be applicable. 8. Security Issues Our scheme implements the same security mechanisms that Mobile IP does. The IPv6 part of a DSMA, for example, should share a security association with MN or HAv6, like a CNv6 in [MIPv6]. The IPv4 side of DSMA should share a security association with MN or HAv4, like a FA in [MIPv4]. Often it will be as easy to distribute a "mobility security association" or "binding security association" between MN and DSMA, as it is between MN and its home agents. This makes binding updates and registrations directed at DSMA easy to implement without any Public Key Infrastructure (PKI) in place. The schemes outlined in this draft are based on extensive use of tunneling. Secure tunneling, including requirements for IPsec AH for reverse tunneling, may be addressed in subsequent versions of the document. 9. IANA Considerations TBD Engelstad [Page 15] INTERNET DRAFT Dual Stack Mobile IP 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. [NGTRANS-MOVING] s. Tsao, G. Tsirtsis, and W. Boehm, "Moving in a Dual Stack Internet", < draft-ietf-ngtrans-moving-00.txt>, July 2001, Work in Progress. [SIIT-DSTM] H. Soliman, E. Nordmark, "Extensions to SIIT and DSTM for enhanced routing of inbound packets", , July 2000, Work in Progress. [NGTRANS-MECH] W. Biemolt et. al., "An overview of the introduction of IPv6 in the Internet", July 2001, Work in Progress. [REVERSE-TUN] G. Montenegro (ed.), "Reverse Tunneling for Mobile IP, revised", IETF RFC 3024, January 2001. [DSTM] J. Bound et.al, "Dual Stack Transition Mechanism (DSTM)", , July 2001, Work in Progress. [ADDRESS-MAPPER] S. Tsao, J. Liu and W. Boehm, " Mobility Support for IPv4 and IPv6 Interconnected Networks based on Dual-Stack Model ", , March 2001, Work in Progress. [6to4] B. Carpenter and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", IETF RFC 3056, February 2001 [HADDR-DISC] P. Calhoun and C.E. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", IETF RFC 2794, January 2000. 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 Engelstad [Page 16] INTERNET DRAFT Dual Stack Mobile IP NGTRANS WG's mailing list on ngtrans@sunroof.eng.sun.com, if you have comments or opinions regarding this draft. Your comments are welcome! APPENDIX: A. DSFA Functionality A.1. DSFA Registration MN may use MIPv4 registration messages [MIPv4] with extensions defined in this draft to configure on the fly the IPv4-to-IPv6 address binding in DSFA's ATL. Unless otherwise stated in this document, the registration procedure is as specified in [MIPv4]. Upon reception of the request DSFA acts as follows: - It will note that it is requested to act as a foreign agent (i.e. a DSFA). - DSFA performs the Mobile-Foreign Authentication. - It processes the "IPv6 Address Extension" and other non- authentication Mobile-Foreign extensions. - DSFA prepares to bind MN's IPv4 home address (in the home address field of the registration request) to MN's IPv6 address (in the IPv6 address extension). I.e. it notes down all relevant information from the request message in a pending registration record. (No actual changes are done in the ATL before it receives a successful registration reply from HAv4.) - It chops off the "IPv6 Address Extension" and other Mobile-Foreign extensions and forwards the remaining Mobile-Home part of the registration request to MN's HAv4. If DSFA receives a successful registration reply from HAv4, it will use the noted information to update the ATL. The registration reply is forwarded back to MN, using the forwarding mechanism that the binding in ATL mandates. All other fields in the registration request have the same values and meaning as in MIPv4. However, the scheme in this draft may add further requirements. The MIPv4 registration request takes the following form: Type: 1 (Registration Request) S: MN can set the bit freely as it concerns only home agent behavior. Engelstad [Page 17] INTERNET DRAFT Dual Stack Mobile IP DSFA will ignore the value of this bit. B: MN can set the bit freely as it concerns only home agent behavior. DSFA will ignore the value of this bit. D: Not set. This ensures that broadcast and multicast packets (if requested by MN) will be encapsulated in an IPv4 header carrying MN's IPv4 home address before they are tunneled to DSFA. Otherwise, DSFA would not have a chance to know where to send these packets. M: Only set if MN knows that DSFA supports Minimal encapsulation. Alternatively, DSFA will always accept the mandatory IP-in-IP encapsulation. G: Only set if MN knows that DSFA supports GRE encapsulation. Alternatively, DSFA will always accept the mandatory IP-in-IP encapsulation. r: Value and meaning determined by [MIPv4]. T: Set if MN requests Reverse Tunneling, i.e. backward tunneled packets from MN are re-tunneled back to home agent. If un-set, on the other hand, backward-tunneled packets are injected directly into the IPv4 domain at DSFA. x: Value and meaning determined by [MIPv4]. Lifetime: Registration lifetime in seconds in line with [MIPv4]. Home Address: The IPv4 home address that the mobile node registers in the ATL. Home Agent: The IPv4 address of the mobile node's home agent. (This must not be an address of DSFA's own interfaces.) Care-of Address: The IPv4 care-of-address that DSFA provides MN with. Identification: A 64-bit number that is used in line with [MIPv4]. Extensions: The registration request must include the "IPv6 Address Extension" that is defined in section 5. The extension is added as a Mobile-Foreign non-Authentication Extension ([MIPv4]). It contains the IPv6 (home or care-of-) address that MN wants to register in ATL. It also contains a binding type, which mandates how IPv4 packets must be tunneled to reach the IPv6 address. MN may tunnel the request over DSFA's IPv6 interface. The registration reply from HAv6 has the same format as in [MIPv4] and is processed in line with [MIPv4]. DSFA relays tunnels the reply to MN. (TBD: Should the also reply from DSFA to MN contain the IPv6 Address Extension?) A.2. DSFA Packet Forwarding If DSFA receives an IPv4-in-IPv4 packet that is destined for DSFA's IPv4 care-of-address(es), it should decapsulate the packet. DSFA uses the destination address of the inner IPv4 packet and the bindings in the address translation list (ATL) to forward the packet. If ATL Engelstad [Page 18] INTERNET DRAFT Dual Stack Mobile IP contains a valid binding for that IPv4 destination address, and the entry shows that this DSMA is registered to serve as a DSFA for MN, information in the ATL entry determines how the packet shall be forwarded. (Normally the IPv4 packet will be tunneled to the IPv6 address specified in the binding.) Note that DSFA may be able to intercept different IPV4 encapsulation formats including Minimal Encapsulation and GRE Encapsulation in addition to the mandatory IP in IP encapsulation. In this draft we use IPv4-in-IPv4 as a generic term for all the encapsulation formats received by DSFA, unless explicitly stated. Tunneled packets that cannot be forwarded should be silently discarded. B. DSHA Functionality B.1. DSHA Registration MNs may use MIPv4 registration messages [MIPv4] with the "IPv6 Address Extension" defined in this draft to configure on the fly the IPv4-to-IPv6 address binding in DSHA's ATL. Upon reception of the registration request, DSHA acts as follows: - It will note that it is requested to act as an IPv4 home agent (i.e. a DSHA). - DSHA performs Mobile-Home Authentication. - It processes the "IPv6 Address Extension" and other non- authentication Mobile-Foreign extensions. - If the home address field is zero, DSHA dynamically allocates an IPv4 home address to MN, in line with [HADDR-DISC]. - If the request is accepted, DSHA binds MN's IPv4 home address to MN's IPv6 address (in the IPv6 Address Extension). It adds an entry in the address translation list. - DSHA generates a MIPv4 registration reply, in line with [MIPv4]. - It encapsulates the registration reply in an IPv6 header according to the ATL binding, and tunnels the reply to MN. Unless otherwise stated in this document, the registration procedure is as specified in [MIPv4]. The MIPv4 registration request takes the following form: Type: 1 (Registration Request) S: May be set if MN knows DSHA supports Simultaneous Bindings. Engelstad [Page 19] INTERNET DRAFT Dual Stack Mobile IP B: May be set if MN knows that DSHA supports forwarding of broadcasted diagrams. D: May only be set if MN is capable of accepting broadcast and multicast packets (if requested by MN) that are tunneled to MN's IPv6 address (without first have been encapsulated by an IPv4 packet that carries MN's IPv4 home address). M: Not set. G: Not set. r: Value and meaning determined by [MIPv4]. T: Should be set. Ignored by DSHA, because it must support backward tunneling anyway. (Backward and reverse tunneling are the same as far as DSHAs are concerned). x: Value and meaning determined by [MIPv4]. Lifetime: Registration lifetime in seconds in line with [MIPv4]. Home Address: MN's IPv4 home address if DSHA has already allocated this address to MN. Otherwise, it may be set to zero to ask DSHA to allocate an IPv4 home address, which it will add to the home address field of the registration reply. The IPv4 address is IPv4 address that is registered in ATL. Home Agent: The IPv4 address of DSHA. Care-of Address: Set to zero. The IPv6 care-of-address is found in the "IPv6 Address Extension" (below). Identification: A 64-bit number that is used in line with [MIPv4]. Extensions: The registration request must include the "IPv6 Address Extension" that is defined in section 5. The extension contains the IPv6 (home or care-of-) address that MN wants to register in ATL. The extension is added as a mobile-home non-authentication extension. The registration reply from DSHA has the same format as in [MIPv4] and is tunneled to MN. (TBD: Should the reply from DSHA to MN contain the IPv6 Address Extension?) B.2. DSHA Packet Forwarding A DSMA that serves as a home agent (DSHA) must examine the IPv4 destination address of all arriving packets to check if it is equal to the home address of any of the MNs that are registered with it. Information in the ATL entry determines how the packet shall be forwarded on behalf of a MN. (Normally the IPv4 packet will be tunneled to the IPv6 address specified in the binding.) If DSHA is not a virtual network ([MIPv4]), MN may request forwarding of broadcast packets. If DSHA is a multicast router, MN may request forwarding of multicast packets. If the D bit is set DSHA will tunnel broadcast and multicast packets directly to MN's IPv6 delivery address. Otherwise, DSMA first encapsulates broadcast and multicast Engelstad [Page 20] INTERNET DRAFT Dual Stack Mobile IP packets, using in an IPv4 header that carries MN's IPv4 home address, before they are tunneled over IPv6 to MN. Engelstad [Page 21]