INTERNET DRAFT P. Engelstad Telenor R&D Expires 11 January 2002 11 July 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 Mobile IPv4 and Mobile IPv6 can work in conjunction to provide transparent L3 mobility to a dual stack mobile node. The mobile node is reachable and can communicate by means of both IPv4 and IPv6, even in situations where the mobile node is in reach of only either an IPv4 or an IPv6 network. The document demonstrates a modular way of running Mobile IPv4 on top Engelstad [Page 1] INTERNET DRAFT Transitional MIPv4v6 Integration of Mobile IPv6 by means of a Transition Agent. This is a dual stack translator that works between Mobile IPv4 and Mobile IPv6 home agents. It translates between MIPv4 and MIPv6 traffic. 1. Introduction When a dual stack mobile node (MN) roams between IPv4 and IPv6 networks, it may use the scheme described below to accommodate IPv4 mobility, reachability and communication, even when MN is in reach of only IPv6 networks. The problem of maintaining IPv4 communication while roaming IPv6 access networks has also been addressed by [IPv4-over-MIPv6] and [SIIT-DSTM]. These proposals, however, do not offer transparent IPv4 mobility, because incoming traffic destined for MN's IPv4 home address will not reach MN. They assume that MN initiate all communication. This draft, on the other hand, proposes to run MIPv4 on top of MIPv6 ("MIPv4-over-MIPv6") in such situations. To specify how MIPv4 and MIPv6 can be integrated (i.e. to run MIPv4-over-MIPv6) we introduce the Transition Agent (TA). It is basically a translator that translates between MIPv4 and MIPv6. When TA receives an IPv4-in-IPv4 packet (tunneled from the Mobile IPv4 home agent) on one interface, it replaces the encapsulating IPv4 header with an IPv6 header, and sends the resulting IPv4-in-IPv6 packet out on another interface (towards the Mobile IPv6 home agent). TA must have a binding cache to map an IPv4 home address to an IPv6 destination address. This scheme is described in section 5.2. TA may also be used for running MIPv4 over an IPv6 access network, circumventing MIPv6. This scheme is described in section 5.3. The concept of the Transition Agent (TA) is introduced to modularize the integration of MIPv4, MIPv6 and IPv4-to-IPv6 transition mechanisms. TA is a dual stack module that takes care of the translation between IPv4 and IPv6. It works independently of MIPv4 and MIPv6; one may plug it into or take it out of an existing MIP- enabled network without influencing the functionality of existing mobility agents (i.e. Mobile IP home agents and foreign agents). The existing mobility agents can be single stack nodes, as all dual stack functionality is located in TA. Running MIPv4-over-MIPv6 is only one way of integrating MIPv4 and MIPv6. By running MIPv6 on top of MIPv4 ("MIPv6-over-MIPv4"), on the other hand, one may accommodate IPv6 mobility, reachability and communication, even when MN is in reach of only IPv4 networks. This Engelstad [Page 2] INTERNET DRAFT Transitional MIPv4v6 Integration situation may be addressed in subsequent versions of this document. Note that how MIPv4 and MIPv6 is integrated inside MN, and how it works in conjunction here, is outside the scope of this draft. The idea of an address-mapper, which is outlined in [ADDRESS-MAPPER], might be applicable. Table of Content 1. Introduction 2. Terminology 3. Overview 4. Applicability 5. Deployment Scenarios 5.1. Home located TA 5.2. MIPv4-over-MIPv6 5.3. Foreign located TA 6. Future studies References Author's address 2. Terminology Transition Agent (TA): A dual stack node with a conceptual binding cache that is able to map IPv4 addresses to IPv6 addresses and vice versa. TA receives IPv4-in-IPv4 packets (which are tunneled from the MIPv4 home agent) on its IPv4 interface and forwards them as IPv4-in-IPv6 packets on its IPv6 interface, as specified in this draft. Home located Transition Agent (HTA): A transition agent that, in default configuration, relays traffic between a mobile nodes Mobile IPv4 home agent and its Mobile IPv6 home agents. Foreign located Transition Agent (FTA): A transition agent that, in default configuration, relays traffic from a Mobile IPv4 home agent, directly to a mobile node that is visiting an IPv6 network. Dual stack node: A node with both an IPv4 stack and an IPv6 stack. Other abbreviations that are introduced in this draft: MIPv4 Mobile IPv4, as specified in [MIPv4]. Engelstad [Page 3] INTERNET DRAFT Transitional MIPv4v6 Integration MIPv6 Mobile IPv6, as specified in [MIPv6]. MIP A MIPv4 or MIPv6 - interpretation depends on context. HAv4 A mobile IPv4 home agent, as specified in [MIPv4]. HAv6 A mobile IPv6 home agent, as specified in [MIPv6]. HA A HAv4 or HAv6 - interpretation depends on context. FA A mobile IPv4 foreign agent, as specified in [MIPv4]. CNv4 A correspondent node [MIPv4] communicating by an IPv4 stack. CNv6 A correspondent node [MIPv6] communicating by an IPv6 stack. CN A CNv4 or CNv6 - interpretation depends on context. MN A dual stack mobile node that implements both MIPv4 and MIPv6. 3. Overview A Transition Agent (TA) is a dual stack router that is located on the border between an IPv4 domain and an IPv6 domain. TA MAY work in conjunction with either Mobile IPv4 (MIPv4) or Mobile IPv6 (MIPv6) or both: - From the IPv4 side, TA is perceived as a MIPv4 Foreign Agent (FA) that behaves according to the MIPv4 specification in [MIPv4]. If MN wants to run MIPv4-over-MIPv6, for example, it uses TA's IPv4 interface address as the care-of-address when registering with HAv4. As a result, HAv4 tunnels IPv4 packets that are destined to MN to TA's IPv4 interface. - From the IPv6 side, TA is perceived as a MIPv6 Correspondent Node (CNv6) that behaves according to the MIPv6 specification in [MIPv6]. When running MIPv4-over-MIPv6, for example, TA sends IPv4-in-IPv6 packets to HAv6. HAv6 sees only the encapsulating IPv6 header and tunnels the packets to MN's IPv6 stack. Like any other Mobile IP agent, TA has a binding cache. In TA's case, this conceptual data structure binds an IPv4 address to an IPv6 address (and vice versa). The cache may also store other control information (e.g. flags, lifetime, etc) similar to that of other MIP agents. TA uses the cache to map IPv4-in-IPv4 headers to IPv4-in-IPv6 headers (and vice versa). If TA receives an IPv4-in-IPv4 packet that is destined for TA's IPv4 interface and that is encapsulated in line with [MIPv4], it MUST operate as follows: It uses the binding cache, and maps the IPv4 destination address of the inner header to a corresponding IPv6 destination address. It replaces the outer IPv4 header with an IPv6 header, and injects the IPv4-in-IPv6 packet into the IPv6 domain. The Engelstad [Page 4] INTERNET DRAFT Transitional MIPv4v6 Integration IPv6 source address is an IPv6 address of TA's own IPv6 interface. If TA is configured to run MIPv4-over-MIPv6, for example, it has a mapping between MN's IPv4 home address and MN's IPv6 home address. It decapsulates the IPv4-in-IPv4 packet, maps the inner IPv4 home address to MN's IPv6 home address, and tunnels the inner IPv4 packet towards MN via MN's IPv6 home agent. The IPv6 destination address of the IPv4-in-IPv6 packet that TA transmits, is MN's IPv6 home address. If TA receives an IPv6-in-IPv4 packet that is destined for TA's IPv6 interface, it SHOULD perform the inverse of the process above. That is, an IPv4-in-IPv6 address is recapsulated and forwarded to the IPv4 domain. Although the main functionality of TA is tunneling and forwarding, as explained above, TA has also other conceptual data structures that enable it to receive MIPv6 binding messages on its IPv6 interface, and respond to them like any other CNv6 should do, according to [MIPv6]. It should also be able to receive MIPv4 registration requests (or binding updates) and respond to them like any other FA should do, according to [MIPv4]. When HAv6 receives MIPv4-over-MIPv6 packets from TA, it sees only the IPv6 header. To achieve route optimization HAv6 is configured to sends a Binding Update to TA (just like it would do to every other CNv6 according to [MIPv6]) in order to make it update its cache. After TA has mapped the IPv4-in-IPv4 packet to an IPv4-in-IPv6 packet, it will use the routing header to tunnel the IPv4-in-IPv6 packets directly to MN in line with [MIPv6]. This kind of encapsulation will be more efficient, circumvent HAv6, and reduce overhead. In static mode of operation the bindings between the IPv4 address and the IPv6 address in the binding cache MAY be manually configured. If TA is configured to run MIPv4-over-MIPv6, for example, it has a fixed mapping between the MN's IPv4 home address and its IPv6 home address. In dynamic mode of operation, however, MN may set this binding on the fly. A special Binding Update message is required to enable this functionality, and a specification of this may be addressed in a later version of this draft. 4. Applicability This scheme shows its strength during the initial stage of communication: It offers transparent reachability to fixed IPv4 and IPv6 home addresses - just like Mobile IP does. However, it also Engelstad [Page 5] INTERNET DRAFT Transitional MIPv4v6 Integration introduces additional overhead, as well as potential bottlenecks and single points of failure - just like Mobile IP does. Therefore, route optimizations are required, and should be done during the initial stages of the communication session between MN and CN. After the route has been optimized, the flow of traffic may still use other transition mechanisms to reach the destination. Some transition mechanisms may prove to be very efficient, although they do not provide this level of transparent mobility, at least for incoming communication initiated by a correspondent node. In these cases the scheme presented here may be used in conjunction with these other transition mechanism, whenever that is possible. In the initial phase of communication, our scheme may be used, before the communication soon is "handed over", by means of route optimization, to (a node or a Tunnel End Point / Tunnel Server that implements) the other scheme. As an optional feature, TA may even be configured to work in conjunction with other transition mechanisms. That is, TA does not only help MIPv4 interact with MIPv6; it may also help MIPv4 and MIPv6 interact with other transition mechanisms in a modularized way. This work is for further studies. [MIPv4-over-6to4] gives an example of how TA can work in conjunction with [6to4]. 5. Deployment scenarios 5.1 Home located TA (HTA) A Home located TA (HTA) is a TA that forwards traffic between a MIPv4 Home Agent (HAv4) and a MIPv6 home agent (HAv6). Neither HAv4 nor HAv6 need be dual stack nodes, as all dual stack functionality is located in TA. This is shown in figure 1 below. Although both IPv4 and IPv6 interfaces of TA are specified, implementers may chose to locate two, or three of the units together. This is shown in figures 2 - 4 below. If two or three units are located on the same dual stack node, implementers MAY not implement the interfaces (that will be) specified in this draft, but the external interfaces MUST comply with the specifications. In those cases, specifications that apply to internal interfaces are more like guidelines to making the merged modules work. Engelstad [Page 6] INTERNET DRAFT Transitional MIPv4v6 Integration +--------+ +--------+ +--------+ +--------+ | IPv4 | | IPv4 | | IPv4 | | IPv4 | | Domain | | Domain | | Domain | | Domain | | +----+ | | | | +----+ | | | | |HAv4| | | | | |HAv4| | | | | +----+ | | | | +----+ | | | | | | | +----+ | | | | | +----+ | | V | | |HAv4| | | V | | |HAv4| | | +----+ | | +----+ | | +----+ | | +----+ | +-+-TA-+-+ +-+-TA-+-+ +-+-TA-+-+ +-+-TA-+-+ | +----+ | | +----+ | | +----+ | | +----+ | | | | | | | | |HAv6| | | |HAv6| | | V | | V | | +----+ | | +----+ | | +----+ | | +----+ | | | | | | |HAv6| | | |HAv6| | | | | | | +----+ | | +----+ | | | | | | IPv6 | | IPv6 | | IPv6 | | IPv6 | | Domain | | Domain | | Domain | | Domain | +--------+ +--------+ +--------+ +--------+ Figure 1. Figure 2. Figure 3. Figure 4. (No co- (HAv4, TA (HAv6, TA (All co- location) co-located) co-located) located) Locating TA in the same administrative domain (or on the same node) as HAv4 has naturally the advantage that a private IPv4 address (or an internal interface address) MAY be used on TA's IPv4 interface. TA will not require a globally routable IPv4 address from the already strained IPv4 address space. Co-location is naturally also a means of reducing the number of single points of failure. However, this may not always be possible. A user may have been provided with a HAv4 on the IPv4 network of her workplace, while an UMTS operator (or whatever) has provided her with a HAv6. This may certainly be located in the operator's domain. She is confined to at least two single points of failure (as shown in figure 1 - 3). For clarity and generality, no co-location is assumed in the following. 5.2. MIPv4-over-MIPv6 HFA MAY be a tool to run MIPv4-over-MIPv6. Its binding cache stores bindings between MN's IPv4 and IPv6 home addresses. The IPv4-in-IPv4 traffic from HAv4 is re-capsulated at TA. The IPv4-in-IPv6 traffic is Engelstad [Page 7] INTERNET DRAFT Transitional MIPv4v6 Integration encapsulated again at HAv6 and sent to MN. MN decapsulates the IPv6 header. Pure IPv6 and MIPv6 traffic is handed to the IPv6 protocol stack, while the IPv4 stack receives decapsulated IPv4 traffic. IPv4 and IPv6 communication can be maintained independently. Moreover, 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. How MIPv4-over-MIPv6 is envisioned to work, is shown in figure 5 below. +------------------------+ | | | Internet | | | | +----+ | +----+ | |HAv4| <----- | <-|CNv4| | +----+ | +----+ +-----------------+ | | | | V | | | +----+ | | IPv6 +---------+-TA-+---------+ | (Access) | +----+ | +---------+ | | | | |MIPv4 <- | | | V | +-------|-+ | | +----+ | +----+ |MIPv6 <--|<- | <---------- | <----- |HAv6| <----- | <-|CNv6| +---------+ | | +----+ | +----+ | | | | | IPv6 | +---------------- + Internet | | | +------------------------+ Figure 5. MIPv4-over-MIPv6, before route optimization. For simplicity, the figure shows only incoming traffic. MIPv6 works transparently to MIPv4. From MIPv4's point of view the MIPv6 tunnel is a fixed connection. 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. The dual stack MN may use any transition mechanism at hand to get reverse (outgoing) traffic onto the IPv4 Internet. [IPv4-over-6to4-anycast] is an example of such a mechanism. If no such mechanisms are available, MN may, if possible, tunnel the packet Engelstad [Page 8] INTERNET DRAFT Transitional MIPv4v6 Integration back to HTA (IPv4-in-IPv6). HTA SHOULD decapsulate it and send it into the IPv4 domain. MIPv4 Registration Messages and Binding Updates are sent like any other IPv4 traffic. When MN is in reach of an IPv4 access network, CN is naturally the primary target of route optimization and HA is a secondary target. Otherwise, HTA may be a target for IPv6 Binding Updates from MN or HAv6. 5.3. Foreign located TA (FTA) Another deployment scenario is to let a TA serve MNs that visit the IP domain where the TA is located. In this scenario, the deployment resembles that of IPv4 FAs, although TA SHOULD NOT send agent advertisements like other FAs do. MN is confined to other means of finding TA's IPv6-address, and IPv4 care-of-address. MN may use an address acquisition method that resembles that of Dual Stack Transition Mechanism (DSTM), which is specified in [DSTM]. A separate option value in the DHCPv4 requests and replies should indicate that the addresses refer to those of a FTA. FTA's IPv4 address (i.e. which corresponds to MNs' IPv4 CoAs) may be encoded as an IPv4-compatible-IPv6 address in such messages. MN registers with FTA by means of an IPv6 message carrying a Binding Update option. The inner IPv4 packet may carry an IPv4 Registration Request (or Binding Update) that is destined for the HAv4. 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, FTA allows all visiting MNs to use the same IPv4 address (CoA). It is the MN's IPv4 home address (in the incoming encapsulated IPv4 packet) that determines the corresponding IPv6 address (CoA) of the visiting MN. 6. Further studies - The exact details of the scheme presented must be worked out. - TA is designed to shield MIPv4 and MIPv6 implementations from the details of IPv4-to-IPv6 transition. Ability to interpret and utilize different transition mechanism at hand or in reach, could also be added as optional functionality of TA. Understanding of other transition mechanisms may improve this scheme's efficiency in terms of facilitating more sound hand-over (route optimization) decisions and improving forwarding performance. This is for further study. Engelstad [Page 9] INTERNET DRAFT Transitional MIPv4v6 Integration - TA MAY be configured to map IPv6-in-IPv6 packets to IPv6-in-IPv4 packets, so that we may run MIPv6-over-MIPv4, instead of the opposite. To make this draft simple and comprehensible, we have not focused on this yet. Such functionality may be embedded into this draft at a later stage. 7. Security Considerations Our scheme implements the same security mechanisms that Mobile IP does. The IPv6 part of a HTA, for example, should share a security association with MN or HAv6, like a CNv6 in [MIPv6]. The IPv4 side of HTA should share a security association with MN or HAv4, like a FA in [MIPv4]. Often it will be as easy to distribute an IPsec "security association" (or keys) between MN and HTA, as it is between MN and its HAs. This makes binding updates and registrations directed at HTA easy to implement without any Public Key Infrastructure (PKI) in place. References [MIPV4] Charles E. Perkins, "IP Mobility Support", IETF RFC 2002, October 1996. [MIPv6] David B. Johnson and Charles E. Perkins, "Mobility Support in IPv6", , March 2000, 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. [IPv4-over-MIPv6] G. Tsirtsis, A. O'Neill and S. Corson, "IPv4 over Mobile IPv6 for Dual Stack nodes", , January 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", , February 2000, Work in Progress. [DSTM] Jim Bound et.al, "Dual Stack Transition Mechanism (DSTM)", Engelstad [Page 10] INTERNET DRAFT Transitional MIPv4v6 Integration , July 2001, Work in Progress. [MIPv4-over-6to4] P. Engelstad, "Mobile IPv4 over 6to4", , July 2001, Work in Progress. [6to4] B. Carpenter and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", IETF RFC 3056, February 2001 [IPv4-over-6to4-anycast] P. Engelstad, "IPv4 over 6to4 anycast", , July 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. Copyright Notice Engelstad [Page 11]