Individual Submission INTERNET-DRAFT Jaehwoon Lee Expired: January 2005 Dongguk Univ. Filename: Jim Bound draft-jaehwoon-dstm-multitep-00.txt HP Myung-ki Shin ETRI/NIST July 2004 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 January 2005. Abstract Dual stack transition mechanism (DSTM) provides connectivity between dual stack hosts (i.e., DSTM client) 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-00.txt Expires - January 2005 [Page 1] Multiple TEP extension to DSTM July 2004 Table of Contents: 1. Introduction...................................................2 2. Terminology....................................................2 3. Multiple TEP Extension.........................................3 4. Applicability Statement........................................4 5. Security Considerations........................................5 References........................................................5 Author's Addresses................................................5 Intellectual Property Statement...................................5 Disclaimer of validity............................................6 Copyright Statement...............................................6 1. Introduction Dual stack transition mechanism (DSTM) enables a dual stack host (i.e., DSTM client) within an IPv6 network to communicate with 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 tunning 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 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]. draft-jaehwoon-multitep-exp-00.txt Expires - January 2005 [Page 2] Multiple TEP extension to DSTM July 2004 3. Multiple TEP extension An example of the DSTM architecture with multiple TEPs is shown in Figure 1. ----------------------------------------------- DSTM Domain (Intranet) | IPv4 Internet | IPv4 Application +---------------------+ | Domain | DSTM Server | | +---------------------+ | ^ ^ ^ | | | | | +----DSTM Node----+ | | | | | | | | | +--------+ | IPv6/IPv4 Node | | - - - - - >| DSTM | | | | | | BR2 | |-----------------| | | |(TEP2) | | DSTM client |<-------+ | | IPv6 |<------------> |-----------------| | | & | IPv4 | 4over6 iface |<=====================>| IPv4 | +-----------------+ IPv4 over IPv6 | +--------+ ^ tunnel | | || | | || | +--------+ || +--->| 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. draft-jaehwoon-multitep-exp-00.txt Expires - January 2005 [Page 3] Multiple TEP extension to DSTM July 2004 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. The DSTM node 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), and caches the information for the IPv6 address of the DSTM node 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 informatioin, the router uses the mapping between IPv4 and IPv6 addresses to tunnel the packet to the destination. Otherwise, BR2 queries 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. BR2 caches the mapping information of the IPv6 and IPv4 addresses, encapsulates the IPv4 packet, and tunnels the packet to the DSTM client. 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. Mechanism in this proposal also assumes that the DSTM client provides its global IPv6 address to DSTM server when it queries for a temporary IPv4 address. draft-jaehwoon-multitep-exp-00.txt Expires - January 2005 [Page 4] Multiple TEP extension to DSTM July 2004 5. Security Considerations This draft can follow security considerations defined by original DSTM draft [DSTM]. References [DSTM] Bound, Jim et al, "Dual Stack Transition Mechanism", April 2004, draft-bound-dstm-exp-01.txt. 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 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. draft-jaehwoon-multitep-exp-00.txt Expires - January 2005 [Page 5] Multiple TEP extension to DSTM July 2004 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-00.txt Expires - January 2005 [Page 6]