Network Working Group M. Blanchet
Internet-Draft Hexago
Expires: August 9, 2004 February 9, 2004
IPv6 Tunnel Broker with the Tunnel Setup Protocol(TSP)
draft-blanchet-v6ops-tunnelbroker-tsp-00
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 August 9, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
A tunnel broker with the Tunnel Setup Protocol(TSP) enables the
establishment of tunnels of various inner protocols, such as IPv6 or
IPv4, inside various outer protocols packets, such as IPv4, IPv6 or
UDP over IPv4 for IPv4 NAT traversal. The control protocol (TSP) is
used by the tunnel client to negociate the tunnel with the broker.
The negociation involves authentication, authorization, tunnel
information such as IP addresses, prefixes when the client is a
router, DNS information such as the NS for the inverse zone
corresponding to the delegated prefix, etc. Some parameters may be
proposed by the broker, such as the transport over UDP IPv4 where an
IPv4 NAT is found in the path between the client and the broker. A
mobile node implementing TSP can be connected to both IPv4 and IPv6
Blanchet Expires August 9, 2004 [Page 1]
Internet-Draft Tunnel Setup Protocol(TSP) February 2004
networks whether he is on IPv4, IPv4 behind a NAT or on IPv6. A
tunnel broker may terminate the tunnels on remote tunnel servers or
on itself. This document describes the TSP protocol within the model
of the tunnel broker [3].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Description of the TSP framework . . . . . . . . . . . . . . 4
2.1 NAT Discovery . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Any encapsulation . . . . . . . . . . . . . . . . . . . . . 5
2.3 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Advantages of TSP . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Description . . . . . . . . . . . . . . . . . . . . 6
4.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2 Topology . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4 Authentication phase . . . . . . . . . . . . . . . . . . . . 8
4.5 Command phase . . . . . . . . . . . . . . . . . . . . . . . 9
4.6 XML Messaging . . . . . . . . . . . . . . . . . . . . . . . 10
4.6.1 Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.6.2 Client element . . . . . . . . . . . . . . . . . . . . . . . 11
4.6.3 Server element . . . . . . . . . . . . . . . . . . . . . . . 11
4.6.4 broker element . . . . . . . . . . . . . . . . . . . . . . . 11
4.7 Tunnel request examples . . . . . . . . . . . . . . . . . . 11
4.7.1 Host Tunnel request and Reply . . . . . . . . . . . . . . . 11
4.7.2 Router Tunnel request with a /48 prefix delegation, and
reply . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.7.3 IPv4 in IPv6 tunnel request . . . . . . . . . . . . . . . . 13
4.7.4 NAT Traversal tunnel request . . . . . . . . . . . . . . . . 15
5. Applicability of TSP in Different Environments . . . . . . . 15
5.1 Applicability of TSP in Provider Networks with Enterprise
Customers . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2 Applicability of TSP in Provider Networks with Home/Small
Office Customers . . . . . . . . . . . . . . . . . . . . . . 16
5.3 Applicability of TSP in Enterprise Networks . . . . . . . . 16
5.4 Applicability of TSP in Wireless Networks . . . . . . . . . 16
5.5 Applicability of TSP in Unmanaged networks . . . . . . . . . 16
5.6 Applicability of TSP for Mobile Hosts . . . . . . . . . . . 17
5.7 Applicability of TSP for Mobile Networks . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . 17
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
References . . . . . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . 18
A. DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
B. Error codes . . . . . . . . . . . . . . . . . . . . . . . . 19
Blanchet Expires August 9, 2004 [Page 2]
Internet-Draft Tunnel Setup Protocol(TSP) February 2004
Full Copyright Statement . . . . . . . . . . . . . . . . . . 21
Blanchet Expires August 9, 2004 [Page 3]
Internet-Draft Tunnel Setup Protocol(TSP) February 2004
1. Introduction
This document first describes the TSP framework as well as the
different profiles used. It then describes the applicability of TSP
in different environments, some were described in the v6ops scenario
documents.
2. Description of the TSP framework
Tunnel Setup Protocol (TSP) is a control/signaling protocol to setup
tunnel parameters between two tunnel end-points. TSP is implemented
as a tiny client code in the requesting tunnel end-point. The other
end-point is the TSP server. TSP uses XML basic messaging over TCP
or UDP. The use of XML gives extensibility and easy option
processing.
Inside a session, TSP can negociate between the two tunnel end-
points:
o authentication of the users, using any kind of authentication
mechanism(through SASL [1]) including anonymous
o IPv6 over IPv4 tunnels
o IPv4 over IPv6 tunnels
o IPv6 over UDP-IPv4 tunnels, when IPv4 NAT are in the path between
the two endpoints
o IP address allocation for the tunnel endpoints
o IPv6 prefix assignment when the client is a router and has a
network behind
o DNS delegation of the inverse tree, based on the ipv6 prefix
assignment
o DNS registration of the end point.
o Routing protocols
The TSP connexion can be established between two nodes, where each
node can control a tunnel end-point. In this context, it is possible
to have up to 4 parties involved: 1- the tsp client, 2- controlling
the requesting tunnel end-point, 3- the tsp server, 4- controlling
the receiving tunnel end-point. 1,3 and 4 is the Tunnel Broker
model. 1 and 2 can be on the same node, as well as 3 and 4 can be on
the same node.
Blanchet Expires August 9, 2004 [Page 4]
Internet-Draft Tunnel Setup Protocol(TSP) February 2004
From the point of view of an operating system, TSP is implemented as
a client application which is able to configure network parameters of
the kernel and operating system.
2.1 NAT Discovery
TSP is also used to discover if a NAT is in the path. In this
discovery mode, the client sends a TSP message, containing its source
tunnel information (such as its source IPv4 address) and the request
for the tunnel over UDP-IPv4 to the TSP server. The TSP server
compares the IPv4 source address of the packet with the IPv4 source
address in the TSP messaging. If they differ, a NAT was in the path.
If an IPv4 NAT is discovered, then UDP-IPv4 encapsulation of the IPv6
tunnel is used over the same UDP channel used for TSP, which enables
the use of the same NAT address-port mapping for both the TSP session
and the IPv6 traffic. A keepalive mechanism is also included to keep
the NAT mapping constant. If there is no IPv4 NAT in the path as
verified by the tunnel broker, then usual IPv6 in IPv4 encapsulation
is used.
When the TSP client moves to another network, the same discovery
process is done. This IPv4 NAT discovery builds the most effective
tunnel for all cases, including in a dynamic situation where the
client moves. On the IPv6 layer, if the client have used user
authentication, the same IPv6 address and prefix are kept and re-
established. On the IPv6 layer, there are no mobility seen.
2.2 Any encapsulation
TSP is used to negociate IPv6 over IPv4 tunnels, IPv6 over UDP-IPv4
tunnels and IPv4 over IPv6 tunnels. IPv4 in IPv6 tunnels are used in
the Dual Stack Transition Mechanism (DSTM) together with TSP.
2.3 Mobility
When a tunnel endpoint changes its underlying IP address (i.e.
change of its IPv4 address when doing IPv6 in IPv4 encapsulation),
the keepalive mechanism fail and the TSP client reconnects to the
broker to re-establish the tunnel.
3. Advantages of TSP
o A signaling protocol to establish the tunnel: no need to change
kernels, routing...
o A signaling protocol flexible and extensible
Blanchet Expires August 9, 2004 [Page 5]
Internet-Draft Tunnel Setup Protocol(TSP) February 2004
o one solution to many encapsulation techniques: v6 in v4, v4 in v6,
v6 over udp over v4, ...
o prefix assignment
o dns delegation
o routing negociation
o discovery of IPv4 NAT in the path, establishing the most optimized
tunnelling technique depending on the discovery.
o mobility of the underlying IP node.
o two to four tier tunnel broker model
o stability of the IP address and prefix, enabling applications
needing stable address to be deployed and used.
o Tunnels established by TSP are static tunnels, which are more
secure than automated tunnels
4. Protocol Description
4.1 Terminology
Tunnel Broker (TB) In a Tunnel Broker model, the broker is taking
charge of all communication between Tunnel Servers (TS) and Tunnel
Clients (TC). Tunnel clients query brokers for a tunnel and the
broker find a suitable tunnel server, ask the Tunnel server to
setup the tunnel and send the tunnel information to the Tunnel
Client.
Tunnel Server (TS) Tunnel Servers are providing the specific tunnel
service to a Tunnel Client. It can reveive the tunnel request
from a Tunnel Broker (as in the Tunnel Broker model) or directly
from the Tunnel Client as in the Tunnel Setup Protocol option.
The Tunnel Server is the tunnel end-point.
Tunnel Client (TC) The Tunnel Client is the entity that need a tunnel
for a particular service or connectivity. A Tunnel Client can be
either a host or a router. The tunnel client is the other tunnel
end-point.
Blanchet Expires August 9, 2004 [Page 6]
Internet-Draft Tunnel Setup Protocol(TSP) February 2004
4.2 Topology
The following diagrams describe typical TSP scenarios. The goal is
to establish a tunnel between Tunnel client and Tunnel server.
Tunnel Setup Protocol used on Tunnel Broker model
_______________
| TUNNEL BROKER |--> Databases (dns, whois)
| |
| TSP TSP |
| SERVER CLIENT |
|_______________|
| |
__________ | | ________
| | | | | TSP |
| TSP |--[TSP]-- +--[TSP]--| SERVER |
| CLIENT | | |--[NETWORK]--
[HOST]--| |<==[CONFIGURED TUNNEL]==>| TUNNEL |
|___________| | SERVER |
|________|
Tunnel Setup Protocol used on Tunnel Server model
___________ ________
| | | TSP |
| TSP |-----------[TSP]---------| SERVER |
| CLIENT | | |--[NETWORK]--
[HOST]--| |<==[CONFIGURED TUNNEL]==>| TUNNEL |
|___________| | SERVER |
|________|
4.3 Overview
The Tunnel Setup Protocol has three phases:
Authentication phase: The Authentication phase is when the Tunnel
Brokers/Servers advertises their capability to Tunnel Clients and
when Tunnel clients authenticate to the server.
Command phase: The command phase is where the client requests or
updates a tunnel.
Response phase: The response phase is where the respond to the client
For each command sent by a Tunnel Client their is an expected
response by the server.
Blanchet Expires August 9, 2004 [Page 7]
Internet-Draft Tunnel Setup Protocol(TSP) February 2004
4.4 Authentication phase
The authentication phase has 3 steps :
o Client's protocol version identification
o Server's capability advertisement
o Client authentication
When a TCP (or UDP-reliable) session is established to a Tunnel
Server, the Tunnel Client sends the current protocol version it is
supporting. The version number syntax is:
VERSION=2.0 CR LF
Version 2.0 is the version number of this specification. Version 1.0
was defined in earlier drafts.
If the server doesn't support the protocol version it sends an error
message and closes the session. The server can optionally send a
server list that may support the protocol version of the client.
Example of a Version not supported (without a server list)
-- Successful TCP Connection --
C:VERSION=0.1 CR LF
S:302 Unsupported client version CR LF
-- Connection closed --
Example of a Version not supported (with a server list)
-- Successful TCP Connection --
C:VERSION=1.1 CR LF
S:1302 Unsupported client version CR LF
<tunnel action="list" type="broker">
<broker>
<address type="ipv4">1.2.3.4</address>
</broker>
<broker>
<address type="dn">ts1.isp1.com</address>
</broker>
</tunnel>
-- Connection closed --
If the server supports the version sent by the client, then the
server sends a list of the capabilities supported for authentication
and tunnels.
Blanchet Expires August 9, 2004 [Page 8]
Internet-Draft Tunnel Setup Protocol(TSP) February 2004
CAPABILITY TUNNEL=V6V4 AUTH=DIGEST-MD5 AUTH=ANONYMOUS CR LF
Tunnel types must be registered with IANA and their profiles are
defined in other documents. Authentication is done using SASL [1].
Each authentication mechanism must be a registered SASL mechanism.
Description of such mechanism is not in the scope of this document.
The Tunnel Client can then choose to close the session if none of the
capabilities fits its needs. If the Tunnel Client chooses to
continue, it must authenticate itself to the server using one of the
adevertised mechanism. If the authentication fails the server sends
an error message and closes the session.
Example of failed authentication
-- Successful TCP Connection --
C:VERSION=2.0 CR LF
S:CAPABILITY TUNNEL=V6V4 AUTH=DIGEST-MD5 CR LF
C:AUTHENTICATE ANONYMOUS CR LF
S:300 Authentication failed CR LF
If the authentication succeed, the server sends a success return code
and the protocol enter the Command phase.
Successful authentication
-- Successful TCP Connection --
C:VERSION=2.0 CR LF
S:CAPABILITY TUNNEL=V6V4 AUTH=DIGEST-MD5 AUTH=ANONYMOUS CR LF
C:AUTHENTICATE ANONYMOUS CR LF
S:200 Authentication successful CR LF
Upon successful authentication the protocol enters the command phase
as described in the next section.
4.5 Command phase
The Command phase is where the Tunnel Client send a tunnel request or
a tunnel update to the server. In this phase, commands are sent as
XML messages. The first line is a "Content-length" directive that
tells the size of the following XML message. This makes it easier
for protocol implementation to tell when they got the whole XML
message. When the server sends a response, the first line is the
"Content-length" directive, the second is the return code and third
one is the XML message if any. The size of the response for the
"Content-length" directive is the first character of the return code
line to the last character of the XML message.
Blanchet Expires August 9, 2004 [Page 9]
Internet-Draft Tunnel Setup Protocol(TSP) February 2004
Spaces can be inserted freely.
Example of a command/response sequence
-- Successful TCP Connection --
C:VERSION=2.0 CR LF
S:CAPABILITY TUNNEL=V6V4 AUTH=DIGEST-MD5 AUTH=ANONYMOUS CR LF
C:AUTHENTICATE ANONYMOUS CR LF
S:200 Authentication successful CR LF
C: Content-length: 123 CR LF
<tunnel action="create" type="v6v4">
<client>
<address type="ipv4">1.1.1.1</address>
</client>
</tunnel> CR LF
S: Content-length: 234 CR LF
200 OK CR LF
<tunnel action="info" type="v6v4" lifetime="1440">
<server>
<address type="ipv4">206.123.31.114</address>
<address type="ipv6">3ffe:b00:c18:ffff:0000:0000:0000:0000</address>
</server>
<client>
<address type="ipv4">1.1.1.1</address>
<address type="ipv6">3ffe:b00:c18:ffff::0000:0000:0000:0001</address>
<address type="dn">userid.domain</address>
</client>
</tunnel> CR LF
-- TCP Connection closed --
4.6 XML Messaging
4.6.1 Tunnel
The client uses the tunnel token with an action attribute. Valid
actions for this profile are : 'create', 'info' and 'delete'.
The 'create' action is used to request a new tunnel or update an
existing tunnel. The 'info' action is used to request current
properties of an existing tunnel. The 'delete' action is used to
remove an existing tunnel from the server.
The 'tunnel' message contains three elements:
client Client's information
Blanchet Expires August 9, 2004 [Page 10]
Internet-Draft Tunnel Setup Protocol(TSP) February 2004
server Server's information
broker List of other server's
4.6.2 Client element
The client element contains 2 elements: 'address' and 'router'.
These elements are used to describe the client needs and will be used
by the server to create the appropriate tunnel. This is the only
element sent by a client.
The 'address' element is used to identify the client IPv4 endpoint of
the tunnel. The client MUST send only an IPv4 address to the server.
The server will then return the IPv6 address endpoint and domain name
inside the 'client' element when the tunnel is created or updated.
Optionaly a client can send a 'router' element to ask for a prefix
delegation.
4.6.3 Server element
The 'server' element contains 2 elements: 'address' and 'router'.
These elements are used to describe the server's tunnel endpoint.
The 'address' element is used to provide both IPv4 and IPv6 addresses
of the server's tunnel endpoint, while the 'router' element provides
information for the routing method choosen by the client.
4.6.4 broker element
The 'broker' element is used by a server to provide a alternate list
of servers to a client in the case where the server is not able to
provide the requested tunnel.
The 'broker' element will contain a series of 'address' element.
4.7 Tunnel request examples
This section presents multiple examples of requests.
4.7.1 Host Tunnel request and Reply
A simple tunnel request consist of a 'tunnel' element which contains
only an 'address' element
Blanchet Expires August 9, 2004 [Page 11]
Internet-Draft Tunnel Setup Protocol(TSP) February 2004
Simple tunnel request made by a client.
-- Successful TCP Connection --
C:VERSION=1.0 CR LF
S:CAPABILITY TUNNEL=V6V4 AUTH=ANONYMOUS CR LF
C:AUTHENTICATE ANONYMOUS CR LF
S:200 Authentication successful CR LF
C:Content-length: 123 CR LF
<tunnel action="create" type="v6v4">
<client>
<address type="ipv4">1.1.1.1</address>
</client>
</tunnel> CR LF
S: Content-length: 234 CR LF
200 OK CR LF
<tunnel action="info" type="v6v4" lifetime="1440">
<server>
<address type="ipv4">206.123.31.114</address>
<address type="ipv6">3ffe:b00:c18:ffff:0000:0000:0000:0000</address>
</server>
<client>
<address type="ipv4">1.1.1.1</address>
<address type="ipv6">3ffe:b00:c18:ffff::0000:0000:0000:0001</address>
<address type="dn">userid.domain</address>
</client>
</tunnel> CR LF
4.7.2 Router Tunnel request with a /48 prefix delegation, and reply
A tunnel request with prefix consist of a 'tunnel' element which
contains 'address' element and a 'router' element.
Tunnel request with prefix and static routes.
C: Content-length: 234 CR LF
<tunnel action="create" type="v6v4">
<client>
<address type="ipv4">1.1.1.1</address>
<router>
<prefix length="48"/>
<dns_server>
<address type="ipv4">2.3.4.5</address>
<address type="ipv4">2.3.4.6</address>
<address type="ipv6">3ffe:0c00::1</address>
</dns_server>
</router>
</client>
Blanchet Expires August 9, 2004 [Page 12]
Internet-Draft Tunnel Setup Protocol(TSP) February 2004
</tunnel> CR LF
S: Content-length: 234 CR LF
200 OK CR LF
<tunnel action="info" type="v6v4" lifetime="1440">
<server>
<address type="ipv4">206.123.31.114</address>
<address type="ipv6">3ffe:b00:c18:ffff:0000:0000:0000:0000</address>
</server>
<client>
<address type="ipv4">1.1.1.1</address>
<address type="ipv6">3ffe:b00:c18:ffff::0000:0000:0000:0001</address>
<address type="dn">userid.domain</address>
<router>
<prefix length="48">3ffe:0b00:c18:1234::</prefix>
<dns_server>
<address type="ipv4">2.3.4.5</address>
<address type="ipv4">2.3.4.6</address>
<address type="ipv6">3ffe:0c00::1</address>
</dns_server>
</router>
</client>
</tunnel> CR LF
4.7.3 IPv4 in IPv6 tunnel request
Tunnel type is set to 'v4v6'.
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 broker will acknowledge
the allocation to the client by sending a 'tunnel' element with the
Blanchet Expires August 9, 2004 [Page 13]
Internet-Draft Tunnel Setup Protocol(TSP) February 2004
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
Blanchet Expires August 9, 2004 [Page 14]
Internet-Draft Tunnel Setup Protocol(TSP) February 2004
4.7.4 NAT Traversal tunnel request
-- Successful TCP Connection --
C:VERSION=1.1 CR LF
S:CAPABILITY TUNNEL=V6V4 TUNNEL=V6UDPV4 AUTH=DIGEST-MD5 CR LF
C:AUTHENTICATE ... CR LF
S:200 Authentication successful CR LF
C:Content-length: ... CR LF
<tunnel action="create" type="v6anyv4">
<client>
<address type="ipv4">10.1.1.1</address>
</client>
</tunnel> CR LF
S: Content-length: ... CR LF
200 OK CR LF
<tunnel action="info" type="v6udpv4" lifetime="1440">
<server>
<address type="ipv4">206.123.31.114</address>
<address type="ipv6">3ffe:b00:c18:ffff:0000:0000:0000:0000</address>
</server>
<client>
<address type="ipv4">10.1.1.1</address>
<address type="ipv6">3ffe:b00:c18:ffff::0000:0000:0000:0001</address>
</client>
</tunnel> CR LF
5. Applicability of TSP in Different Environments
This section describes the applicability of TSP in different
environments.
5.1 Applicability of TSP in Provider Networks with Enterprise Customers
In a provider network where IPv4 is dominant, a tunnelled
infrastructure can be used to provider IPv6 services to the
enterprise customers, before a full IPv6 native infrastructure is
built. In order to start deploying in a controlled manner and to
give enterprise customers a prefix, the TSP framework is used. The
TSP server can be put in the core, in the aggregation points or in
the pops to offer the service to the customers. IPv6 over IPv4
encapsulation can be used. If the customers are behind an IPv4 NAT,
then IPv6 over UDP-IPv4 encapsulation can be used. TSP can be used
in combination of other techniques.
Blanchet Expires August 9, 2004 [Page 15]
Internet-Draft Tunnel Setup Protocol(TSP) February 2004
5.2 Applicability of TSP in Provider Networks with Home/Small Office
Customers
In a provider network where IPv4 is dominant, a tunnelled
infrastructure can be used to provider IPv6 services to the home/
small office customers, before a full IPv6 native infrastructure is
built. The small networks such as Home/Small offices have a non-
upgradable gateway with NAT. TSP with NAT traversal is used to offer
IPv6 connectivity and a prefix to the internal network.
Automation of the prefix assignment and DNS delegation, done by TSP,
is a very important feature for a provider in order to substantially
decrease support costs. The provider can use the same authentication
database that is used to authenticate the IPv4 users. Customers can
deploy home IPv6 networks without any intervention of the provider
support people.
With the NAT discovery function of TSP, providers can use the same
TSP infrastructure for both NAT and not-NAT parts of the network.
5.3 Applicability of TSP in Enterprise Networks
In an enterprise network where IPv4 is dominant, a tunnelled
infrastructure can be used to provider IPv6 services to the IPv6
islands (hosts or networks) inside the enterprise, before a full IPv6
native infrastructure is built. TSP can be used to give IPv6
connectivity, prefix and routing for the islands. This gives to the
enterprise a full control deployment of IPv6 while maintaining
automation and permanence of the IPv6 assignments to the islands.
5.4 Applicability of TSP in Wireless Networks
In a wireless network where IPv4 is dominant, hosts and networks move
and change IPv4 address. TSP enables the automatic re-establishment
of the tunnel when the IPv4 address change.
In a wireless network where IPv6 is dominant, hosts and networks
move. TSP enables the automatic re-establishment of the tunnel
together with the DSTM mechasnism.
5.5 Applicability of TSP in Unmanaged networks
An unmanaged network is where no network manager or staff is
available to configure network devices. TSP is particularly powerful
in this context where automation of all necessary information for the
IPv6 connectivity is handled by TSP: tunnel end-points parameters,
prefix assignment, dns delegation, routing.
Blanchet Expires August 9, 2004 [Page 16]
Internet-Draft Tunnel Setup Protocol(TSP) February 2004
An unmanaged network may be behind a NAT, maybe not. With the NAT
discovery function, TSP works automatically in both cases.
5.6 Applicability of TSP for Mobile Hosts
Mobile hosts are common and used. Laptops moving from wireless,
wired in office, home, ... are examples. They often have IPv4
connectivity, but not necessarily IPv6. TSP framework enables the
mobile hosts to have IPv6 connectivity wherever they are, by having
the TSP client sends updated information of the new environment to
the TSP server, when a change occur. Together with NAT discovery,
the mobile host can be always IPv6 connected wherever it is.
Mobile here means only the change of IPv4 address. MobileIP
mechanisms and fast handoff take care of additional constraints in
mobile environments.
5.7 Applicability of TSP for Mobile Networks
Mobile networks share the applicability of the mobile hosts.
Moreover, in the TSP framework, they also keep their prefix
assignment and can control the routing. NAT discovery can also be
used.
6. IANA Considerations
A tunnel type registry should be setup by IANA. The following
strings are defined in this document: "v6v4" for IPv6 in IPv4
encapsulation (using IPv4 protocol 41) "v6udpv4" for IPv6 in UDP in
IPv4 encapsulation "v6anyv4" for IPv6 in IPv4 or IPv6 in UDP in IPv4
encapsulation "v4v6" for IPv4 in IPv6 encapsulation.
Details on the registration procedure for new tokens TBD.
IANA assigned 3653 as the TSP port number.
7. Security Considerations
Authentication of the TSP session uses the SASL[RFC2222] framework,
where the authentication mechanism is negociated between the client
and the server. The framework enables to use the level of
authentication needed for securing the session, based on the
policies.
Static tunnels are created when the TSP negociation is terminated.
Static tunnels are not open gateways and exhibit less security issues
than automated tunnels. Static IPv6 in IPv4 tunnels security
considerations are described in [RFC2893].
Blanchet Expires August 9, 2004 [Page 17]
Internet-Draft Tunnel Setup Protocol(TSP) February 2004
8. Conclusion
The Tunnel Setup Protocol (TSP) is applicable in many environments,
such as: providers, enterprises, wireless, unmanaged networks, mobile
hosts and networks. TSP gives the two tunnel end-points the ability
tonegociate tunnel parameters, as well as prefix assignment, dns
delegation and routing in an authenticated session. It also provides
IPv4 NAT discovery function by using the most effective
encapsulation. It also supports the IPv4 mobility of the nodes.
9. Acknowledgements
This draft is the merge of many previous drafts about TSP. Authors
who have contributed to earlier drafts are: Florent Parent and
Octavio Medina.
References
[1] Myers, J., "Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997.
[2] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6
Hosts and Routers", RFC 2893, August 2000.
[3] Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 Tunnel
Broker", RFC 3053, January 2001.
[4] Bound, J., "Dual Stack Transition Mechanism (DSTM)", draft-ietf-
ngtrans-dstm-08 (work in progress), July 2002.
[5] Hagino, J., "Possible abuse against IPv6 transition
technologies", July 2000.
Author's Address
Marc Blanchet
Hexago
2875 boul. Laurier, suite 300
Sainte-Foy, QC G1V 2M2
Canada
Phone: +1 418 266 5533
EMail: Marc.Blanchet@hexago.com
URI: http://www.hexago.com/
Blanchet Expires August 9, 2004 [Page 18]
Internet-Draft Tunnel Setup Protocol(TSP) February 2004
Appendix A. DTD
<?xml version="1.0"?>
<!DOCTYPE tunnel [
<!ELEMENT tunnel (server?,client?,broker?)>
<!ATTLIST tunnel action (create|info|list) #REQUIRED >
<!ATTLIST tunnel type (v6v4|v4v6|v6anyv4|v6udpv4|broker) #REQUIRED >
<!ATTLIST tunnel lifetime CDATA "1440" >
<!ELEMENT server (address+,router?)>
<!ELEMENT client (address+,router?)>
<!ELEMENT broker (adress+)>
<!ELEMENT router (prefix?,dns_server?,as?)>
<!ELEMENT dns_server (address+)>
<!ELEMENT prefix (#PCDATA)>
<!ATTLIST prefix length CDATA #REQUIRED>
<!ELEMENT address (#PCDATA)>
<!ATTLIST address type (ipv4|ipv6|dn) #REQUIRED>
]>
Appendix B. Error codes
Error codes are sent as a numeric value followed by a text message
describing the code. The Tunnel Setup Protocol defines error code
numbers 1 through 499 and 1000 through 1499. Profile dependant error
codes are defined within the 500 through 999 and 1500 through 1999
range.
The predefined values are :
if a list of tunnel servers is following the error code as a referal
service, then 1000 is added to the error code.
200 Success
Successful operation
300 Authentication failed
Invalid userid, password or authentication mechanism.
Blanchet Expires August 9, 2004 [Page 19]
Internet-Draft Tunnel Setup Protocol(TSP) February 2004
301 No more tunnels available
The server has reached its capacity limit.
302 Unsupported client version
The client version is not supported by the server.
303 Unsupported tunnel type
The server does not provide the requested tunnel type.
306 Address Pool Exhausted
307 Configuration Error at TEP
308 Requested Address Unavailable
309 Invalid IPv6 address
501 Invalid IPv4 address
502 Invalid or duplicate nicname
504 Router function not supported
506 IPv4 prefix already used for existing tunnel
507 Requested prefix length cannot be assigned
509 DNS delegation setup error
514 Protocol error
517 Unsupported router protocol
518 Unsupported prefix length
520 Missing prefix length
Blanchet Expires August 9, 2004 [Page 20]
Internet-Draft Tunnel Setup Protocol(TSP) February 2004
Full Copyright Statement
Copyright (C) The Internet Society (2004). 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 Expires August 9, 2004 [Page 21]