Internet DRAFT - draft-ietf-ngtrans-6to4-dstm

draft-ietf-ngtrans-6to4-dstm




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 
 
 
    
1. 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.  
    
    
2. 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 
 
    
3. 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. 
    
4. 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 
 
 
5. Changes  
    
6. 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.