Experimental RFC Proposal
Internet Draft Jim Bound (Editor)
Document: draft-bound-dstm-exp-00.txt Hewlett Packard
Expires: February 2004 August 2003
Dual Stack Transition Mechanism
<draft-bound-dstm-exp-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
This document is a submission by the Internet Protocol IPv6 Working
Group of the Internet Engineering Task Force (IETF). Comments should
be submitted to the ipng@sunroof.eng.sun.com mailing list.
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.
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 IP Layer Stack 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-00.txt Expires February 2004 [Page 1]
Internet Draft Dual Stack Transition Mechanism August 2003
Table of Contents:
1. Introduction................................................3
2. DSTM Terminology............................................4
3. DSTM Problem Statement and Assumptions......................5
4. DSTM Deployment Example.....................................7
5. DSTM Client.................................................8
5.1 DSTM Server Access Module...................................8
5.2 DSTM Dynamic Tunnel Interface (DTI).........................9
6. DSTM Server ................................................9
6.1 DSTM Client Access Module...................................9
6.2 DSTM Address Pool Access Module.............................9
6.3 DSTM Routing Information Access Module......................9
7. DSTM Border Router..........................................9
8. Applicability Statement....................................10
9. Security Considerations....................................10
Appendix A DHCPv6 Options for DSTM.............................11
Appendix B DSTM Port Options for DHCPv6........................16
Appendix C Tunnel Setup Protocol (TSP).........................18
Full Copyright Statement.......................................33
Acknowledgments................................................33
References.....................................................33
Authors Addresses..............................................34
draft-bound-dstm-exp-00.txt Expires February 2004 [Page 2]
Internet Draft Dual Stack Transition Mechanism August 2003
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 IP Layer Stack 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-00.txt Expires February 2004 [Page 3]
Internet Draft Dual Stack Transition Mechanism August 2003
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-00.txt Expires February 2004 [Page 4]
Internet Draft Dual Stack Transition Mechanism August 2003
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 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 [1] would not be used to assign IPv4 addresses to
a DSTM Dual IP Layer IPv6/IPv6 nodes, since IPv4 routing is not
maintained within an IPv6 Dominant Network implementation. Using
DHCPv6 [2] reduces the reliance on IPv4 infrastructure for the
transition to IPv6 with DSTM. But, DHCPv6 is not the only mechanism
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.
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.
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.
draft-bound-dstm-exp-00.txt Expires February 2004 [Page 5]
Internet Draft Dual Stack Transition Mechanism August 2003
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 | | ----------------
|------------------| | | DSTM Border |
| DSTM client | | | Router |
| |<------- | |
|------------------| | Address mapping|
| DTI/Route | /------------------ |----------------|
| | IPv4 in IPv6 | IPv6/IPv4 node |
------------------ ------------------/ ----------------
|
-----------------------------------------------
draft-bound-dstm-exp-00.txt Expires February 2004 [Page 6]
Internet Draft Dual Stack Transition Mechanism August 2003
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-00.txt Expires February 2004 [Page 7]
Internet Draft Dual Stack Transition Mechanism August 2003
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.
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 (TSP) [see
Appendix C], also used in the Tunnel Broker [3],
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.
draft-bound-dstm-exp-00.txt Expires February 2004 [Page 8]
Internet Draft Dual Stack Transition Mechanism August 2003
The DSTM client must not perform any Dynamic upates to the DNS [4]
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 as the DSTM Client
Access Module.
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
draft-bound-dstm-exp-00.txt Expires February 2004 [Page 9]
Internet Draft Dual Stack Transition Mechanism August 2003
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
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-00.txt Expires February 2004 [Page 10]
Internet Draft Dual Stack Transition Mechanism August 2003
Appendix A DHCPv6 Options for DSTM
Network Working Group B. Volz
Internet-Draft Ericsson
Expires: October 24, 2002 J. Bound
Compaq Computer Corporation
R. Droms
Cisco Systems
T. Lemon
Nominum, Inc.
April 25, 2002
DSTM Options for DHCP
draft-ietf-dhc-dhcpv6-opt-dstm-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 October 24, 2002.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
The DSTM Global IPv4 Address option and the DSTM Tunnel Endpoint
Option provide DSTM (Dual Stack Transition Mechanism) configuration
information to DHCPv6 hosts.
1. Introduction
This document describes two options for DHCPv6 [2] that provide
information for hosts using the "Dual Stack Transition Mechanism"
(DSTM) [3].
2. Requirements
draft-bound-dstm-exp-00.txt Expires February 2004 [Page 11]
Internet Draft Dual Stack Transition Mechanism August 2003
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in RFC2119 [1].
3. Terminology
This document uses terminology specific to IPv6 and DHCPv6 as defined
in section "Terminology" of the DHCPv6 specification.
4. Identity Association for DSTM Global IPv4 Addresses
The Identity Association for DSTM Global IPv4 Addresses (IA_DSTM)
option is used to carry an IA, the parameters associated with the IA
and the addresses associated with the IA. All of the addresses in
this option are used by the client as DSTM Global IPv4 Addresses [3].
The format of the IA_DSTM option is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IA_DSTM | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. IA-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_IA_DSTM (TBD)
option-len: 12 + length of IA-options field
IAID: The unique identifier for this IA; the IAID must be
unique among the identifiers for all of this client's IAs
T1: The time at which the client contacts the server from
which the addresses in the IA were obtained to extend the
lifetimes of the addresses assigned to the IA; T1 is a time
duration relative to the current time expressed in units of
seconds
T2: The time at which the client contacts any available
server to extend the lifetimes of the addresses assigned to the
IA; T2 is a time duration relative to the current time expressed
in units of seconds
IA-options: Options associated with this IA.
The IA-options field encapsulates those options that are specific to
this IA. For example, all of the Address Options carrying the
addresses associated with this IA are in the IA-options field.
draft-bound-dstm-exp-00.txt Expires February 2004 [Page 12]
Internet Draft Dual Stack Transition Mechanism August 2003
An IA_DSTM option may only appear in the options area of a DHCP
message. A DHCP message may contain multiple IA_DSTM options.
The status of any operations involving this IA is indicated in a
Status Code option in the IA-options field.
Note that an IA has no explicit "lifetime" or "lease length" of its
own. When the lifetimes of all of the addresses in an IA have
expired, the IA can be considered as having expired. T1 and T2 are
included to give servers explicit control over when a client
recontacts the server about a specific IA.
In a message sent by a client to a server, values in the T1 and T2
fields indicate the client's preference for those parameters. The
client may send 0 if it has no preference for T1 and T2. In a
message sent by a server to a client, the client MUST use the values
in the T1 and T2 fields for the T1 and T2 parameters. The values in
the T1 and T2 fields are the number of seconds until T1 and T2.
The server selects the T1 and T2 times to allow the client to extend
the lifetimes of any addresses in the IA before the lifetimes expire,
even if the server is unavailable for some short period of time.
Recommended values for T1 and T2 are .5 and .8 times the shortest
preferred lifetime of the addresses in the IA, respectively. If the
server does not intend for a client to extend the lifetimes of the
addresses in an IA, the server sets T1 and T2 to 0.
T1 is the time at which the client begins the lifetime extension
process by sending a Renew message to the server that originally
assigned the addresses to the IA. T2 is the time at which the client
starts sending a Rebind message to any server.
T1 and T2 are specified as unsigned integers that specify the time in
seconds relative to the time at which the messages containing the
option is received.
A DSTM Tunnel End Point option (Section 5) MAY be encapsulated in an
IA_DSTM option to specify one or more tunnel endpoints.
5. DSTM Tunnel Endpoint Option
The DSTM Tunnel Endpoint option carries an IP address that is to be
used as a tunnel endpoint (TEP) to encapsulate IP datagrams within
IP.
The format of the DSTM Tunnel Endpoint option is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_DSTM_TEP | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. tep .
. (16 octets) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_DSTM_TEP (TBD)
draft-bound-dstm-exp-00.txt Expires February 2004 [Page 13]
Internet Draft Dual Stack Transition Mechanism August 2003
option-length: 16
tep: Tunnel endpoint
A DSTM Tunnel EndPoint Option MUST NOT be used except when
encapsulated in an IA_DSTM option.
6. Appearance of these options
The IA_DSTM option may appear in the same messages as the IA option
and the IA_TA option [2].
A server may send a Reconfigure with an IA_DSTM option number in the
Option Request option (see sections 19 and 22.7 of the DHCP
specification [2]) to request that the client send a IA_DSTM option,
with an IAID, in the Renew message the client subsequently sends to
the server.
The DSTM Tunnel Endpoint option MUST only appear as an encapsulated
option in an IA_DSTM option.
7. Security Considerations
The DSTM Global IPv4 Address option may be used by an intruder DHCP
server to assign an invalid IPv4-mapped address to a DHCPv6 client in
a denial of service attack. The DSTM Tunnel Endpoint option may be
used by an intruder DHCP server to configure a DHCPv6 client with an
endpoint that would cause the client to route packets thorugh an
intruder system.
To avoid these security hazards, a DHCPv6 client MUST use
authenticated DHCPv6 to confirm that it is exchanging the DSTM
options with an authorized DHCPv6 server.
8. IANA Considerations
IANA is requested to assign an option code to this option from the
option-code space defined in section "DHCPv6 Options" of the DHCPv6
specification [2].
References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R.
Droms (ed.), "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", draft-ietf-dhc-dhcpv6 (work in progress), April 2002.
[3] Bound, J., "Dual Stack Transition Mechanism (DSTM)", draft-ietf-
ngtrans-dstm (work in progress), November 2001.
[4] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
Authors' Addresses
draft-bound-dstm-exp-00.txt Expires February 2004 [Page 14]
Internet Draft Dual Stack Transition Mechanism August 2003
Bernie Volz
Ericsson
959 Concord Street
Framingham, MA 01701
USA
Phone: +1 508 875 3162
EMail: bernie.volz@ericsson.com
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
Ralph Droms
Cisco Systems
250 Apollo Drive
Chelmsford, MA 01824
USA
Phone: +1 978 497 4733
EMail: rdroms@cisco.com
Ted Lemon
Nominum, Inc.
950 Charter Street
Redwood City, CA 94043
USA
EMail: mellon@nominum.com
draft-bound-dstm-exp-00.txt Expires February 2004 [Page 15]
Internet Draft Dual Stack Transition Mechanism August 2003
Appendix B DSTM Port Options for DHCPv6
Network Working Group Myung-Ki Shin
Internet-Draft ETRI
Expires: December 2002 June 2002
DSTM Ports Option for DHCPv6
draft-ietf-dhc-dhcpv6-opt-dstm-ports-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 pro-
gress."
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 2002.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
The DSTM Ports Option provides DSTM (Dual Stack Transition
Mechanism) configuration information to DHCPv6 hosts.
1. Introduction
This document describes the Ports Option for DHCPv6 [2] that
provide information for hosts using the "Dual Stack Transition
Mechanism" (DSTM) [3].
2. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 [1].
draft-bound-dstm-exp-00.txt Expires February 2004 [Page 16]
Internet Draft Dual Stack Transition Mechanism August 2003
3. Terminology
This document uses terminology specific to IPv6 and DHCPv6 as
defined in section "Terminology" of the DHCPv6 specification.
4. DSTM Ports Option
The DSTM Ports option carries a port range that is to be used for
the associated IPv4-mapped IPv6 address in an IA_DSTM option [5].
The format of the DSTM Ports option is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_DSTM_PORTS | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start port | end port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_DSTM_PORTS (TBD)
option-length: 4
start port: The start port number for the associated IPv4-
mapped IPv6 address.
end port: The end port number for the associated IPv4-
mapped IPv6 address.
A DSTM Ports option MAY be encapsulated in an IA_DSTM option [5] to
specify the port range associted with the IPv4-mapped IPv6 address.
A DSTM Ports option MUST NOT be used except when encapsulated in an
IA_DSTM option [5].
5. Appearance of these options
The DSTM Ports option MUST only appear as an encapsulated option in
an IA_DSTM option [5].
6. Security Considerations
The DSTM Ports option may be used by an intruder DHCP server to
assign an invalid port range to a DHCP client in a denial of
service attack.
To avoid this security hazard, a DHCP client MUST use authenticated
DHCP to confirm that it is exchanging the DSTM options with an
authorized DHCP server.
7. IANA Considerations
IANA is requested to assign an option code to this option from the
draft-bound-dstm-exp-00.txt Expires February 2004 [Page 17]
Internet Draft Dual Stack Transition Mechanism August 2003
option-code space defined in section "DHCP Option" of the DHCPv6
specification [2].
References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R.
Droms (ed.), "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", draft-ietf-dhc-dhcpv6-26 (work in progress), June 2002.
[3] Bound, J., "Dual Stack Transition Mechanism (DSTM)", draft-ietf-
ngtrans-dstm-07 (work in progress), Feburary 2002.
[4] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture",
RFC 2373, July 1998.
[5] Volz, B. et al., "DSTM Options for DHCPv6", draft-ietf-dhc-dhcpv6-
opt-dstm-01.txt, (work in progress), April 2002.
Authors' Addresses
Myung-Ki Shin
ETRI PEC
161 Kajong-Dong, Yusong-Gu, Taejon 305-350, Korea
Tel : +82 42 860 4847
Fax : +82 42 861 5404
E-mail : mkshin@pec.etri.re.kr
Appendix C Tunnel Setup Protocol (TSP)
Network Working Group M. Blanchet
Internet-Draft Viagenie
Expires: December 30, 2002 O. Medina
ENST Bretagne
F. Parent
Viagenie
July 1, 2002
DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup Protocol(TSP)
draft-blanchet-ngtrans-tsp-dstm-profile-01
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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-
draft-bound-dstm-exp-00.txt Expires February 2004 [Page 18]
Internet Draft Dual Stack Transition Mechanism August 2003
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 December 30, 2002.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
Based on the actions they perform, The network model presented in
DSTM [1] defines three types of equipments: a DSTM server, DSTM nodes
and a Tunnel End Point (TEPs). Within this model, a protocol is
required for configuration data exchange among these equipments.
This document presents a method to perform these actions based on TSP
[2].
Blanchet, et al. Expires December 30, 2002 [Page 1]
Internet-Draft DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup
Protocol(TSP) July 2002
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. General Description of the Protocol . . . . . . . . . . . . . 4
2.1 Initial Address Allocation . . . . . . . . . . . . . . . . . . 5
2.2 Allocation Renewal . . . . . . . . . . . . . . . . . . . . . . 6
2.3 End of Allocation . . . . . . . . . . . . . . . . . . . . . . 7
3. TSP Profile for DSTM . . . . . . . . . . . . . . . . . . . . . 7
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Client element . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Server element . . . . . . . . . . . . . . . . . . . . . . . . 8
4. DSTM protocol using TSP . . . . . . . . . . . . . . . . . . . 8
4.1 Initial Address Allocation . . . . . . . . . . . . . . . . . . 8
4.2 Allocation Renewal . . . . . . . . . . . . . . . . . . . . . . 9
4.3 End of Allocation . . . . . . . . . . . . . . . . . . . . . . 11
5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
draft-bound-dstm-exp-00.txt Expires February 2004 [Page 19]
Internet Draft Dual Stack Transition Mechanism August 2003
A. Appendix A. IPv4 over IPv6 tunnel DTD . . . . . . . . . . . . 13
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
Blanchet, et al. Expires December 30, 2002 [Page 2]
Internet-Draft DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup
Protocol(TSP) July 2002
1. Introduction
Based on the actions they perform, The network model presented in
DSTM [1] defines three types of equipments: a DSTM server, DSTM nodes
and a Tunnel End Point (TEPs). Within this model, a protocol is
required for configuration data exchange among these equipments.
This document presents a method to perform these actions based on TSP
[2].
The Tunnel Setup Protocol, TSP, is a protocol designed to negotiate
tunnel information, such as IP addresses, network prefixes and
routing information. TSP provides optional authentication, transport
over IPv6 and redundancy of the service. Other protocols, such as
DHCPv6 [4], can be used to deploy DSTM but, in the short term, such
protocols may be more complex to implement.
The use of TSP for DSTM address allocation and tunnel set up demands
the definition of four types of messages:
o 'Tunnel Create' messages are used to request the establishment of
a 4over6 tunnel between a node and a given TEP. For first-time
draft-bound-dstm-exp-00.txt Expires February 2004 [Page 20]
Internet Draft Dual Stack Transition Mechanism August 2003
requests, tunnel creation implies the allocation of a temporary
IPv4 address to the requesting node. In addition, this type of
message is also used to ask for extension of the validity of an
already allocated address.
o 'Tunnel Delete' messages are sent by the server to destroy an
existing 4over6 tunnel. The server MUST send this type of message
to the client (and to the TEP, if server and TEP are not co-
located) when the allocation timer for a given address expires.
o 'Tunnel Info' messages are sent as a reply to Tunnel Create or
Tunnel Delete requests. This type of message may contain
configuration data to be used by a node, or simply confirm the
creation/deletion of a 4over6 tunnel.
o Finally, Error Messages inform about the impossibility to allocate
a temporary address or establish a 4over6 tunnel.
TSP provides authentication services using SASL [5]. If DSTM client
authentication is required, the DSTM server can be configured to
negotiate with the client the authentication scheme that will be
used. In this mode, only authenticated clients are authorized to
receive an IPv4 address. If no authentication is required, the
ANONYMOUS authentication scheme can be used to allow any client to
receive a temporary IPv4 address.
Blanchet, et al. Expires December 30, 2002 [Page 3]
Internet-Draft DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup
Protocol(TSP) July 2002
2. General Description of the Protocol
Figure 2.1 presents the message exchanges required by DSTM when the
allocation process is started by a DSTM node. In this document we do
not explain the different mechanisms that can be put in place to
detect the need of an IPv4 address in a Dual Stack node. As required
by DSTM, all TSP message exchanges take place in IPv6 using TCP
transport. Remark that exchanges between DSTM Servers and TEPs are
not required if both functionalities are implemented in the same
host.
The allocation process greatly depends on a parameter called
"Lifetime". It specifies the time (in seconds) over which an IPv4
address is assigned to a node, defining implicitly how often requests
for allocation renewals are to be sent.
TSP message exchange starts whenever a DSTM node requires an IPv4
address. The node may start the exchange, but it may also be
possible that DSTM servers send Unsolicited Allocation messages to
nodes. This would be useful for implementations where it is allowed
to originate connections from outside the DSTM domain (probably using
a DNS-ALG). The exact description of this possibility is outside the
draft-bound-dstm-exp-00.txt Expires February 2004 [Page 21]
Internet Draft Dual Stack Transition Mechanism August 2003
scope of this document.
Blanchet, et al. Expires December 30, 2002 [Page 4]
Internet-Draft DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup
Protocol(TSP) July 2002
Address Allocation Process using SAAP
DSTM node DSTM Server TEP
| | |
| Tunnel Create | |
|------------------>| |
| | Tunnel Create |
| |------------------>|
| | Tunnel Info |
| Tunnel Info |<------------------|
|<------------------| |
| | |
| 4over6 tunnel |
|<=====================================>|
| | |
| Tunnel Create | |
|------------------>| |
| Tunnel Info | |
|<------------------| |
| | |
. . .
. . .
draft-bound-dstm-exp-00.txt Expires February 2004 [Page 22]
Internet Draft Dual Stack Transition Mechanism August 2003
. . .
| Tunnel Delete | Tunnel Delete |
|<------------------|------------------>|
| | |
| Tunnel Info | Tunnel Info |
|..................>|<..................|
| | |
As shown in the figure, DSTM makes use of three types of TSP message:
Create, Delete and Info. 'Tunnel Create' messages are sent by a DSTM
node to ask for 4over6 Tunnel Configuration Parameters (implicitly
including the request for a temporary IPv4 address). The same type
of message is used by the DSTM server to configure the TEP and by the
DSTM node to ask for renewal of the allocation. 'Tunnel Info'
messages are usually sent as a reply to a previous 'Tunnel Create'
request. Such a message may also be used to acknowledge the
reception of a 'Tunnel Delete' command. Finally, DSTM servers send
'Tunnel Delete' messages to destroy 4over6 tunnels when the
allocation time for an address expires.
2.1 Initial Address Allocation
As described in TSP [2], the first phase in TSP involves
authentication (which can be ANONYMOUS). If authentication fails, an
'Authentication Failure' error message (type 300) is generated and no
Blanchet, et al. Expires December 30, 2002 [Page 5]
Internet-Draft DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup
Protocol(TSP) July 2002
address is allocated to the requesting node. If authentication
succeeds, TSP enters into command phase and the allocation process
can take place.
As shown on figure 2.1, the address allocation process starts when a
DSTM node sends a 'Tunnel Create' request to the DSTM Server. This
message contains the Link-Local address of the node and the Global
IPv6 address that the node would use to establish the 4over6 tunnel.
No other information is needed.
Next, the DSTM server processes the request. It may result in an
error due to Address Pool exhaustion (error type 306). If an IPv4
address is available, the server configures the TEP using another
'Tunnel Create' message. The message includes the global IPv6 and
the allocated IPv4 addresses of the requesting node.
The TEP MUST be configured to accept TSP messages only from a valid
DSTM server. At the arrival of a 'Tunnel Create' Request, the TEP
updates its IPv4/IPv6 mapping table and sets up the 4over6 tunnel as
requested. If, for some reason, it is not possible to update the
table, or the 4over6 tunnel cannot be set up, the TEP replies with an
error message (error type 307). In that case, the DSTM server SHOULD
forward the error message to the requesting node.
draft-bound-dstm-exp-00.txt Expires February 2004 [Page 23]
Internet Draft Dual Stack Transition Mechanism August 2003
If tunnel configuration succeeds, the DSTM server receives a 'Tunnel
Info' message from the TEP. This message contains the IPv6 and IPv4
addresses of the TEP for the new tunnel.
At this point, the server updates its own tables and sends a 'Tunnel
Info' message to the requesting node. This message contains the
temporary IPv4 address of the node, its period of validity (the 'Life
Time') and address information of the TEP. TEP information MUST be
the same that the TEP provided.
Finally, the IPv4 stack of the node is configured. A 4over6 tunnel
is established between the node and the TEP. An IPv4 default route
is added pointing to the 4over6 tunnel. Communication in IPv4 can
take place. A timer configured with the 'Life Time' parameter
informs the node when to ask for renewal of allocation, if needed.
2.2 Allocation Renewal
As long as an IPv4 address is needed at the node, 'Tunnel Create'
messages are sent to the DSTM Server as a request for allocation
renewal. The frequency of such requests depends on the 'Life Time'
parameter. The temporary IPv4 address for which allocation renewal
is requested MUST be included in the messages.
Blanchet, et al. Expires December 30, 2002 [Page 6]
Internet-Draft DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup
Protocol(TSP) July 2002
Based on the contents of the message and local policy, the server may
reply with a 'Tunnel Info' message. At the node, the reception of
such a message means that allocation time has been extended: the
timer is reset to the value contained in the 'Life Time' field. No
modification is needed in the IPv4 stack nor in the TEP. If
allocation cannot be extended, an error message MUST be sent to the
node (error type 308) and tunnel information MUST be deleted at the
TEP.
2.3 End of Allocation
If properly configured, there will be a time where the node will no
longer need an IPv4 address. At this time, it will stop sending
'Tunnel Create' requests for renewal. At the server, when allocation
time expires, a 'Tunnel Delete' message MUST be sent to both the node
and the corresponding TEP. The server SHOULD NOT wait for an
acknowledge from the node before updating its own tables and deleting
the configuration at the TEP. However, implementations may wait
until the server receives a reply before releasing the address.
A 'Tunnel Delete' message contains the IPv4 and IPv6 addresses of the
node for which the entry in the mapping table is to be deleted. The
TEP MUST stop forwarding packets for that node as a reaction to this
type of message. Depending on implementation, TEPs may acknowledge
tunnel deletion using a 'Tunnel Info' message.
draft-bound-dstm-exp-00.txt Expires February 2004 [Page 24]
Internet Draft Dual Stack Transition Mechanism August 2003
3. TSP Profile for DSTM
This section describes the TSP profile for IPv4 over IPv6 tunnels in
DSTM.
3.1 Overview
The TSP profile uses the included DTD for the XML format of the
message. The DTD (c.f. Annexe) contains the description of the
tunnel XML message. This message is used by a TSP-DSTM compliant
server to provide the necessary information to DSTM nodes and the TEP
in order to establish 4over6 tunnels. Three types of action are
defined in a 'tunnel' message: Create, Delete and Info.
The 'Create' action is used to request a new tunnel or to renew an
address allocation.
The 'Delete' action is used by the server to remove an existing
tunnel from a node and the TEP.
The 'Info' action is used by the server to send tunnel configuration
data. It is also used by nodes and the TEP to acknowledge a previous
Blanchet, et al. Expires December 30, 2002 [Page 7]
Internet-Draft DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup
Protocol(TSP) July 2002
command (Create or Delete).
The 'tunnel' message may have one or two elements:
o client: Client's information
o server: Server's information
Server is used in the context of the other party in the TSP
connection. It can be the DSTM server if the client is the DSTM
node, or the TEP if the client is the DSTM server.
3.2 Client element
The client element contains 'address' elements. The 'address'
element is used to identify the client IPv6 endpoint of the 4over6
tunnel. The client MUST send its link- local and global IPv6
addresses to the server. The server will then return a temporary
IPv4 address inside the 'client' element when the tunnel is created
or allocation is renewed.
3.3 Server element
The 'server' element contains 'address' elements. This element is
used to identify the addresses at the TEP. The 'address' element
provides both IPv4 and IPv6 addresses of the TEP.
draft-bound-dstm-exp-00.txt Expires February 2004 [Page 25]
Internet Draft Dual Stack Transition Mechanism August 2003
4. DSTM protocol using TSP
TSP message exchanges are done using TCP over IPv6 transport. Once
the TCP session is established between the DSTM node and server, it
MAY be kept connected for the duration of the address allocation
lease time. This TCP connection can be used by the server to send
requests to the client on a communication channel already established
(and potentially authenticated) by the client.
This section presents an example of a DSTM host requesting an IPv4
address allocation to a DSTM server. As described in TSP[ref], the
first TSP phase involves authentication (which can be ANONYMOUS)
followed by a command phase that takes care of the allocation
negotiation.
4.1 Initial Address Allocation
Allocation Requests coming from a node consist of a 'tunnel' element
using the attributes action set to 'create' and type set to 'v4v6'.
The 'tunnel' element contains one 'client' element.
Blanchet, et al. Expires December 30, 2002 [Page 8]
Internet-Draft DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup
Protocol(TSP) July 2002
Simple tunnel request made by a 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: 228 CR LF
<tunnel action="create" type="v4v6">
<client>
<address
type="ipv6">fe80:0000:0000:0000:0000:0000:0000:0001</address>
<address
type="ipv6">3ffe:0b00:0c18:ffff:0000:0000:0000:0001</address>
</client>
</tunnel> CR LF
If the allocation request is accepted, the DSTM server will
acknowledge the allocation to the client by sending a 'tunnel'
element with the attribute 'action' set to 'info', 'type' set to
'v4v6' and the 'lifetime' attribute set to the period of validity or
lease time of the allocation. The 'tunnel' element contains 'server'
and 'client' elements.
Server response
draft-bound-dstm-exp-00.txt Expires February 2004 [Page 26]
Internet Draft Dual Stack Transition Mechanism August 2003
S: Content-length: 370 CR LF
200 OK CR LF
<tunnel action="info" type="v4v6" lifetime="1440">
<server>
<address type="ipv4"
length="30">206.123.31.2</address>
<address
type="ipv6">3ffe:b00:c18:ffff:0000:0000:0000:0002</address>
</server>
<client>
<address type="ipv4"
length="30">206.123.31.1</address>
<address
type="ipv6">3ffe:b00:c18:ffff::0000:0000:0000:0001</address>
</client>
</tunnel> CR LF
4.2 Allocation Renewal
A DSTM host asks for renewal of an IPv4 address allocation by sending
a 'Tunnel Create' message to a DSTM server. The request consists of
a 'tunnel' element using the attributes action set to 'create' and
Blanchet, et al. Expires December 30, 2002 [Page 9]
Internet-Draft DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup
Protocol(TSP) July 2002
type set to 'v4v6'. The 'tunnel' element contains one 'client'
element. The temporary IPv4 address for which allocation renewal is
requested MUST be included in the messages.
Renewal of the same client
C:Content-length: 228 CR LF
<tunnel action="create" type="v4v6">
<client>
<address
type="ipv6">fe80:0000:0000:0000:0000:0000:0000:0001</address>
<address
type="ipv6">3ffe:0b00:0c18:ffff:0000:0000:0000:0001</address>
<address type="ipv4"
length="30">206.123.31.1</address>
</client>
</tunnel> CR LF
If the allocation request is accepted, the DSTM server will
acknowledge the renewal to the client by sending a 'tunnel' element
with the attribute 'action' set to 'info', 'type' set to 'v4v6' and
the 'lifetime' attribute set to the period of validity or lease time
of the allocation. No message is sent to the TEP in this case. At
the node, the reception of such a message means that allocation time
has been extended; the timer is reset to the value contained in the
draft-bound-dstm-exp-00.txt Expires February 2004 [Page 27]
Internet Draft Dual Stack Transition Mechanism August 2003
'lifetime' field.
Server's response to the renewal
S: Content-length: 370 CR LF
200 OK CR LF
<tunnel action="info" type="v4v6" lifetime="1440">
<server>
<address type="ipv4"
length="30">206.123.31.2</address>
<address type="ipv6"
length="64">3ffe:b00:c18:ffff:0000:0000:0000:0002</address>
</server>
<client>
<address type="ipv4"
length="30">206.123.31.1</address>
<address type="ipv6"
length="64">3ffe:b00:c18:ffff::0000:0000:0000:0001</address>
</client>
</tunnel> CR LF
Blanchet, et al. Expires December 30, 2002 [Page 10]
Internet-Draft DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup
Protocol(TSP) July 2002
4.3 End of Allocation
A DSTM server uses a 'Tunnel Delete' message to end the IPv4 address
allocation of a client. The release request consists of a 'tunnel'
element using the attributes action set to 'delete' and type set to
'v4v6'. The 'tunnel' element contains 'server' and 'client' elements
representing the address allocation that is released.
Server sending a release request
S: Content-length: 370 CR LF
200 OK CR LF
<tunnel action="delete" type="v4v6">
<server>
<address type="ipv4"
length="30">206.123.31.2</address>
<address type="ipv6"
length="64">3ffe:b00:c18:ffff:0000:0000:0000:0002</address>
</server>
<client>
<address type="ipv4"
length="30">206.123.31.1</address>
<address type="ipv6"
draft-bound-dstm-exp-00.txt Expires February 2004 [Page 28]
Internet Draft Dual Stack Transition Mechanism August 2003
length="64">3ffe:b00:c18:ffff::0000:0000:0000:0001</address>
</client>
</tunnel> CR LF
5. Error Codes
This list describes the error codes used in this document.
300 Authentication failed
306 Address Pool Exhausted
307 Configuration Error at TEP
308 Requested Address Unavailable
309 Invalid IPv6 address
310 IPv4 Invalid Address
6. IANA Considerations
The TUNNELTYPE "v4v6" is registered for this document.
Blanchet, et al. Expires December 30, 2002 [Page 11]
Internet-Draft DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup
Protocol(TSP) July 2002
7. Security
TSP provides authentication services using SASL [RFC2222]. If DSTM
client authentication is required, TSP can be configured at the
server to negotiate with the client the authentication scheme that
will be used.
In the context where the server sends a request to the client, some
form of authentication is required so that the client can be sure
that the request comes from a trusted DSTM server.
This document proposes that in the case where the client initially
authenticates to the DSTM server, this TCP session MAY be kept
connected for the duration of the address allocation lease time.
This TCP connection can be used by the server to send requests to the
client on a communication channel already established by the client.
A more secure solution would be to provide mutual authentication
between the parties.
References
[1] Bound, J., "Dual Stack Transition Mechanism (DSTM)", draft-ietf-
ngtrans-dstm-05 (work in progress), November 2001.
draft-bound-dstm-exp-00.txt Expires February 2004 [Page 29]
Internet Draft Dual Stack Transition Mechanism August 2003
[2] Blanchet, M., "Tunnel Setup Protocol", July 2001.
[3] Hagino, J., "Possible abuse against IPv6 transition
technologies", July 2000.
[4] Droms, R., Perkins, C., Bound, J. and M. Carney, "Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc-
dhcpv6-21 (work in progress), November 2001.
[5] Myers, J., "Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997.
Authors' Addresses
Marc Blanchet
Viagenie
2875 boul. Laurier, bureau 300
Sainte-Foy, QC G1V 2M2
Canada
Phone: +1 418 656 9254
EMail: Marc.Blanchet@viagenie.qc.ca
URI: http://www.viagenie.qc.ca/
Blanchet, et al. Expires December 30, 2002 [Page 12]
Internet-Draft DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup
Protocol(TSP) July 2002
Octavio Medina
ENST Bretagne
BP 78
Cesson Sevigne, Cedex 35512
France
Phone: +33 2 99 12 70 23
EMail: Octavio.Medina@enst-bretagne.fr
URI: http://www.enst-bretagne.fr
Florent Parent
Viagenie
2875 boul. Laurier, bureau 300
Sainte-Foy, QC G1V 2M2
Canada
Phone: +1 418 656 9254
EMail: Florent.Parent@viagenie.qc.ca
URI: http://www.viagenie.qc.ca/
Appendix A. Appendix A. IPv4 over IPv6 tunnel DTD
draft-bound-dstm-exp-00.txt Expires February 2004 [Page 30]
Internet Draft Dual Stack Transition Mechanism August 2003
Blanchet, et al. Expires December 30, 2002 [Page 13]
Internet-Draft DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup
Protocol(TSP) July 2002
DTD
<?xml version="1.0"?>
<!DOCTYPE tunnel [
<!ELEMENT tunnel (server?,client?,broker?)>
<!ATTLIST tunnel action (create|info|list) #REQUIRED >
<!ATTLIST tunnel type (v4v6|broker) #REQUIRED >
<!ATTLIST tunnel lifetime CDATA "1440" >
<!ELEMENT server (address+,router?)>
<!ELEMENT client (address+,router?)>
<!ELEMENT broker (address+)>
<!ELEMENT router (prefix?,dns_server?,as?)>
<!ATTLIST router protocol (rip|bgp) "">
<!ELEMENT dns_server (address+)>
<!ELEMENT as EMPTY>
<!ATTLIST as number CDATA #REQUIRED>
<!ELEMENT prefix (#PCDATA)>
<!ATTLIST prefix length CDATA #REQUIRED>
<!ELEMENT address (#PCDATA)>
<!ATTLIST address type (ipv4|ipv6|dn) #REQUIRED>
<!ATTLIST address length CDATA "">
]>
Blanchet, et al. Expires December 30, 2002 [Page 14]
draft-bound-dstm-exp-00.txt Expires February 2004 [Page 31]
Internet Draft Dual Stack Transition Mechanism August 2003
Internet-Draft DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup
Protocol(TSP) July 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Blanchet, et al. Expires December 30, 2002 [Page 15]
draft-bound-dstm-exp-00.txt Expires February 2004 [Page 32]
Internet Draft Dual Stack Transition Mechanism August 2003
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
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
[1] Droms, R. (ed) "Dynamic Host Configuration Protocol"
RFC 2131, March 1997.
[2] Droms. R. (ed) et. al. "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6), RFC 3315, July 2003.
[3] Durand, Fasano, Guardini, and Lento, "IPv6 Tunnel Broker"
RFC 3053, January 2001.
[4] Vixie P. (ed) et. al. "Dynamic Updates in the Domain Name
System, RFC 2136, April 1997.
draft-bound-dstm-exp-00.txt Expires February 2004 [Page 33]
Internet Draft Dual Stack Transition Mechanism August 2003
Authors 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
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-00.txt Expires February 2004 [Page 34]