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 
                 <draft-ietf-ngtrans-v4-over-mipv6-00.txt>
 
 
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]. 
    



  
<Tsirtsis, O'Neill, Corson>       1                                   
                          <IPv4 over MIPv6>          <January> <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: 
    
    
  
<Tsirtsis, O'Neill, Corson>                                          2 
                          <IPv4 over MIPv6>          <January> <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.  
  
<Tsirtsis, O'Neill, Corson>                                          3 
                          <IPv4 over MIPv6>          <January> <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), 
   <draft-ietf-ngtrans-dstm-03.txt>, October 2000, Work in Progress. 
    
   [SOL] H. Soliman, E. Nordmark, "Extensions to SIIT and DSTM for 
   enhanced routing of inbound packets", <draft-soliman-siit-dstm-
   00.txt>, July 2000, Work in Progress 
    
   [MIPV6] D. Johnson and C. Perkins, "Mobility Support in IPv6", 
   <draft-ietf-mobileip-ipv6-12.txt>, Work in progress. 
  
<Tsirtsis, O'Neill, Corson>                                          4 
                          <IPv4 over MIPv6>          <January> <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 
    

























  
<Tsirtsis, O'Neill, Corson>                                          5 
                          <IPv4 over MIPv6>          <January> <2001> 
 
 
   Copyright Notice 
    
                         Placeholder for ISOC copyright.