NGTRANS WG G. Tsirtsis A. O'Neill S. Corson Internet Draft Flarion Technologies Document: draft-ietf-ngtrans-v4-over-mipv6-00.txt Category: Informational January 2001 Expires: June 2001 IPv4 over Mobile IPv6 for Dual Stack nodes Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Abstract In this document we show how IPv4 based communications can be supported by a dual stack mobile node that only supports Mobile IPv6 (MIPv6). The aim is to use MIPv6 for mobility services while the Mobile can still use its dual stack capabilities for IPv4 communications without the need for translation. 1. Introduction Mobile IP (MIP) is capable of offering mobile services to terminals. Faced with IPv4 address shortage and other shortcomings of Mobile IPv4, a lot of work is now focused on the more functional Mobile IPv6. This, however, creates a number of problems for migration and interoperability, potentially forcing IPv6 Only deployment and consequently, heavy use of Tunneling and/or Protocol Translation [SIIT], [NAT-PT]. 1 <2001> [SOL] combines [DSTM] and [SIIT] to allow IPv6 only nodes to communicate with IPv4 only nodes and provides some support for Mobile Nodes in the same domain. In this document we present mechanisms to be used for support of IPv4 based communication with a dual stack mobile node (IPv4v6) that only supports Mobile IPv6 (MIPv6), rather than both MIPv4 and MIPv6. The aim is to use MIPv6 for mobility services whilst allowing the Mobile to use its dual stack capabilities for legacy IPv4 communications without requiring translation or MIPv4 deployment. 2. Dual Stack Mobile Node Imagine a Dual Stack Mobile Node (MN) that only supports MIPv6 and not MIPv4. While stationary and at home the MN does not use its MIPv6 capabilities and thus looks like a regular Dual Stack node. In an environment like that one of the most appealing interoperability mechanisms proposed by the NGTRANS WG is called [DSTM]. DSTM allows a dual stack node to use DHCPv6 to configure on demand its IPv4 stack. This offers high utilization of IPv4 address space and no requirements for IPv4 support in the domain. Additionally, while the Node has an IPv4 address, it can communicate with IPv4 only nodes without the use of Protocol Translators and/or Address Translators. DSTM has been mainly designed for stationary dual stack nodes. We will now examine how a MN can take advantage of DSTM in a mobile environment. It is clear that if the MN is not moving, DSTM can be directly applicable i.e.: the MN can use DHCPv6 over MIPv6 to communicate with the DSTM server in the home network and request an IPv4 address. The problem is that while MIPv6 can "move" the mobile's IPv6 stack between access points in the network, it is not obvious how it can move the IPv4 stack of the same MN. 3. Tunneling IPv4 in IPv6 [DSTM] assumes that IPv4 routing is not available in the DSTM domain. The Dynamic Tunneling Interface (DTI)_is defined as an interface that encapsulates IPv4 packets into IPv6 packets. The Tunnel End Point (TEP) is also defined as the destination of the IPv6 packet containing an IPv4 packet. Providing the MN node knows were the TEP is, in the domain it happens to be in, it can use MIPv6 to send an encapsulated IPv4 packet to the IPv4 CN. So, lets see how a Dual Stack MN would use DSTM and MIPv6 to initiate an IPv4 based communication. The examples below are borrowed from [DSTM] and modified for our purpose. Similar notation is also used: 2 <2001> MN will designate an IPv6 host with a dual stack, MN6 will be the IPv6 address of this host and MN4 its IPv4 address. TEP will designate the Dual Stack Tunnel End Point of the network. CN will designate an IPv4-only host and CN4 its address. ==> means an IPv6 packet --> an IPv4 packet ++> a tunneled IPv4 packet that is encapsulated in an IPv6 packet ..> a DNS query or response. The path taken by this packet does not matter in the examples. "a" means the DNS name of a host DNS DHCPv6 MN6 TEP CN4 | | | |. . .> Z | | - MN6 asks DNS for an A6 for "CN4" |<. . .error | | - the DNS answers with an error |. . .> Z | | - MN6 asks for the A RR for "CN4" |<. . . Z4 | | - the answer is CN4 | | | | | | | | | - MN6 needs an IPv4 address. |=================> | - MN6 requests from the local DHCPv6 | | | server an IPv4 address |<================= | - The DHCPv6 server replies to the MN | | | providing temporarily an IPv4 | | | address and the TEP address. |+++++++++++>| | - The MN sends the IPv6 packet to the | | | TEP using its Home Address | |----------->| - The TEP sends the packet to CN4 MN6 essentially uses its MIPv6 Care Of Address (COA) in the foreign domain to request an IPv4 address (and the local TEP) from the local DHCPv6 server. It then uses MIPv6 to communicate with the local TEP and encapsulate IPv4 packets destined to external IPv4 only nodes. Even if MN6 moves to a new Access Router in this domain, a BU to the TEP will allow the IPv6 tunnel and the IPv4 packets it encapsulates to be maintained. Note that like [SOL] the level of IPv6 connectivity offered by the above combination is very similar to MIPv4 without route optimization since the IPv4 address used is in fact a dynamically allocated IPv4 Home Address. Also like [SOL], MIPv6 Route optimization is of course used for the path between the MN and the TEP in that domain. It might also be possible for the MN to use the Home DHCPv6 server when in a foreign domain e.g: if the foreign domain does not support DHCPv6. This would require DHCPv6 request to be sent through the Home Agent of the MN. The reply would then include an IPv4 address and a TEP address from the home domain. Data would have to be sent from the MN to the HA to the TEP and eventually to the CN. 3 <2001> Note that no new protocol or change to any protocol is implied in this draft. We just show how MIPv6 can be combined with DSTM to give basic IPv4 based communication capability to a Dual Stack MN which only supports MIPv6. 4. Comparison with [SOL] The main advantage of this approach is that no translation is used for IPv4 communications. [SOL] uses translation for IPv4 communications. The main disadvantage of this approach is that all IPv4 communications will have to go over one or more TEP boxes that are single points of failure for the IPv4 sessions they support at any one time. In [SOL] this problem is minimized due to the stateless nature of [SIIT]. Finally, care needs to be taken so that the COA the MN uses to request an IPv4 address from the DHCPv6 server, does not expire before the DHCPv6 server manages to allocate the IPv4 address. Movement and thus deprecation of the COA can be handled as long as packets to this COA still reach the MN. [MIPv6] provides mechanisms to allow that. In this draft we do not consider incoming sessions (from IPv4 only nodes outside the IPv6 domain). This is because the [DSTM] specification does not support that functionality but only as a future work item. If and when such mechanisms are developed, they are likely to apply in this draft too. 5. Security Considerations The same as those define in [MIPv6] and [DSTM] 6. References [DSTM], Jim Bound et.al, Dual Stack Transition Mechanism (DSTM), , October 2000, Work in Progress. [SOL] H. Soliman, E. Nordmark, "Extensions to SIIT and DSTM for enhanced routing of inbound packets", , July 2000, Work in Progress [MIPV6] D. Johnson and C. Perkins, "Mobility Support in IPv6", , Work in progress. 4 <2001> [SIIT] E. Nordmark, "Stateless IP/ICMP Translation Algorithm", RFC2765, February 2000. [NAT-PT] G. Tsirtsis, P. Shrisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC2766, February 2000. 7. Acknowledgments This draft is based on [SOL] and offers an alternative to it. Author's Addresses George Tsirtsis Flarion Technologies Phone: +44-20-88260073 Email: G.Tsirtsis@Flarion.com Alan O'Neill Flarion Technologies Scott Corson Flarion Technologies 5 <2001> Copyright Notice Placeholder for ISOC copyright.