NGTRANS WG                                                  G. Tsirtsis
                                                   Flarion Technologies
Internet Draft
Title:draft-ietf-ngtrans-6to4-DSTM-00.txt
Expires : June 2001                                        January 2001


                  Dual Stack deployment using DSTM and 6to4
                    <draft-ietf-ngtrans-6to4-dstm-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. 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

   It is desirable that most of IPv6 deployment is based on Dual Stack
   IPv4 and IPv6 nodes so that interoperability with the current IPv4
   based Internet be seamless. The 6to4 transition mechanism offers a
   automated mechanisms for addressing an IPv6 site as well as
   interconnectivity with other IPv6 sites when no native IPv6
   connectivity is available.[DSTM] provides a mechanism for dynamic
   IPv4 address allocation to Dual Stack nodes and a mechanism to send
   packets over a network that only supports IPv6 routing. By combining
   the two mechanisms we show how Dual Stack Intranets may be deployed
   with minimum need for IPv4 address space and no native IPv6
   connectivity.


INDEX

      1. Introduction
      2. Combining DSTM with 6to4
      3. Changes to DSTM and 6to4
      4. Conclusion
      5. Changes from v00 to v01


Tsirtsis                                                             1
Internet Draft         Combining 6to4 and DSTM           January 2001



. Introduction

   It is desirable that most of IPv6 deployment is based on Dual Stack
   IPv4 and IPv6 nodes so that interoperability with the current IPv4
   based Internet be seamless. The [6to4] transition mechanism offers a
   automated mechanisms for addressing an IPv6 site as well as
   interconnectivity with other IPv6 sites when no native IPv6
   connectivity is available. DSTM provides a mechanism for dynamic
   IPv4 address allocation to Dual Stack nodes and a mechanism to send
   packets over a network that only supports IPv6 routing. By combining
   the two mechanisms we show how Dual Stack Intranets may be deployed
   with minimum need for IPv4 address space and no native IPv6
   connectivity.

   No new protocol is defined in this document.


. Combining DSTM with 6to4

   DSTM defines that if IPv4 routing is not supported in the DSTM
   domain, IPv4 is tunnelled over IPv6 from the Dual Stack Node to the
   TEP which de-capsulates and forwards over IPv4 to external network.
   A small configuration problem is that TEP's address needs to be
   known in advance and DSTM extends DHCPv6 to provide this
   information.

   Imagine a domain that
   - has Dual Stack nodes.
   - only supports IPv6 Routing.
   - IPv6 addresses are allocated by 6to4.
   - IPv4 addresses are allocated by DSTM.

   In the example below, the following notation, borrowed from [DSTM]
   will be used:

     X    will designate an IPv6 host with a dual stack, X6 will be the
          IPv6 address of this host and X4 the IPv4 address
     Y    will designate a 6to4 border router at the boundary between
          an IPv6 DSTM/6to4 domain and an IPv4-only domain.
     Z    will designate an IPv4-only host and Z4 its address.
    ==>   means an IPv6 packet
    -->   means an IPv4 packet
    ++>   means a tunneled IPv4 packet is encapsulated in an IPv6
          packet
    ..>   means 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






Tsirtsis                                                             2
Internet Draft         Combining 6to4 and DSTM           January 2001


       DHCPv6
        DNS   6to4
    X6       Y6/Y4      Z4
    |          |          |
    |. . . . . . . .>  Z  | - X6 asks the DNS for an AAAA for "Z"
    |<. . . . . . . error | - the DNS answers with an error
    |. . . . . . . .>  Z  | - X6 asks for the A RR for "Z"
    |<. . . . . . . . Z4  | - the answer is Z4
    |          |          |
    |          |          | - The application sends its first IPv4
    |          |          |   packet which arrives to the DTI interface
    |          |          |   (If the application is compiled for IPv6
    |          |          |   this can be done through an IPv4-mapped
    |          |          |   address).
    |          |          |
    |          |          | - X6 needs an IPv4 address (first use)
    |====>     |          | - X6 queries the DHCPv6 server for an
    |          |          |   IPv4 address using DHCPv6
    |<====     |          | - The DHCPv6 server locates the client
    |          |          |   and provides a temporary IPv4
    |          |          |   global address.
    |+++++++++>|          | - The MN sends the IPv6 packet to the
    |          |          |   6to4 router 2002:6to4::
    |          |--------->| - Y sends the packet to the destination Z4
    |          |          | - Y caches the association between
    |          |          |   the IPv4 and IPv6 address of X.



   When an IPv6 node wants to talk to an IPv4 only node (e.g.:
   132.100.1.1) the following will happen according to DSTM:
   A DNS request for AAAA/A6 will return an error. This will trigger an
   A request, which will return the IPv4 address of the destination
   (say 132.100.1.1). The IPv6 node will use DHCPv6 to get a temporary
   IPv4 address (say 70.60.50.1). Now unlike DSTM, the packet can be
   immediately tunnelled to the 6to4 router of the site:

   Inner Source Address      = 70.60.50.1
   Inner Destination Address = 132.100.1.1
   Outer Source Address      = 2002:6to4::EUI1
   Outer Destination Address = 2002:132.100.1.1::

   The key is that a packet with Destination (2002:132.100.1.1::) in
   the 6to4 domain will naturally go straight to the 6to4 gateway of
   the domain.

   Now the 6to4 boarder router can recognize that the above destination
   address is not the normal "6to4 IPv6 address", which would require
   the low 64 bits to be populated. In this case instead of
   *en*capsulation the gateway needs to *de*capsulate and send the
   internal IPv4 packet to the IPv4 destination.



Tsirtsis                                                             3
Internet Draft         Combining 6to4 and DSTM           January 2001


   The 6to4 gateway will send the IPv4 packet:
   Source Address      = 70.60.50.1
   Destination Address = 132.100.1.1

   The gateway also needs to keep the mapping between 70.60.50.1 and
   2002:6to4::EUI1 (as DSTM does in TEP) so the returned packet can be
   encapsulated and sent back to the Dual Stack Node.

   On the returning path the 6to4 gateway will receive the following
   IPv4 packet:
   Source Address      = 132.100.1.1
   Destination Address = 70.60.50.1

   The 6to4 gateway recognises the IPv4 destination of 70.60.50.1 as
   the IPv6 destination 2002:6to4::EUI1 and sends it to it:

   Inner Source Address      = 132.100.1.1
   Inner Destination Address = 70.60.50.1
   Outer Source Address      = 2002:132.100.1.1::
   Outer Destination Address = 2002:6to4::EUI1


. Changes to DSTM and 6to4

   For the above mechanisms to work, the following needs to happen:
   - DSTM nodes with 6to4 addresses SHOULD encapsulate IPv4 packets
   into IPv6 packets using a destination address of the form of
   2002:Z4:: where Z4 is the IPv4 address of the IPv4 only destination
   - 6to4 gateways SHOULD recognise a packet with destination address
   of the form 2002:Z4:: (Interface ID = 0) as a packet containing an
   IPv4 packet and thus SHOULD de-capsulate and forward the packets to
   its IPv4 destination. The same realisation can come from the Next
   Header field of the IPv6 outer header.

. Conclusion

   We showed that combining DSTM with 6to4 one can provide a complete
   solution to an Intranet that would like to utilize the Dual Stack
   approach to migration but only has a few IPv4 addresses and no
   native connectivity to IPv6. The combination also provides a small
   improvement to the way the two transition mechanisms operate.

   What do you gain:
   - Combine TEP/6to4 gateway functions/boxes
   - Dual Stack nodes do no need to know the address of the TEP and
   thus no need to configure DHCP with it and no need to re-configure
   it in a renumbering event.







Tsirtsis                                                             4
Internet Draft         Combining 6to4 and DSTM           January 2001


. Changes

. References

   [DSTM], Jim Bound et.al, Dual Stack Transition Mechanism (DSTM),
   <draft-ietf-ngtrans-dstm-03.txt>, October 2000, Work in Progress.

   [6to4], B. Carpenter, K. Moore, Connection of IPv6 Domains via IPv4
   Clouds without Explicit Tunnels, <draft-ietf-ngtrans-6to4-07.txt>,
   September 2000, Work in Progress


Author's Address

      George Tsirtsis
      Flarion Technologies
      (+44) 020 88260073
      G.Tsirtsis@Flarion.com
      gtsirt@hotmail.com


Copyright Notice

     Placeholder for ISOC copyright.