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 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), , October 2000, Work in Progress. [6to4], B. Carpenter, K. Moore, Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels, , 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.