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-
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
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
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
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 | |
|<------------------| |
| | |
. . .
. . .
. . .
| 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.
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.
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.
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
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
'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"
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.
[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
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]
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]