Experimental RFC Proposal INTERNET-DRAFT Jaehwoon Lee Expired: August 2005 Dongguk Univ. Document: draft-jaehwoon-dstm-multitep-01.txt Jim Bound Obsoletes: draft-jaehwoon-dstm-multitep-00.txt HP Myung-ki Shin ETRI/NIST February 2005 Multiple TEP Extension to DSTM Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 docu- ments 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. This Internet-Draft will expire on August 2005. Abstract Dual stack transition mechanism (DSTM) provides connectivity between dual stack hosts (i.e., DSTM clients) within an IPv6-only network and IPv4 nodes within an IPv4 internet or intranet. DSTM defined in [DSTM] considers only one TEP, that is, packets from an IPv4 node to a DSTM client need to be routed through the same DSTM border router as that used in transmitting packets from the DSTM client to the IPv4 node. In this draft, we propose a DSTM architecture of using multiple TEPs with only one IPv4 address pool for a DSTM domain. draft-jaehwoon-multitep-exp-01.txt Expires - August 2005 [Page 1] Multiple TEP extension to DSTM February 2005 Table of Contents: 1. Introduction...................................................3 2. Terminology....................................................3 3. Multiple TEP Extension.........................................3 4. Applicability Statement........................................6 5. Security Considerations........................................6 Acknowledgement...................................................6 References........................................................6 Author's Addresses................................................6 A. Appendix A. TSP Profile exchanged between the DSTM server and the TEP........................................7 Intellectual Property Statement...................................8 Disclaimer of validity............................................8 Copyright Statement...............................................8 draft-jaehwoon-multitep-exp-01.txt Expires - August 2005 [Page 2] Multiple TEP extension to DSTM February 2005 1. Introduction Dual stack transition mechanism (DSTM) enables a dual stack host (i.e., DSTM client) within an IPv6 network to communicate with an IPv4- only capable node within an IPv4 internet or intranet. DSTM defines a method to allocate a temporary IPv4 address to a DSTM client and provides the IPv4-over-IPv6 tunneling in order to carry IPv4 traffic within an IPv6 network. DSTM architecture is composed of a number of DSTM clients, a DSTM server, and one or more DSTM border routers each having a Tunnel End Point (TEP). DSTM defined in [DSTM] assumes only one TEP, that is, packets from an IPv4 node to a DSTM client should be routed through the same TEP as that use in transmitting packets from the DSTM client to the IPv4 node. However, the mechanism has the drawback of the DSTM domain disconnection from an IPv4 internet in the case of the TEP failure. As an approach to overcome this deficiency, multiple TEPs each having a different IPv4 address pool can be used. However, this method has limitations like that each TEP should advertise different IPv4 address pool information to the IPv4 internet and the optimal router may not be provided. In this draft, we propose the multiple TEP extension to DSTM so that traffic from a DSTM client to an IPv4 node and the reverse traffic from the IPv4 node to the DSTM client can be transmitted through different DSTM border routers (TEPs). 2. Terminology There is no additional terms defined in this draft except those defined in [DSTM]. 3. Multiple TEP extension to DSTM An example of the DSTM architecture with multiple TEPs is shown in Figure 1. draft-jaehwoon-multitep-exp-01.txt Expires - August 2005 [Page 3] Multiple TEP extension to DSTM February 2005 ----------------------------------------------- DSTM Domain (Intranet) | IPv4 Internet | IPv4 Application +---------------------+ | Domain | DSTM Server | | +---------------------+ | ^ ^ ^ | | | | | +----DSTM Node----+ | | | | | | | | | +--------+ | IPv6/IPv4 Node | | - - - - - >| DSTM | | | | ( TSP ) | | BR2 | |-----------------| | | |(TEP2) | | DSTM client |<-------+ | | IPv6 |<------------> |-----------------| | | & | IPv4 | 4over6 iface |<=====================>| IPv4 | +-----------------+ IPv4 over IPv6 | +--------+ ^ tunnel | | ^ || | | | ( BGP+ ) || | | v || | +--------+ || +--->| DSTM | || | BR1 | =============================>|(TEP1) | IPv4 over IPv6 | IPv6 |<------------> tunnel | & | IPv4 | IPv4 | +--------+ IPv6-only Network | | ---------------------------------------------- Figure 1 A schematic overview of DSTM with the multiple TEP extension As an example, network address 1.0.0.0 is allocated as an IPv4 address pool for the DSTM domain in figure 1. The border router operates between a DSTM domain and an IPv4 internet and advertises the network address to an IPv4 internet in order to provide the reachability from the IPv4 internet. Routing within an IPv4 internet must ensure that IPv4 packets destined to the DSTM domain arrive at one or more TEPs within the DSTM domain. In order to communicate with an IPv4 node, a DSTM client asks the DNS for the A/AAAA RR for an IPv4 node. The answer of the DNS is the IPv4 address (type A) of the IPv4 node. draft-jaehwoon-multitep-exp-01.txt Expires - August 2005 [Page 4] Multiple TEP extension to DSTM February 2005 The DSTM client queries the DSTM server in order to get a temporary IPv4 global address and the IPv6 TEP address. On receiving the request, the DSTM server provides a temprary IPv4 address currently not used and the IPv6 address of a TEP (i.e., TEP1). DHCPv6 or Tunnel Setup Protocol (TSP) can be used for the communication between the DSTM client and the DSTM server [TSP]. When DHCPv6 is used, the DSTM client uses its link local address to communicate with the DSTM server. In this case, the DSTM server does not cache any information about the DSTM client. When using TSP, the DSTM client communicates with the DSTM server by using its global IPv6 address. In this case, the DSTM server caches the information of the IPv6 address of the DSTM client and the IPv4 address allocated to it. The IPv4 address allocated to the DSTM client is used as the source address of the IPv4 packets generated by the DSTM client. The DSTM client encapsulates an IPv4 packet and sends the encapsulated IPv6 packet to a DSTM border router, BR1, defined by the TEP1 address. BR1 decapsulates the packet, sends it to the IPv4 node, and caches the IPv6/IPv4 addresses of the DSTM client. The IPv4 node answers, and the IPv4 packet may arrive at another DSTM borer router, BR2. BR2 checks the mapping information. If the destination IPv4 address exists in the information, the router uses the mapping between IPv4 and IPv6 addresses to tunnel the packet to the destination. Otherwise, when DHCPv6 is used within the DSTM domain, BR2 communicates with BR1 by using variant of BGP, such as BGP+, in order to get the IPv6 address corresponding to the destination IPv4 address of the packet. How to use variant of BGP is for further study. When TSP is used, BR2 queris the DSTM server for the IPv6 address corresponding to the IPv4 address allocated to the DSTM client. The DSTM server sends to BR2 the IPv6 address corresponding to the queried Ipv4 address. Appendix A shows the XML messages exchanged between the DSTM server and BR2 by using TSP. BR2 caches the mapping information of the IPv6 and IPv4 addresses, encapsulates the IPv4 packet, and tunnels the packet to the DSTM client. draft-jaehwoon-multitep-exp-01.txt Expires - August 2005 [Page 5] Multiple TEP extension to DSTM February 2005 4. Applicability statement Multiple TEP extension to DSTM, proposed in this draft, assumes only one DSTM server. At this time, it is beyond the scope of this proposal to consider multiple DSTM server as well as synchronization of address mapping information between them. 5. Security Considerations IPsec will exist between all ingress/egress points and we can expand later. This draft can also follow security considerations defined by original DSTM draft [DSTM]. Acknowledgments The authors would like to thank Florent Parent for his comments on TSP profiles. References [DSTM] Bound, Jim et al, "Dual Stack Transition Mechanism", draft-bound-dstm-exp-01.txt (work in progress), January 2005. [TSP] Blanchet, M. and Parent, F, "IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)", draft-blanchet-v6ops- tunnelbroker-tsp-01.txt (work in progress), June 2004. Authors' Addresses Jaehwoon Lee Dongguk University 26, 3-ga Pil-dong, Chung-gu Seoul, 100-715, KOREA Email: jaehwoon@dongguk.edu Jim Bound ZK3-3/W20 Hewlett Packerd 110 Spit brook Road Nashua, NH 03062-2698, USA. Email: Jim.Bound@hp.com Myung-Ki Shin ETRI/NIST 820 West Diamond Avenue Gaithersburg, MD 20899, USA E-mail : mshin@nist.gov draft-jaehwoon-multitep-exp-01.txt Expires - August 2005 [Page 6] Multiple TEP extension to DSTM February 2005 Appendix A. TSP Profile exchanged between the DSTM server and the TEP The Tunnel Setup Protocol, TSP, is designed to negotiate the tunnel information [TSP]. Four types of messages are defined to use TSP for DSTM, such as 'Tunnel Create' message, 'Tunnel Delete' message, 'Tunnel Info' message, and 'Tunnel Error' message. In this draft, an additional message is defined to exchange address information between the DSTM server and a TEP. o 'Tunnel query' messages are sent by a TEP to the DSTM server in order to query the IPv6 address of the requesting DSTM client. The following is the TSP profile exchanged between the TEP and the DSTM server. Client : TEP2 , Server : DSTM client -- Successful TCP connection -- C: VERSION=1.0 CR LF S: CAPABILITY TUNNEL=V4V6 AUTH=DIGEST-MD5 AUTH=ANONYMOUS CR LF C: AUTHENTICATE ANONYMOUS CR LF S: OK Authentication successful CR LF C: Content-length: ... CR LF
[IPv4 address of the TEP2]
[IPv6 address of the TEP2]
[IPv4 address of the DSTM client]
CR LF S: Content-length: ... CR LF 200 OK CR LF
[IPv4 address of the DSTM client]
[IPv6 address of the DSTM client]
[IPv4 address of the TEP2]
[IPv6 address of the TEP2]
 draft-jaehwoon-multitep-exp-01.txt Expires - August 2005 [Page 7] Multiple TEP extension to DSTM February 2005 Intellectual Property Statement 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. draft-jaehwoon-multitep-exp-01.txt Expires - August 2005 [Page 8]