Experimental RFC Proposal Internet Draft Jim Bound (Editor) Document: draft-bound-dstm-exp-03.txt Hewlett-Packard Obsoletes: draft-bound-dstm-exp-02.txt Expires: June 2005 Dual Stack IPv6 Dominant Transition Mechanism (DSTM) <draft-bound-dstm-exp-03.txt> Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The deployment of IPv6 will require a tightly coupled use of IPv4 addresses to support the interoperation of IPv6 and IPv4 within an IPv6 dominant 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 IPv6 Dominant Transition Mechanism (DSTM) is based on the use of IPv4-over-IPv6 tunnels to carry IPv4 traffic within an IPv6 dominant network and provides a method to allocate a temporary IPv4 address to Dual IP Layer IPv6/IPv4 capable nodes. DSTM is also a way to avoid the use of Network Address Translation for early adopter IPv6 deployment to communicate with IPv4 legacy nodes and applications. draft-bound-dstm-exp-03.txt Expires Feb 2006 [Page 1]^L Internet Draft Dual Stack Transition Mechanism July 2005 Table of Contents: 1. Introduction................................................3 2. DSTM Terminology............................................4 3. DSTM Problem Statement and Assumptions......................5 4. DSTM Deployment Example.....................................8 5. DSTM Client.................................................9 5.1 DSTM Server Access Module..................................10 5.2 DSTM Dynamic Tunnel Interface (DTI)........................10 6. DSTM Server ...............................................10 6.1 DSTM Client Access Module..................................10 6.2 DSTM Address Pool Access Module............................11 6.3 DSTM Routing Information Access Module.....................11 7. DSTM Border Router.........................................11 8. Applicability Statement....................................11 9. Security Considerations....................................12 Acknowledgments................................................13 References.....................................................13 Copyright (C) The Internet Society (2005)......................13 Disclaimer.....................................................14 IPR Disclosure Acknowledgement.................................14 Disclaimer of validity.........................................14 Acknowledgment.................................................15 Author's Addresses.............................................16 draft-bound-dstm-exp-03.txt Expires Feb 2006 [Page 2]^L Internet Draft Dual Stack Transition Mechanism July 2005 1. Introduction The deployment of IPv6 will require a tightly coupled use of IPv4 addresses to support the interoperation of IPv6 and IPv4 within an IPv6 dominant 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 IPv6 Dominant Transition Mechanism (DSTM) is based on the use of IPv4-over-IPv6 tunnels to carry IPv4 traffic within an IPv6 dominant network and provides a method to allocate a temporary IPv4 address to Dual IP Layer IPv6/IPv4 capable nodes. DSTM is also a way to avoid the use of Network Address Translation for early adopter IPv6 deployment to communicate with IPv4 legacy nodes and applications. DSTM is targeted to help the interoperation of IPv6 newly deployed networks with existing IPv4 networks, where the user wants to begin IPv6 adoption with an IPv6 dominant network plan, or later in the transition of IPv6, when IPv6 dominant networks will be more prevalent. When DSTM is deployed in a network, an IPv4 address can be allocated to a Dual IP Layer IPv6/IPv4 capable node to connect with IPv4 only capable nodes. DSTM permits dual IPv6/IPv4 nodes to communicate with IPv4 only nodes and applications, without modification to any IPv4 only node or application, or the IPv4 only application on the DSTM node. This allocation mechanism is coupled with the ability to perform IPv4-over-IPv6 tunneling of IPv4 packets inside the IPv6 dominant network. The DSTM architecture is composed of a DSTM address server, and DSTM capable nodes. The DSTM server is responsible for IPv4 address allocation to client nodes and MAY also provide tunnel end points (TEP) to the DSTM nodes. The DSTM server MUST guarantee the uniqueness of the IPv4 address for a period of time. The DSTM nodes will use TEPs to tunnel IPv4 packets within IPv6 to a DSTM Border router. The DSTM border router then decapsulates the IPv6 packets and transmits the IPv4 packets to the destination IPv4 node. The DSTM border router MUST cache the path back to the DSTM node for the IPv4 address to tunnel the packet in IPv6 to the original DSTM node. draft-bound-dstm-exp-03.txt Expires Feb 2006 [Page 3]^L Internet Draft Dual Stack Transition Mechanism July 2005 2. DSTM Terminology DSTM Domain The network areas on an Intranet where dual IPv6/IPv4 nodes use DSTM to assure IPv4 communication. An IPv4 address allocation server may be deployed inside the domain to manage an IPv4 address pool. IPv4 routing access may not be maintained within a DSTM domain. DSTM Client A Dual IP Layer IPv4/IPv6 Capable Node that has implemented the DSTM client software in this specification. DSTM Server A Dual IP Layer IPv4/IPv6 Capable Node that has implemented the DSTM server software in this specification. DSTM Border Router A Dual IP Layer IPv4/IPv6 Capable Node that has implemented the DSTM border router software in this specification. IPv6 Dominant Network A network that is using IPv6 as the dominant network transport for network operations. Dynamic Tunnel Interface This is an interface on a DSTM Client that will permit the sending of IPv4 packets within IPv6 to a DSTM Border Router, and receive IPv4 packets within IPv6 from an IPv4 node or application. draft-bound-dstm-exp-03.txt Expires Feb 2006 [Page 4]^L Internet Draft Dual Stack Transition Mechanism July 2005 3. DSTM Problem Statement and Assumptions 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. Some users will require an aggressive transition to IPv6 and will begin the deployment of IPv6 reducing immediately the reliance on IPv4 whereever possible. Under this premise, supporting native IPv4 and native IPv6 simultaneously largely increases the complexity and cost of network administration (e.g. address plan, routing infrastructure). It is proposed, in this case, to define the network strategy plan to support IPv6 only use as soon as possible. Reliance on IPv4 infrastructure points like name service and address allocation for Dual IPv6/IPv4 capable nodes will move to an IPv6 strategy. Using DSTM, DHCPv4 [DHC4] may be used to assign IPv4 addresses to a DSTM nodes, since IPv4 routing is not maintained within an IPv6 dominant network implementation, to support DHCPv4 some IPv4 network connecvity would be required. Using DHCPv6 [DHC6] reduces the reliance on IPv4 infrastructure for the transition to IPv6 with DSTM. But, DHCPv6 and DHCPv4 are not the only mechanisms that can be supported to allocate IPv4 addresses to a DSTM client. DSTM is a transition mechanism that uses existing protocols. DSTM does not specify a protocol. However, DSTM defines client, server, and border router behavior and the properties of the temporary addresses allocation mechanisms. The core assumption within DSTM is that it is completely transparent to applications, which can continue to work with IPv4 addresses. It is also transparent to the network, which carries only IPv6 packets. DSTM assumes the user, has deployed IPv6 to support end-2-end applications and security, without translation. DSTM implementation would also support the use of IPv6 dominant networks as specified in IPv6 Enterprise Scecnarios and Analysis [ENTSCE, ENTANA] The DSTM architecture base assumptions are as follows: 1. The DSTM domain is within an Intranet not on the Internet. 2. Dual IPv6/IPv4 nodes do not maintain IPv4 addresses except on a temporary basis, to communicate with IPv4 Applications. 3. The temporary IPv4 address allocation is done by the DSTM server, different protocols such as DHCPv6 or other mechanism can be used to assign the IPv4 address. DHCPv6 is the recommended draft-bound-dstm-exp-03.txt Expires Feb 2006 [Page 5]^L Internet Draft Dual Stack Transition Mechanism July 2005 default mechanism. 4. DSTM will keep IPv4 routing tables to a minimum and use IPv6 routing, which will reduce the network management required for IPv4 during transition within a DSTM Dominant IPv6 Network. 5. 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 DSTM border router, where the packet will be decapsulated and forwarded using IPv4. The IPv4 allocation mechanism, from the DSTM server, can provide the TEP IPv6 address to the DSTM client, in addition to manual configuration. 6. Existing IPv4 applications or nodes do not have to be modified. Implementation defined software will have to exist to support DSTM: 1. DSTM server implementation is required to maintain configuration information about TEPs for encapsulating IPv4 packets between IPv6 nodes that can forward IPv4 packets to an IPv4 routing destination, and to maintain a pool of IPv4 addresses. 2. DSTM client implementation is required to support the dynamic tunneling mechanisms in this specification to encapsulate IPv4 packets within IPv6, and be able to communicate with the DSTM server to obtain IPv4 addresses and TEPs. 3. DSTM border router implementation is required to support the decapsulation of IPv6 packets from DSTM clients and forward them to the IPv4 destination, and cache the IPv6 address and the source IPv4 address used by the DSTM client. Schematic Overview of DSTM ------------------------------------------------- | IPv4 Intranet | DSTM Domain Intranet | Internet or Intranet | _____________________ | Applications Domain | | | | DSTM Server | | |_____________________| | ^ | | | __________________ | | | | | | | IPv6/IPv4 Node | | ---------------- draft-bound-dstm-exp-03.txt Expires Feb 2006 [Page 6]^L Internet Draft Dual Stack Transition Mechanism July 2005 |------------------| | | DSTM Border | | DSTM client | | | Router | | |<------- | | |------------------| | Address mapping| | DTI/Route | /------------------ |----------------| | | IPv4 in IPv6 | IPv6/IPv4 node | ------------------ ------------------/ ---------------- | ----------------------------------------------- draft-bound-dstm-exp-03.txt Expires Feb 2006 [Page 7]^L Internet Draft Dual Stack Transition Mechanism July 2005 4. DSTM Deployment Example In the example below, the following notation will be used: X will designate a dual IPv6/IPv4 node, X6 will be the IPv6 address of this node and X4 the IPv4 address 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 This example describes the case where an application running on a dual IPv6/IPv4 node (X6) wants to establish a session with an IPv4 application (Z4). The IPv4 routing table of node X is configured to send IPv4 packets to the nodes Dynamic Tunnel Interface (DTI) interface. draft-bound-dstm-exp-03.txt Expires Feb 2006 [Page 8]^L Internet Draft Dual Stack Transition Mechanism July 2005 DSTM Server DNS X6 Y6/Y4 Z4 | | | |. . . . . . . .> Z | - IPv4 application asks the DNS for the A | | | RR for "Z". (IPv6 application asks the | | | DNS for the AAAA RR fo "Z".) | | | |<. . . . . . . . Z4 | - the answer is Z4 (or IPv4-mapped IPv6 | | | ::FFFF:Z4). | | | | | | - The IPv4 application sends its first | | | IPv4 packet which arrives to the DTI | | | interface. (The IPv6 application | | | can do this 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 | |<-----------| - 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. DSTM Client A DSTM client requires the implementation of a DSTM Server Access Module and a Dynamic Tunnel Interface. draft-bound-dstm-exp-03.txt Expires Feb 2006 [Page 9]^L Internet Draft Dual Stack Transition Mechanism July 2005 5.1 DSTM Server Access Module A DSTM Server Access Module connects to the DSTM Server to obtain an IPv4 address and TEP. DSTM recommends the use of a DHCPv6 client implementation or using the Tunnel Setup Protocol. The DSTM client may also receive an expiration life time for that IPv4 address, which when expired the DSTM client cannot continue to use that IPv4 address. The DSTM client must not perform any Dynamic upates to the DNS [DYNDNS] for any IPv4 address returned to the DSTM Server Access Module. The TEP can also be manually configured on the DSTM client. 5.2 DSTM Dynamic Tunnel Interface (DTI) The DSTM client implementation after obtaining an IPv4 address and TEP configures its DTI to send an IPv4 packet to the IPv6 TEP of a DSTM border router, and receive IPv4 packets from an IPv6 TEP for an IPv4 application on a DSTM client. 6. DSTM Server A DSTM server implementation requires the implementation of a DSTM Client Access Module, Address Pool Access Module, and Routing Information Access Module. 6.1 DSTM Client Access Module The DSTM Client Access Module is required to accept requests from DSTM clients for an IPv4 address and TEPs, and then return an IPv4 address and TEPs to the DSTM client. DSTM recommends the use of a DHCPv6 server implementation or Tunnel Broker [TUNBKR] as the DSTM Client Access Module. draft-bound-dstm-exp-03.txt Expires Feb 2006 [Page 10]^L Internet Draft Dual Stack Transition Mechanism July 2005 6.2 DSTM Address Pool Access Module The DSTM Address Pool Module is required to maintain a pool of IPv4 addresses for DSTM clients and maintain the lifetimes for those addresses. The lifetime for those IPv4 addresses can be provided to the DSTM client with the IPv4 address and TEPs. 6.3 DSTM Routing Information Access Module The DSTM Routing Information Access Module is required to learn or manually configure the TEPs within the DSTM domain to provide TEPs to the DSTM clients. 7. DSTM Border Router The DSTM border router is required to be able to receive IPv6 packets from DSTM clients and then decapsulate the inner IPv4 packets and send to the IPv4 destination address in the IPv4 packets. The DSTM border router is required to maintain the IPv6 address of the DSTM clients that send IPv6 packets with IPv4 encapsulated, so IPv4 packets sent to the DSTM clients IPv4 address can be tunneled back to the DSTM client. 8. 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 exact capacities of the DTI required by DSTM is implementation draft-bound-dstm-exp-03.txt Expires Feb 2006 [Page 11]^L Internet Draft Dual Stack Transition Mechanism July 2005 defined. Optionally, it is allowed that DSTM nodes configure manually (in a static manner) the tunnel to the TEP; but the recommendation is not to do this. The dynamic configuration of DTI 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 DSTM client '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. 9. 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 configured 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. Also TSP can be used with the Transport Layer Security protocol over a VPN. draft-bound-dstm-exp-03.txt Expires Feb 2006 [Page 12]^L Internet Draft Dual Stack Transition Mechanism July 2005 Acknowledgments The authors would like to thank the following persons for their hard work to build the DSTM options in DHCPv6 as follows: Ted Lemon, Ralph Droms, Myung-Ki Shin, and Bernie Volz. References Normative References [DHC4] Droms, R. (ed) "Dynamic Host Configuration Protocol" RFC 2131, March 1997. [DHC6] Droms. R. (ed) et. al. "Dynamic Host Configuration Protocol for IPv6 (DHCPv6), RFC 3315, July 2003. [TUNBKR] Durand, Fasano, Guardini, and Lento, "IPv6 Tunnel Broker" RFC 3053, January 2001. [DYNDNS] Vixie P. (ed) et. al. "Dynamic Updates in the Domain Name System, RFC 2136, April 1997. Non-Normative References [ENTSCE] Bound, J (ed) "IPv6 Enterprise Scenarios" work in progress ietf-draft-v6ops-ent-scenarios--05.txt, August 2004 [ENTANA] Bound, J (ed) "IPv6 Enterprise Network Analysis" work in progress, draft-ietf-v6ops-ent-analysis-01.txt January 2005 Copyright (C) The Internet Society (2005) This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." draft-bound-dstm-exp-03.txt Expires Feb 2006 [Page 13]^L Internet Draft Dual Stack Transition Mechanism July 2005 Disclaimer This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. IPR Disclosure Acknowledgement By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Disclaimer of validity The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. draft-bound-dstm-exp-03.txt Expires Feb 2006 [Page 14]^L Internet Draft Dual Stack Transition Mechanism July 2005 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. draft-bound-dstm-exp-03.txt Expires Feb 2006 [Page 15]^L Internet Draft Dual Stack Transition Mechanism July 2005 Author's Addresses Jim Bound Hewlett Packard ZK3-3/W20 110 Spit Brook Road Nashua, NH 03062-2698 USA Phone: +1 603 884 0062 EMail: Jim.Boundhp.com Laurent Toutain ENST Bretagne BP 78 35512 Cesson Sevigne Cedex, FR. Phone : +33 2 99 12 70 26 Email : Laurent.Toutain@enst-bretagne.fr Octavio Medina ENST Bretagne BP 78 35512 Cesson Sevigne Cedex, FR. Phone : +33 2 99 12 70 23 Email : Octavio.Medina@enst-bretagne.fr Francis Dupont ENST Bretagne BP 78 35 512 Cesson Sevigne Cedex, FR. Phone : +33 2 99 12 70 33 Email : Francis.Dupont@enst-bretagne.fr Myung-Ki Shin ETRI PEC 161 Kajong-Dong, Yusong-Gu, Taejon 305-350, Korea Phone: +82 42 860 4847 Fax : +82 42 861 5404 E-mail : mkshin@pec.etri.re.kr Jaehwoon Lee Dongguk University 26, 3 Pil-dong, Chung-gu, Seoul, 100-715, Korea Phone: +82-2-22603849 Email : jaehwoon@dongguk.edu Hee-Cheol Lee ETRI PEC 161 Gajong-Dong, Yusong-Gu, Daejon 305-350, Korea Phone: +82 42 860 1833 Email: hclee_shep@etri.re.kr draft-bound-dstm-exp-03.txt Expires Feb 2006 [Page 16]^L Internet Draft Dual Stack Transition Mechanism July 2005 Eva Castro Universidad Rey Juan Carlos Escuela Superior de Ciencias Experimentales Tecnologia Departamento de Informatica, Estadistica y Telematica C/ Tulipan s/n - 28933 Mostoles - Madrid SPAIN E-mail: eva@gsyc.escet.urjc.es draft-bound-dstm-exp-03.txt Expires Feb 2006 [Page 17]^L