One document matched: draft-jaehwoon-dstm-multitep-01.txt
Differences from draft-jaehwoon-dstm-multitep-00.txt
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
<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-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]
| PAFTECH AB 2003-2026 | 2026-04-23 18:53:31 |