INTERNET-DRAFT Jim Bound NGTRANS Working Group Hewlett Packard Expires December 2002 Dual Stack Transition Mechanism (DSTM) Overview 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. To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Bound Expires December 2002 [Page 1] INTERNET-DRAFT draft-ietf-ngtrans-dstm-overview-00.txt June 2002 Abstract The initial deployment of IPv6 will require a tightly coupled use of IPv4 addresses to support the interoperation of IPv6 and IPv4 within an IPv6-only Network. Nodes will still need to communicate with IPv4 nodes that do not have a dual IP layer supporting both IPv4 and IPv6. The Dual Stack Transition Mechanism (DSTM) is based on the use of IPv4-over-IPv6 tunnels to carry IPv4 traffic within an IPv6-only network and provides a method to allocate a temporary IPv4 Address to IPv6/IPv4 nodes. DSTM is also a way to avoid the use of Network Address Translation for early adopter IPv6 deployment. Table of Contents: 1. Introduction .......................................... 3 2. DSTM Overview and Assumptions ......................... 4 3. DSTM Deployment Example ............................... 5 4.1 DSTM Client/Server Example ........................... 6 5. Implementation State and Other IETF work using DSTM .... 7 6. Applicability Statement ............................... 8 7. Security Considerations ............................... 9 Acknowledgments .......................................... 9 References ............................................... 9 Authors' Address ......................................... 9 Bound Expires December 2002 [Page 2] INTERNET-DRAFT draft-ietf-ngtrans-dstm-overview-00.txt June 2002 1. Introduction The initial deployment of IPv6 will require a tightly coupled use of IPv4 addresses to support the interoperation of IPv6 and IPv4 within an IPv6-only Network. Nodes will still need to communicate with IPv4 nodes that do not have a dual IP layer supporting both IPv4 and IPv6. The Dual Stack Transition Mechanism (DSTM) is based on the use of IPv4-over-IPv6 tunnels to carry IPv4 traffic within an IPv6-only network and provides a method to allocate a temporary IPv4 Address to IPv6/IPv4 nodes. DSTM is also a way to avoid the use of Network Address Translation for early adopter IPv6 deployment. DSTM is targeted to help the interoperation of IPv6 newly deployed networks with existing IPv4 networks. Since the IPv4 globally routable address space available is becoming a scarce resource, it is assumed that users will deploy IPv6 to reduce the need and reliability on IPv4 within a portion of their networks. Under this premise, supporting native IPv4 and native IPv6 simultaneously largely increases the complexity of network administration (address plan, routing infrastructure). It is proposed, in this case, to configure the network only for IPv6. In this specific scenario, DHCPv4 can not be directly used to assign IPv4 addresses to IPv6 nodes, since no IPv4 connectivity is maintained in the network. When DSTM is deployed in a network, an IPv4 address is allocated to a dual stack node if the connection can not be established using IPv6. This allows either IPv6 nodes to communicate with IPv4-only nodes, or IPv4-only applications to run on an IPv6 node without modification. This allocation mechanism is coupled with the ability to perform IPv4-over-IPv6 (4over6) tunnelling, hiding IPv4 packets inside the native IPv6 domain. This simplifies network management: only the IPv6 routing plan is managed inside the network. The DSTM architecture is composed of an address server (DSTM server), a gateway and a number of nodes (DSTM nodes). The address server is in charge of IPv4 address allocation to client nodes. This allocation is very simple since there is no localization purpose in this address. The DSTM server has just to guarantee the uniqueness of the IPv4 address for a period of time. The gateway, or Tunnel End Point (TEP), can be seen as a border router between the IPv6-only domain and an IPv4 Internet or Intranet. This node performs encapsulation/decapsulation of packets to assure bi-directional forwarding between both networks. Finally, in order to assure IPv4 connectivity, nodes in the IPv6-only domain should be able to dynamically configure their IPv4 stack (by asking the server for a temporary address) and must be capable to establish 4over6 tunnels towards a Tunnel End Point. The exact details on how DSTM nodes communicate with the DSTM Server is out of the scope of this overview and will be described in other documents. Bound Expires December 2002 [Page 3] INTERNET-DRAFT draft-ietf-ngtrans-dstm-overview-00.txt June 2002 2. DSTM Overview and Assumptions DSTM as discussed in the introduction is a method that uses existing protocols. DSTM does not specify a protocol. However, DSTM defines client, server and TEP behaviour and the properties of the temporary addresses allocation mechanisms. The motivation for DSTM is to provide IPv6 nodes a means to acquire an IPv4 address, for communications with IPv4-only nodes or IPv4 applications. The core assumption within this mechanism is that it is totally transparent to applications, which can continue to work with IPv4 addresses. It is also transparent to the network which carries only IPv6 packets. It is the authors' viewpoint that the user in this case, has deployed IPv6 to support end to end computing, without translation. This aspect is fundamental during a transition process to guarantee that every existing application will continue to work (e.g. IPsec, H.323), with embeded IPv4 addresses in the payload of a packet. The DSTM model and assumptions are as follows: - The DSTM domain is within an Intranet not on the Internet. - IPv6 nodes do not maintain IPv4 addresses except on a temporary basis, to communicate with IPv4-only and IPv4 Applications. - The temporary IPv4 address allocation is done by the DSTM server, different protocols such as DHCPv6 or RPCv6 can be used to assign the IPv4 address. - The DSTM domain for the IPv6 nodes will keep IPv4 routing tables to a minimum and use IPv6 routing, hence, reducing the network management required for IPv4 during transition. - Once IPv6 nodes have obtained IPv4 addresses Dynamic Tunneling is used to encapsulate the IPv4 packet within IPv6 and then forward that packet to an IPv6 TEP, where the packet will be decapulated and forwarded using IPv4. The IPv4 allocation mechanism may also provide the TEP IPv6 address. - Existing IPv4 applications or nodes do not have to be modified to communicate with DSTM. - Implementation defined software will have to exist to support DSTM: o Ability within a DSTM Server implementation to maintain configuration information about TEPs for encapsulating IPv4 packets between IPv6 nodes that can forward IPv4 packets to an Bound Expires December 2002 [Page 4] INTERNET-DRAFT draft-ietf-ngtrans-dstm-overview-00.txt June 2002 IPv4 routing realm, and to maintain a pool of IPv4 Addresses. o An IPv6 node MUST support the dynamic tunneling mechanisms in this specification to encapsulate IPv4 packets within IPv6 on an IPv6 node. In addition a DSTM client SHOULD be present on the node for IPv4 Mapped Addresses and TEPs management. o DSTM Border Routers MAY recall or be able to cache the association of IPv6 and IPv4 addresses of nodes during the forwarding process. A schematic overview of DSTM is as follows: ----------------------------------------------- | IPv4 Internet or Intranet DSTM Domain Intranet | IPv4 Applications | Domain _____________________ | | | | | DSTM Server | | |_____________________| | ^ | | | __________________ | _|_______ | | | | | | IPv6/IPv4 Node | | | DSTM | |------------------| | | Border | | DSTM client | | | Router | | |<------- | IPv6 | |------------------| | & | | DTI/Route |<-------------------->| IPv4 | ------------------- --------- | ---------------------------------------------- For an IPv6 node to participate in DSTM it MUST have a dual IP layer, supporting both an IPv4 and an IPv6 stack. DSTM is not a solution for IPv6 ONLY nodes. 3. DSTM Deployment Example In the example below, the following notation will be used: X will designate an IPv6 node with a dual stack, X6 will be the IPv6 address of this node and X4 the IPv4 address Bound Expires December 2002 [Page 5] INTERNET-DRAFT draft-ietf-ngtrans-dstm-overview-00.txt June 2002 Y will designate a DSTM border router at the boundary between an IPv6 DSTM domain and an IPv4-only domain. Z will designate an IPv4-only node 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 node 4.1 DSTM Client/Server Example This example describes the case where an application (either compiled for the IPv6 or IPv4 API) running on an IPv6 node (X6) wants to establish a session with an IPv4 application on an IPv4-only node (Z4). The IPv4 routing table of node X is configured to send IPv4 packets to the DTI interface. Bound Expires December 2002 [Page 6] INTERNET-DRAFT draft-ietf-ngtrans-dstm-overview-00.txt June 2002 DSTM Server DNS X6 Y6/Y4 Z4 | | | |. . . . . . . .> Z | - X6 asks the DNS 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 DSTM server for an | | | IPv4 address |<==== | | - The DSTM server locates the client | | | and provides a temporary IPv4 | | | global address and the IPv6 TEP address. |+++++++++++>| | - The DTI sends the IPv6 packet to the | | | TEP. | |----------->| - Y sends the packet to the destination Z4 | | | - Y caches the association between | |<-----------| - Z4 answers. | | | |<+++++++++++| | - Y uses the mapping between X4 and X6 | | | to tunnel the packet to the destination | | | When Z responds the packet returns back through Y. Y having cached the association between the IPv4 and the IPv6 address of X, is able to send the packet encapsulating the IPv4 packet within IPv6 back to X. 5. Implementation State and Other IETF work using DSTM DSTM is being used as a transition architecture and methodology for early and long term deployment. Implementations of DSTM exist on Linux and BSDi, and using RPCv6, DHCPv6, and manual configuration to provide the DSTM IPv4 Addresses to clients. DSTM can be used by Mobile and Stationary Clients or for Servers and Gateways providing other transition mechanisms for VPNs, Mobility between IPv4 and IPv6, and DNS Records to locate IPv6 nodes. DSTM can also be used to support 6to4 and Teredo as adjuncts to those transition mechanisms. Bound Expires December 2002 [Page 7] INTERNET-DRAFT draft-ietf-ngtrans-dstm-overview-00.txt June 2002 DSTM's implementation pilots exist and it is also achieving defacto implementation status within the early IPv6 adopter networks to avoid translation of IPv6. Other relevant IETF works in progress for DSTM can be viewed as follows: Dual Stack Transition Mechanism (DSTM) draft-ietf-ngtrans-dstm-07.txt DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup Protocol(TSP) draft-blanchet-ngtrans-tsp-dstm-profile-00 Dual Stack deployment using DSTM and neighbour discovery draft-bereski-ngtrans-nd-dstm-01.txt DSTM Options for DHCP draft-ietf-dhc-dhcpv6-opt-dstm-01.txt DSTM Ports Option for DHCPv6 draft-ietf-dhc-dhcpv6-opt-dstm-ports-00.txt Dual Stack Transition Mechanism (DSTM) Extensions draft-ietf-ngtrans-dstmext1-aiih-00.txt Extensions to SIIT and DSTM for enhanced routing of inbound packets draft-ietf-ngtrans-siit-dstm-01.txt DSTM in a VPN Scenario draft-richier-dstm-vpn-00.txt Using a Single IPv4 Global Address in DSTM draft-shin-dstm-single-ipv4-00.txt 6. Applicability Statement DSTM is applicable for use from within a DSTM Domain in which hosts need to communicate with IPv4-only hosts or through IPv4-only applications on a user Intranet or over the Internet. The motivation of DSTM is to allow dual IP layer nodes to communicate using global IPv4 addresses across an Intranet or Internet, where global addresses are required. However, the mechanisms used in DSTM can also be deployed using private IPv4 addresses to permit the Intranet use of DSTM where users require temporary access to IPv4 services within their Intranet. In DSTM, a mechanism is needed to perform the address allocation process. This can be decoupled in two functions: the management of the IPv4 address pool and the communication protocol between server and clients. A number of mechanisms, like DHCPv6, can perform these functions. The choice of the method to be used is out of scope and will be described in other documents. The exact capacities of the 4over6 tunnelling interface required by DSTM is implementation defined. Optionally, it is allowed that DSTM Bound Expires December 2002 [Page 8] INTERNET-DRAFT draft-ietf-ngtrans-dstm-overview-00.txt June 2002 nodes configure manually (in a static manner) the tunnel to the TEP; but the recommendation is not to do this. The dynamic configuration of 4over6 interfaces as a result of the address allocation process is the right way to execute DSTM on an IPv6 Network. DSTM also assumes that all packets returning from an IPv4 node to a DSTM node are routed through the originating DSTM TEP who maintains the association of the node's IPv4/IPv6 addresses. At this time it is beyond the scope of this proposal to permit IPv4 packets destined to a DSTM node to be forwarded through a non-originating DSTM TEP. A line for future work on DSTM may include the support of multiple TEPs for returning IPv4 packets and the discovery of DSTM nodes using IPv4 DNS queries. 7. Security Considerations The DSTM mechanism can use all of the defined security specifications for each functional part of its operation. For DNS, the DNS Security Extensions/Update can be used. Concerning address allocation, when connections are initiated by the DSTM nodes, the risk of Denial of Service attacks (DOS) based on address pool exaustion is limited since DSTM is used in an Intranet environement. In this scenario, If DHCPv6 is deployed, the DHCPv6 Authentication Message can be used too. Also, since the TEPs are inside an Intranet, they can not be used as an open relay. Finally, for IPv4 communications on DSTM nodes, once the node has an IPv4 address, IPsec can be used since DSTM does not break secure end-to-end communications at any point. Acknowledgments TBD References TBD Authors' Address Jim Bound Hewlett Packard 110 Spitbrook Road Nashua, NH 003062 Phone: +603.884.00 Email: Jim.Bound@hp.com USA Bound Expires December 2002 [Page 9]