Internet DRAFT - draft-jaehwoon-dstm-multitep
draft-jaehwoon-dstm-multitep
Experimental RFC Proposal
INTERNET-DRAFT Jaehwoon Lee
Expired: January 13, 2006 Dongguk Univ.
Document: draft-jaehwoon-dstm-multitep-02.txt Jim Bound
Obsoletes: draft-jaehwoon-dstm-multitep-01.txt HP
Myung-ki Shin
ETRI
Sanghyun Ahn
Univ. of Seoul
July 14, 2005
Multiple TEP Extension to DSTM
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/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 13, 2006.
Copyright Notice
Copyright (C) The Internet Society (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-02.txt Expires - January 2006 [Page 1]
Multiple TEP extension to DSTM July 2005
Table of Contents:
1. Introduction...................................................3
2. Terminology....................................................3
3. Multiple TEP Extension.........................................3
4. Applicability Statement........................................5
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-02.txt Expires - January 2006 [Page 2]
Multiple TEP extension to DSTM July 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-02.txt Expires - January 2006 [Page 3]
Multiple TEP extension to DSTM July 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.
The DSTM client queries the DSTM server in order to get a temporary
IPv4 global address and the IPv6 TEP address, in order to communicate
with an IPv4-only node. 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).
draft-jaehwoon-multitep-exp-02.txt Expires - January 2006 [Page 4]
Multiple TEP extension to DSTM July 2005
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 may use its link local address
to communicate with the DSTM server. Even though DHCPv6 is used, the
DSTM client should provide its IPv6 address to DSTM server. When using
TSP, the DSTM client communicates with the DSTM server by using its
global IPv6 address.
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, 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.
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.
draft-jaehwoon-multitep-exp-02.txt Expires - January 2006 [Page 5]
Multiple TEP extension to DSTM July 2005
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 PEC
161 Gajeong-dong Yuseong-gu,
Daejon 305-350, Korea
E-mail : mshin@pec.etri.re.kr
Sanghyun Ahn
University of Seoul
90, Cheonnong-dong, Tongdaemun-gu
Seoul 130-743, KOREA
Email: ahn@venus.uos.ac.kr
draft-jaehwoon-multitep-exp-02.txt Expires - January 2006 [Page 6]
Multiple TEP extension to DSTM July 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
<tunnel action="query" type="v4v6">
<client>
<address type="ipv4">[IPv4 address of the TEP2]</address>
<address type="ipv6">[IPv6 address of the TEP2]</address>
</client>
<server>
<address type="ipv4">[IPv4 address of the DSTM client]
</address>
</tunnel> CR LF
S: Content-length: ... CR LF
200 OK CR LF
<tunnel action="info" type="v4v6" lifetime="1440">
<server>
<address type="ipv4" length="30">
[IPv4 address of the DSTM client]</address>
<address type="ipv6">[IPv6 address of the DSTM client]
</address>
</server>
<client>
<address type="ipv4" length="30">[IPv4 address of the TEP2]
</address>
<address type="ipv6">[IPv6 address of the TEP2]</address>
</client>
</tunnel>
draft-jaehwoon-multitep-exp-02.txt Expires - January 2006 [Page 7]
Multiple TEP extension to DSTM July 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
draft-jaehwoon-multitep-exp-02.txt Expires - January 2006 [Page 8]
