One document matched: draft-tsirtsis-v4-over-mipv6-00.txt

Personal                                                    G. Tsirtsis
                                                             A. O'Neill
                                                                     BT
Internet Draft                                                S. Corson
Document: draft-tsirtsis-v4-over-mipv6-00.txt           Ansible Systems
Category: Informational                                     August 2000
Expires: February 2001

               IPv4 over Mobile IPv6 for Dual Stack nodes
                    draft-tsirtsis-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 either Tunneling or Protocol Translation
   [SIIT], [NAT-PT].

   [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.


<Tsirtsis, O'Neill, Corson>       1

                          <IPv4 over MIPv6>           <August> <2000>


   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 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:

   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.

<Tsirtsis, O'Neill, Corson>                                          2

                          <IPv4 over MIPv6>           <August> <2000>


   ==>   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 CCoA 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.

   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


<Tsirtsis, O'Neill, Corson>                                          3

                          <IPv4 over MIPv6>           <August> <2000>


   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. In
   [SOL] this problem is minimized due to the stateless nature of
   [SIIT].

   Finally, care needs to be taken so that the CCoA 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 CCoA can be handled as long as
   packets to this CCoA 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

   [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.

   [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






<Tsirtsis, O'Neill, Corson>                                          4

                          <IPv4 over MIPv6>           <August> <2000>



7. Acknowledgments

   This draft is based on [SOL] and offers an alternative to it.


Author's Addresses

   George Tsirtsis
   BT
   Phone: +44-20-88260073
   Email: george.tsirtsis@bt.com


   Alan O'Neill
   BT
   Phone: +44-20-88260073
   Email: alan.w.oneill@bt.com

   M. Scott Corson
   University of Maryland
   Ansible Systems
   (+1) 301-405-6630
    corson@isr.umd.edu




	                             Copyright Notice

	                      Placeholder for ISOC copyright.