IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)
draft-blanchet-v6ops-tunnelbroker-tsp-04
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 5572.
|
|
|---|---|---|---|
| Authors | Florent Parent , Marc Blanchet | ||
| Last updated | 2020-01-21 (Latest revision 2008-05-06) | ||
| RFC stream | Independent Submission | ||
| Intended RFC status | Experimental | ||
| Formats | |||
| Stream | ISE state | (None) | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 5572 (Experimental) | |
| Action Holders |
(None)
|
||
| Telechat date | (None) | ||
| Responsible AD | Mark Townsley | ||
| Send notices to | (None) |
draft-blanchet-v6ops-tunnelbroker-tsp-04
Network Working Group M. Blanchet
Internet-Draft Viagenie
Intended status: Experimental F. Parent
Expires: November 7, 2008 Beon Solutions
May 6, 2008
IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)
draft-blanchet-v6ops-tunnelbroker-tsp-04
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 7, 2008.
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 negotiate the tunnel with the broker. A
mobile node implementing TSP can be connected to both IPv4 and IPv6
networks whether it is on IPv4 only, IPv4 behind a NAT or on IPv6
only. 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 model.
Blanchet & Parent Expires November 7, 2008 [Page 1]
Internet-Draft Tunnel Setup Protocol (TSP) May 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Description of the TSP framework . . . . . . . . . . . . . . . 4
2.1. NAT Discovery . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Any encapsulation . . . . . . . . . . . . . . . . . . . . 6
2.3. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Advantages of TSP . . . . . . . . . . . . . . . . . . . . . . 7
4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 7
4.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. TSP signaling . . . . . . . . . . . . . . . . . . . . . . 9
4.4.1. Signaling transport . . . . . . . . . . . . . . . . . 9
4.4.2. Authentication phase . . . . . . . . . . . . . . . . . 11
4.4.3. Command and response phase . . . . . . . . . . . . . . 14
4.5. Tunnel establishment . . . . . . . . . . . . . . . . . . . 16
4.5.1. IPv6-over-IPv4 tunnels . . . . . . . . . . . . . . . . 16
4.5.2. IPv6-over-UDP tunnels . . . . . . . . . . . . . . . . 16
4.6. Tunnel Keep-alive . . . . . . . . . . . . . . . . . . . . 16
4.7. XML Messaging . . . . . . . . . . . . . . . . . . . . . . 17
4.7.1. Tunnel . . . . . . . . . . . . . . . . . . . . . . . . 17
4.7.2. Client Element . . . . . . . . . . . . . . . . . . . . 18
4.7.3. Server Element . . . . . . . . . . . . . . . . . . . . 18
4.7.4. Broker Element . . . . . . . . . . . . . . . . . . . . 19
5. Tunnel request examples . . . . . . . . . . . . . . . . . . . 19
5.1. Host tunnel request and reply . . . . . . . . . . . . . . 19
5.2. Router Tunnel request with a /48 prefix delegation,
and reply . . . . . . . . . . . . . . . . . . . . . . . . 20
5.3. IPv4 over IPv6 tunnel request . . . . . . . . . . . . . . 22
5.4. NAT Traversal tunnel request . . . . . . . . . . . . . . . 23
6. Applicability of TSP in Different Networks . . . . . . . . . . 24
6.1. Provider Networks with Enterprise Customers . . . . . . . 24
6.2. Provider Networks with Home/Small Office Customers . . . . 25
6.3. Enterprise Networks . . . . . . . . . . . . . . . . . . . 25
6.4. Wireless Networks . . . . . . . . . . . . . . . . . . . . 25
6.5. Unmanaged networks . . . . . . . . . . . . . . . . . . . . 26
6.6. Mobile Hosts and Mobile Networks . . . . . . . . . . . . . 26
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.1. Normative References . . . . . . . . . . . . . . . . . . . 28
11.2. Informative References . . . . . . . . . . . . . . . . . . 28
Appendix A. The TSP DTD . . . . . . . . . . . . . . . . . . . . . 29
Appendix B. Error codes . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Blanchet & Parent Expires November 7, 2008 [Page 2]
Internet-Draft Tunnel Setup Protocol (TSP) May 2008
Intellectual Property and Copyright Statements . . . . . . . . . . 32
Blanchet & Parent Expires November 7, 2008 [Page 3]
Internet-Draft Tunnel Setup Protocol (TSP) May 2008
1. Introduction
This document first describes the TSP framework, the protocol
details, and the different profiles used. It then describes the
applicability of TSP in different environments, some of which were
described in the v6ops scenario documents.
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 [RFC2119].
2. Description of the TSP framework
Tunnel Setup Protocol (TSP) is a 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 server that will setup the tunnel service. TSP uses XML
[W3C.REC-xml-20040204] basic messaging over TCP or UDP. The use of
XML gives extensibility and easy option processing.
TSP negotiates tunnel parameters between the two tunnel end-points.
Parameters that are always negociated are:
o authentication of the users, using any kind of authentication
mechanism (through SASL [RFC4422]) including anonymous
o Tunnel encapsulation
* IPv6 over IPv4 tunnels [RFC4213]
* IPv4 over IPv6 tunnels [RFC2473]
* IPv6 over UDP-IPv4 tunnels for NAT traversal
o IP address assignment for the tunnel endpoints
o DNS registration of the IP end point address (AAAA)
Other tunnel parameters that may be negotiated are:
o Tunnel keep-alive
o IPv6 prefix assignment when the client is a router
o DNS delegation of the inverse tree, based on the IPv6 prefix
assigned
Blanchet & Parent Expires November 7, 2008 [Page 4]
Internet-Draft Tunnel Setup Protocol (TSP) May 2008
o Routing protocols
The tunnel encapsulation can be explicitly specified by the client,
or can be determined during the TSP exchange by the broker. The
latter is used to detect the presence of NAT in the path and select
IPv6 over UDP-IPv4 encapsulation.
The TSP connection can be established between two nodes, where each
node can control a tunnel end-point.
The nodes involved in the framework are:
1. the TSP client
2. client tunnel end-point
3. the TSP server
4. server tunnel end-point
1,3 and 4 form the tunnel broker model [RFC3053], where 3 is the
tunnel broker and 4 is the tunnel server (Figure 1). The tunnel
broker may control one or many tunnel servers.
In its simplest model, one node is the client configured as a tunnel
end-point (1 and 2 on same node), and the second node is the server
configured as the other tunnel end-point (3 and 4 on same node).
This model is shown in Figure 2
_______________
| TUNNEL BROKER |--> Databases (DNS)
| |
| TSP |
| SERVER |
|_______________|
| |
__________ | | ________
| | | | | |
| TSP |--[TSP]-- +---------| |
| CLIENT | | TUNNEL |--[NETWORK]--
[HOST]--| |<==[CONFIGURED TUNNEL]==>| SERVER |
|___________| | |
|________|
Figure 1: Tunnel Setup Protocol used on Tunnel Broker model
Blanchet & Parent Expires November 7, 2008 [Page 5]
Internet-Draft Tunnel Setup Protocol (TSP) May 2008
___________ ________
| | | TSP |
| TSP |-----------[TSP]---------| SERVER |
| CLIENT | | |--[NETWORK]--
[HOST]--| |<==[CONFIGURED TUNNEL]==>| TUNNEL |
|___________| | SERVER |
|________|
Figure 2: Tunnel Setup Protocol used on Tunnel Server model
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 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 over UDP, containing
its tunnel request information (such as its source IPv4 address) to
the TSP server. The TSP server compares the IPv4 source address of
the packet with the address in the TSP message. If they differ, one
or many IPv4 NAT is in the path.
If an IPv4 NAT is discovered, then IPv6 over UDP-IPv4 tunnel
encapsulation is selected. Once the TSP signaling is done, the
tunnel is established over the same UDP channel used for TSP, so the
same NAT address-port mapping is used for both the TSP session and
the IPv6 traffic. If no IPv4 NAT is detected in the path by the TSP
server, then IPv6 over IPv4 encapsulation is used.
A keep-alive mechanism is also included to keep the NAT mapping
active.
The IPv4 NAT discovery builds the most effective tunnel for all
cases, including in a dynamic situation where the client moves.
2.2. Any encapsulation
TSP is used to negotiate IPv6 over IPv4 tunnels, IPv6 over UDP-IPv4
tunnels and IPv4 over IPv6 tunnels. IPv4 over IPv6 tunnels are used
in the Dual Stack Transition Mechanism (DSTM) together with TSP
[I-D.bound-dstm-exp].
2.3. Mobility
When a node moves to a different IP network (i.e. change of its IPv4
address when doing IPv6 over IPv4 encapsulation), the TSP client
reconnects automatically to the broker to re-establish the tunnel
Blanchet & Parent Expires November 7, 2008 [Page 6]
Internet-Draft Tunnel Setup Protocol (TSP) May 2008
(keep-alive mechanism). On the IPv6 layer, if the client uses user
authentication, the same IPv6 address and prefix are kept and re-
established, even if the IPv4 address or tunnel encapsulation type
changes.
3. Advantages of TSP
o Tunnels established by TSP are static tunnels, which are more
secure than automated tunnels ([RFC3964]). No 3rd party relay
required.
o Stability of the IP address and prefix, enabling applications
needing stable address to be deployed and used. For example, when
tunneling IPv6, there is no dependency on the underlying IPv4
address.
o Prefix assignment supported. Can use provider address space.
o Signaling protocol flexible and extensible (XML, SASL)
o One solution to many encapsulation techniques: v6 in v4, v4 in v6,
v6 over UDP over v4. Can be extended to other encapsulation
types, such as v6 in v6.
o Discovery of IPv4 NAT in the path, establishing the most optimized
tunnelling technique depending on the discovery.
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 finds a suitable tunnel server, asks the Tunnel server to
setup the tunnel and sends the tunnel information to the Tunnel
Client.
Tunnel Server (TS): Tunnel Servers are providing the specific tunnel
service to a Tunnel Client. It can receive the tunnel request
from a Tunnel Broker (as in the Tunnel Broker model) or directly
from the Tunnel Client. The Tunnel Server is the tunnel end-
point.
Blanchet & Parent Expires November 7, 2008 [Page 7]
Internet-Draft Tunnel Setup Protocol (TSP) May 2008
Tunnel Client (TC): The tunnel client is the entity that needs 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.
v6v4: IPv6-over-IPv4 tunnel encapsulation
v6udpv4: IPv6-over-UDP-over-IPv4 tunnel encapsulation
v4v6: IPv4-over-IPv6 tunnel encapsulation
4.2. Topology
The following diagrams describe typical TSP scenarios. The goal is
to establish a tunnel between Tunnel client and Tunnel server.
4.3. Overview
The Tunnel Setup Protocol is initiated from a client node to a tunnel
broker. The Tunnel Setup Protocol has three phases:
Authentication phase: The Authentication phase is when the tunnel
broker/server advertises its capability to a tunnel client and
when a tunnel client authenticate to the broker/server.
Command phase: The command phase is where the client requests or
updates a tunnel.
Response phase: The response phase is where the tunnel client
receives the request response from the tunnel broker/server, and
the client accepts or rejects the tunnel offered.
For each command sent by a Tunnel Client there is an expected
response by the server.
After the response phase is completed, a tunnel is established as
requested by the client. If requested, periodic keep-alive packets
can be sent from the client to the server.
Blanchet & Parent Expires November 7, 2008 [Page 8]
Internet-Draft Tunnel Setup Protocol (TSP) May 2008
tunnel tunnel
client broker
+| Send version +
||---------------------------------> ||
|| Send capabilities ||
||<--------------------------------- +| Authentication
|| SASL authentication || phase
||<--------------------------------> ||
TSP || Authentication OK ||
signaling||<--------------------------------- +
|| Tunnel request || Command
||---------------------------------> || phase
|| Tunnel response +
||<--------------------------------- || Response
|| Tunnel acknowledge || phase
||---------------------------------> +
+| |
|| Tunnel established |
Data ||===================================|
phase || |
+| (keep-alive) |
Figure 3: Tunnel Setup Protocol exchange
4.4. TSP signaling
The following sections describes in detail the TSP protocol and the
different phases in the TSP signaling.
4.4.1. Signaling transport
TSP signaling can be transported over TCP or UDP, and over IPv4 or
IPv6. The tunnel client selects the transport according to the
tunnel encapsulation to be requested. Figure 4 shows the transport
used for TSP signaling with possible tunnel encapsulation requested.
TSP signaling over UDP/v4 MUST be used if a v6 over UDP over IPv4
(v6udpv4) tunnel is to be requested (e.g., for NAT traversal).
Blanchet & Parent Expires November 7, 2008 [Page 9]
Internet-Draft Tunnel Setup Protocol (TSP) May 2008
Tunnel
Encapsulation Valid Valid
Requested Transport Address family
------------------------------------------
v6anyv4 TCP UDP IPv4
v6v4 TCP UDP IPv4
v6udpv4 UDP IPv4
v4v6 TCP UDP IPv6
Figure 4: TSP signaling transport
Note that the TSP framework allows for other type of encapsulation to
be defined, such as IPv6 over GRE or IPv6 over IPv6.
4.4.1.1. TSP signaling over TCP
TSP over TCP is sent over port number 3653 (IANA assigned). TSP data
used during signaling is detailed in the next sections.
+------+-----------+----------+
| IP | TCP | TSP data |
| | port 3653 | |
+------+-----------+----------+
where IP is IPv4 or IPv6
Figure 5: Tunnel Setup Protocol packet format (TCP)
4.4.1.2. TSP signaling over UDP/v4
While TCP provides the connection-oriented and reliable data delivery
features required during the TSP signaling session, UDP does not
offer any reliability. This reliability is added inside the TSP
session as an extra header at the beginning of the UDP payload.
+------+-----------+------------+----------+
| IPv4 | UDP | TSP header | TSP data |
| | port 3653 | | |
+------+-----------+------------+----------+
Figure 6: Tunnel Setup Protocol packet format (UDP)
The algorithm used to add reliability to TSP packets sent over UDP is
described in section 22.5 in [UNP].
Blanchet & Parent Expires November 7, 2008 [Page 10]
Internet-Draft Tunnel Setup Protocol (TSP) May 2008
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xF | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSP data |
...
Figure 7: TSP header for reliable UDP
The four bit field (0-3) is set to 0xF. This marker is used by
the tunnel broker to identify a TSP signaling packets that is sent
after an IPv6 over UDP is established. This is explained in
section Section 4.5.2
Sequence Number: 28 bit field. Set by the tunnel client. Value is
increased by one for every new packet sent to the tunnel broker.
The return packet from the broker contains the unaltered sequence
number.
Timestamp: 32 bit field. Set by the tunnel client. Generated from
the client local time value. The return packet from the broker
contains the unaltered timestamp.
TSP data: Same as in the TCP/v4 case. Content described in latter
sections.
The TSP client builds its UDP packet as described above and sends it
to the tunnel broker. When the tunnel broker responds, the same
values for the sequence number and timestamp MUST be sent back to the
client. The TSP client can use the timestamp to determine the
retransmission timeout (current time minus the packet timestamp).
The client SHOULD retransmit the packet when the retransmission
timeout is reached. The retransmitted packet MUST use the same
sequence number as the original packet so that the server can detect
duplicate packets. The client SHOULD use exponential backoff when
retransmitting packets to avoid network congestion.
4.4.2. Authentication phase
The authentication phase has 3 steps :
o Client's protocol version identification
Blanchet & Parent Expires November 7, 2008 [Page 11]
Internet-Draft Tunnel Setup Protocol (TSP) May 2008
o Server's capability advertisement
o Client authentication
When a TCP or UDP session is established to a tunnel broker, the
tunnel client sends the current protocol version it is supporting.
The version number syntax is:
VERSION=2.0.0 CR LF
Version 2.0.0 is the version number of this specification. Version
1.0.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 an unsupported client version (without a server list)
-- Successful TCP Connection --
C:VERSION=0.1 CR LF
S:302 Unsupported client version CR LF
-- Connection closed --
Figure 8: Example of unsupported client version
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 --
Figure 9: Example of unsupported client version, with server
redirection
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 & Parent Expires November 7, 2008 [Page 12]
Internet-Draft Tunnel Setup Protocol (TSP) May 2008
CAPABILITY TUNNEL=V6V4 TUNNEL=V6UDPV4 AUTH=ANONYMOUS AUTH=PLAIN
AUTH=DIGEST-MD5 CR LF
Tunnel types must be registered with IANA and their profiles are
defined in Section 7. Authentication is done using SASL [RFC4422].
Each authentication mechanism should be a registered SASL mechanism.
Description of such mechanisms 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 authenticates to the server using one of the advertised
mechanism using SASL. If the authentication fails, the server sends
an error message and closes the session.
The example in Figure 10 shows a failed authentication where the
tunnel client requests an anonymous authentication which is not
supported by the server.
Note that linebreaks and indentation within a "C:" or "S:" are
editorial and not part of the protocol.
-- Successful TCP Connection --
C:VERSION=2.0.0 CR LF
S:CAPABILITY TUNNEL=V6V4 AUTH=DIGEST-MD5 CR LF
C:AUTHENTICATE ANONYMOUS CR LF
S:300 Authentication failed CR LF
Figure 10: Example of failed authentication
Figure 11 shows a successful anonymous authentication.
-- Successful TCP Connection --
C:VERSION=2.0.0 CR LF
S:CAPABILITY TUNNEL=V6V4 TUNNEL=V6UDPV4 AUTH=ANONYMOUS AUTH=PLAIN
AUTH=DIGEST-MD5 CR LF
C:AUTHENTICATE ANONYMOUS CR LF
S:200 Success CR LF
Figure 11: Successful anonymous authentication
Digest-MD5 authentication with SASL follows [RFC2831]. Figure 12
shows a successgul digest-md5 SASL authentication.
Blanchet & Parent Expires November 7, 2008 [Page 13]
Internet-Draft Tunnel Setup Protocol (TSP) May 2008
-- Successful TCP Connection --
C:VERSION=2.0.0 CR LF
S:CAPABILITY TUNNEL=V6V4 TUNNEL=V6UDPV4 AUTH=ANONYMOUS AUTH=PLAIN
AUTH=DIGEST-MD5 CR LF
C:AUTHENTICATE DIGEST-MD5 CR LF
S:cmVhbG09aGV4b3Msbm9uY2U9MTExMzkwODk2OCxxb3A9YXV0aCxhbGdvcml0aG09bWQ
1LXNlc3MsY2hhcnNldD11dGY4
C:Y2hhcnNldD11dGY4LHVzZXJuYW1lPSJ1c2VybmFtZTEiLHJlYWxtPSJoZXhvcyIsbm9
uY2U9IjExMTM5MDg5NjgiLG5jPTAwMDAwMDAxLGNub25jZT0iMTExMzkyMzMxMSIsZG
lnZXN0LXVyaT0idHNwL2hleG9zIixyZXNwb25zZT1mOGU0MmIzYzUwYzU5NzcxODUzZ
jYyNzRmY2ZmZDFjYSxxb3A9YXV0aA==
S:cnNwYXV0aD03MGQ1Y2FiYzkyMzU1NjhiZTM4MGJhMmM5MDczODFmZQ==
S:200 Success CR LF
Figure 12: Successful Digest-MD5 authentication
The base64-decoded version of the SASL exchange is:
S:realm="hexos",nonce="1113908968",qop="auth",algorithm=md5-sess,
charset=utf8
C:charset=utf8,username="username1",realm="hexos",nonce="1113908968",
nc=00000001,cnonce="1113923311",digest-uri="tsp/hexos",
response=f8e42b3c50c59771853f6274fcffd1ca,qop=auth
S:rspauth=70d5cabc9235568be380ba2c907381fe
Once the authentication succeeds, the server sends a success return
code and the protocol enters the Command phase.
4.4.3. Command and response 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
indicates the size of the following 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 "Content-length" is calculated from the first character of
the return code line to the last character of the XML message,
inclusively.
Spaces can be inserted freely.
Blanchet & Parent Expires November 7, 2008 [Page 14]
Internet-Draft Tunnel Setup Protocol (TSP) May 2008
-- UDP session established --
C:VERSION=2.0.0 CR LF
S:CAPABILITY TUNNEL=V6V4 TUNNEL=V6UDPV4 AUTH=ANONYMOUS
AUTH=PLAIN AUTH=DIGEST-MD5 CR LF
C:AUTHENTICATE ANONYMOUS CR LF
S:200 Success CR LF
C:Content-length: 205 CR LF
<tunnel action="create" type="v6udpv4">
<client>
<address type="ipv4">192.0.2.135</address>
<keepalive interval="30"></keepalive>
</client>
</tunnel> CR LF
S:Content-length: 501 CR LF
200 Success CR LF
<tunnel action="info" type="v6udpv4" lifetime="604800">
<server>
<address type="ipv4">192.0.2.115</address>
<address type="ipv6">
2001:db8:8000:0000:0000:0000:0000:38b2
</address>
</server>
<client>
<address type="ipv4">192.0.2.135</address>
<address type="ipv6">
2001:db8:8000:0000:0000:0000:0000:38b3
</address>
<keepalive interval="30">
<address type="ipv6">
2001:db8:8000:0000:0000:0000:0000:38b2
</address>
</keepalive>
</client>
</tunnel> CR LF
C:Content-length: 35 CR LF
<tunnel action="accept"></tunnel> CR LF
Figure 13: Example of a command/response sequence
The example in Figure 13 shows a client requesting an anonymous
v6udpv4 tunnel, indicating that a keep-alive packet will be sent
every 30 seconds. The tunnel broker responds with the tunnel
parameters and indicates its acceptance of the keepalive period
(Section 4.6). Finally, the client sends an accept message to the
Blanchet & Parent Expires November 7, 2008 [Page 15]
Internet-Draft Tunnel Setup Protocol (TSP) May 2008
server.
Once the accept message has been sent, the server and client
configure their tunnel endpoint based on the negotiated tunnel
parameters.
4.5. Tunnel establishment
4.5.1. IPv6-over-IPv4 tunnels
Once the TSP signaling is completed, a tunnel can be established on
the tunnel server and client node. If a v6v4 tunnel has been
negotiated, then an IPv6-over-IPv4 tunnel [RFC4213] is established
using the operating system tunneling interface. On the client node,
this is accomplished by the TSP client calling the appropriate OS
commands or system calls.
4.5.2. IPv6-over-UDP tunnels
If a v6udpv4 tunnel is configured, the same source/destination
address and port used during the TSP signaling are used to configure
the v6udpv4 tunnel. If a NAT is in the path between the TSP client
and tunnel broker, the TSP signaling session will have created a UDP
state in the NAT. By reusing the same UDP socket parameters to
transport IPv6, the traffic will flow across the NAT using the same
state.
+------+-----------+--------+
| IPv4 | UDP | IPv6 |
| hdr. | port 3653 | |
+------+-----------+--------+
Figure 14: IPv6 transport over UDP
At any time, a client may re-establish a TSP signaling session. The
client disconnects the current tunnel and starts a new TSP signaling
session as described in Section 4.4.1.2. If a NAT is present and the
new TSP session uses the same UDP mapping in the NAT as for the
tunnel, the tunnel broker will need to disconnect the client tunnel
before the client can establish a new TSP session.
4.6. Tunnel Keep-alive
A TSP client may select to send periodic keep-alive messages to the
server in order to maintain its tunnel connectivity. This allows the
client to detect network changes and enable automatic tunnel re-
establishment. In the case of IPv6-over-UDP tunnels, periodic keep-
alive can help refresh the connection state in a NAT if such device
Blanchet & Parent Expires November 7, 2008 [Page 16]
Internet-Draft Tunnel Setup Protocol (TSP) May 2008
is in the tunnel path.
For IPv6-over-IPv4 and IPv6-over-UDP tunnels, the keep-alive message
is an ICMPv6 echo request [RFC4443] sent from the client to the
tunnel server. The IPv6 destination address of the echo message MUST
be the address from the 'keepalive' element sent in the tunnel
response during the TSP signaling (Section 4.4.3). The echo message
is sent over the configured tunnel.
The tunnel server responds to the ICMPv6 echo requests and can keep
track of which tunnel is active. Any client traffic can also be used
to verify if the tunnel is active. This can be used by the broker to
disconnect tunnels that are no longer in use.
The broker can send a different keep-alive interval from the value
specified in the client request. The client MUST conform to the
broker specified keep-alive interval. The client SHOULD apply a
random "jitter" value to avoid synchronization of keep-alive messages
from many clients to the server [FJ93]. This is achieved by using an
interval value in the range of [0.75T - T], where T is the keep-alive
interval specified by the server.
4.7. XML Messaging
This section describes the XML messaging used in the TSP signaling
during the command and response phase. The XML elements and
attributes are listed in the DTD (Appendix A).
4.7.1. Tunnel
The client and server use the tunnel token with an action attribute.
Valid actions for this profile are : 'create', 'delete', 'info',
'accept' and 'reject'.
create: action used to request a new tunnel or update an existing
tunnel. Sent by the tunnel client.
delete: action used to remove an existing tunnel from the server.
Sent by the tunnel client.
info: action used to request current properties of an existing
tunnel. This action is also used by the tunnel broker to send
tunnel parameters following a client 'create' action.
accept: action used by the client to acknowledge the server that the
tunnel parameters are accepted. The client will establish a
tunnel.
Blanchet & Parent Expires November 7, 2008 [Page 17]
Internet-Draft Tunnel Setup Protocol (TSP) May 2008
reject: action used by the client to signal the server that the
tunnel parameters offered are rejected and no tunnel will be
established.
The tunnel 'lifetime' attribute is set by the tunnel broker and
specifies the lifetime of the tunnel in minutes. The lifetime is an
administratively set value. When a tunnel lifetime is expired, it is
disconnected on the tunnel server.
The 'tunnel' message contains three elements:
<client>: Client's information
<server>: Server's information
<broker>: List of other server's
4.7.2. Client Element
The client element contains 3 sub-elements: 'address', 'router' and
'keepalive'. These elements are used to describe the client request
and will be used by the server to create the appropriate tunnel. The
client element is the only element sent by a client.
The 'address' element is used to identify the client IP endpoint of
the tunnel. When tunneling over IPv4, the client MUST send only its
IPv4 address to the server. When tunneling over IPv6, the client
MUST only send its IPv6 address to the server.
The broker then returns the assigned IPv6 or IPv4 address endpoint
and domain name inside the 'client' element when the tunnel is
created or updated. If supported by the broker, the 'client' element
MAY contain the registered DNS name for the address endpoint assigned
to the client.
Optionally a client MAY send a 'router' element to ask for a prefix
delegation.
Optionally, a client MAY send a 'keepalive' element which contains
the keep-alive time interval requested by the client.
4.7.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 chosen by the client.
Blanchet & Parent Expires November 7, 2008 [Page 18]
Internet-Draft Tunnel Setup Protocol (TSP) May 2008
4.7.4. Broker Element
The 'broker' element is used by a tunnel broker to provide a
alternate list of brokers to a client in the case where the server is
not able to provide the requested tunnel.
The 'broker' element contains a series of 'address' element(s).
5. Tunnel request examples
This section presents multiple examples of requests.
5.1. Host tunnel request and reply
A simple tunnel request consist of a 'tunnel' element which contains
only an 'address' element. The tunnel action is 'create', specifying
a 'v6v4' tunnel encapsulation type. The response sent by the tunnel
broker is an 'info' action. Note that the registered FQDN of the
assigned client IPv6 address is also returned to the tunnel client.
Blanchet & Parent Expires November 7, 2008 [Page 19]
Internet-Draft Tunnel Setup Protocol (TSP) May 2008
-- Successful TCP Connection --
C:VERSION=2.0.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">192.0.2.114</address>
<address type="ipv6">
2001:db8:c18:ffff:0000:0000:0000:0000
</address>
</server>
<client>
<address type="ipv4">1.1.1.1</address>
<address type="ipv6">
2001:db8:c18:ffff::0000:0000:0000:0001
</address>
<address type="dn">userid.domain</address>
</client>
</tunnel> CR LF
C: Content-length: 35 CR LF
<tunnel action="accept"></tunnel> CR LF
Figure 15: Simple tunnel request made by a client
5.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. The 'router'
element also contains the 'dns_server' element which is used to
request DNS delegation of the assigned IPv6 prefix. The 'dns_server'
element lists the IP address of the DNS servers to be registered for
the reverse-mapping zone.
Blanchet & Parent Expires November 7, 2008 [Page 20]
Internet-Draft Tunnel Setup Protocol (TSP) May 2008
Tunnel request with prefix and static routes.
C: Content-length: 234 CR LF
<tunnel action="create" type="v6v4">
<client>
<address type="ipv4">192.0.2.9</address>
<router>
<prefix length="48"/>
<dns_server>
<address type="ipv4">192.0.2.5</address>
<address type="ipv4">192.0.2.4</address>
<address type="ipv6">2001:db8::1</address>
</dns_server>
</router>
</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">192.0.2.114</address>
<address type="ipv6">
2001:db8:c18:ffff:0000:0000:0000:0000
</address>
</server>
<client>
<address type="ipv4">192.0.2.9</address>
<address type="ipv6">
2001:db8:c18:ffff::0000:0000:0000:0001
</address>
<address type="dn">userid.domain</address>
<router>
<prefix length="48">2001:db8:c18:1234::</prefix>
<dns_server>
<address type="ipv4">192.0.2.5</address>
<address type="ipv4">192.0.2.4</address>
<address type="ipv6">2001:db8::1</address>
</dns_server>
</router>
</client>
</tunnel> CR LF
C: Content-length: 35 CR LF
<tunnel action="accept"></tunnel> CR LF
Figure 16: Tunnel request with prefix and DNS delegation
Blanchet & Parent Expires November 7, 2008 [Page 21]
Internet-Draft Tunnel Setup Protocol (TSP) May 2008
5.3. IPv4 over IPv6 tunnel request
This is similar to the previous 'create' action, but with the tunnel
type is set to 'v4v6'.
-- 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">
2001:db8:0c18:ffff:0000:0000:0000:0001
</address>
</client>
</tunnel> CR LF
Simple tunnel request made by a client
If the allocation request is accepted, the broker 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.
Blanchet & Parent Expires November 7, 2008 [Page 22]
Internet-Draft Tunnel Setup Protocol (TSP) May 2008
S: Content-length: 370 CR LF
200 OK CR LF
<tunnel action="info" type="v4v6" lifetime="1440">
<server>
<address type="ipv4" length="30">
192.0.2.2
</address>
<address type="ipv6">
2001:db8:c18:ffff:0000:0000:0000:0002
</address>
</server>
<client>
<address type="ipv4" length="30">
192.0.2.1
</address>
<address type="ipv6">
2001:db8:c18:ffff::0000:0000:0000:0001
</address>
</client>
</tunnel> CR LF
IPv4 over IPv6 tunnel response
In DSTM [I-D.bound-dstm-exp] terminology, the DSTM server is the TSP
broker and the TEP is the tunnel server.
5.4. NAT Traversal tunnel request
When a client is capable of both IPv6 over IPv4 and IPv6 over UDP
over IPv4 encapsulation, it can request the broker, by using the
"v6anyv4" tunnel mode, to determine if it is behind a NAT and to send
the appropriate tunnel encapsulation mode as part of the response.
The client can also explicitly request an IPv6 over UDP over IPv4
tunnel by specifying "v6udpv4" in its request.
In the following example, the client informs the broker that it
requests to send keep-alives every 30 seconds. In its response, the
broker accepted the client suggested keep-alive interval, and the
IPv6 destination address for the keep-alive packets is specified.
Blanchet & Parent Expires November 7, 2008 [Page 23]
Internet-Draft Tunnel Setup Protocol (TSP) May 2008
C:VERSION=2.0.0 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>
<keepalive interval="30"></keepalive>
</client>
</tunnel> CR LF
S: Content-length: ... CR LF
200 OK CR LF
<tunnel action="info" type="v6udpv4" lifetime="1440">
<server>
<address type="ipv4">192.0.2.114</address>
<address type="ipv6">
2001:db8:c18:ffff:0000:0000:0000:0002
</address>
</server>
<client>
<address type="ipv4">10.1.1.1</address>
<address type="ipv6">
2001:db8:c18:ffff::0000:0000:0000:0003
</address>
<keepalive interval="30">
<address type="ipv6">
2001:db8:c18:ffff:0000:0000:0000:0002
</address>
</keepalive>
</client>
</tunnel> CR LF
Tunnel request using v6anyv4 mode
6. Applicability of TSP in Different Networks
This section describes the applicability of TSP in different
networks.
6.1. Provider Networks with Enterprise Customers
In a provider network where IPv4 is dominant, a tunnelled
infrastructure can be used to provide 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
Blanchet & Parent Expires November 7, 2008 [Page 24]
Internet-Draft Tunnel Setup Protocol (TSP) May 2008
server can be 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.
6.2. 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 AAA database
that is used to authenticate the IPv4 broadband 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 non-NAT parts of the network.
6.3. 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 [RFC4057]. 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.
6.4. 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 IPv4 over
IPv6 tunnel.
Blanchet & Parent Expires November 7, 2008 [Page 25]
Internet-Draft Tunnel Setup Protocol (TSP) May 2008
6.5. Unmanaged networks
An unmanaged network is where no network manager or staff is
available to configure network devices [RFC3904]. TSP is
particularly useful 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.
An unmanaged network may be behind a NAT, maybe not. With the NAT
discovery function, TSP works automatically in both cases.
6.6. Mobile Hosts and Mobile Networks
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 send updated information of the new environment to the
TSP server, when a change occurs. Together with NAT discovery and
traversal, the mobile host can be always IPv6 connected wherever it
is.
Mobile here means only the change of IPv4 address. Mobile-IP
mechanisms and fast hand-off take care of additional constraints in
mobile environments.
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.
7. IANA Considerations
A tunnel type registry should be setup by IANA. The following
strings are defined in this document:
o "v6v4" for IPv6 in IPv4 encapsulation (using IPv4 protocol 41)
o "v6udpv4" for IPv6 in UDP in IPv4 encapsulation
o "v6anyv4" for IPv6 in IPv4 or IPv6 in UDP in IPv4 encapsulation
o "v4v6" for IPv4 in IPv6 encapsulation.
Registration of a new tunnel type can be obtained on a first come
first served policy [RFC2434]. A new registration should provide a
point of contact, the tunnel type string, and a brief description on
Blanchet & Parent Expires November 7, 2008 [Page 26]
Internet-Draft Tunnel Setup Protocol (TSP) May 2008
the applicability.
IANA assigned 3653 as the TSP port number.
8. Security Considerations
Authentication of the TSP session uses the SASL [RFC4422] framework,
where the authentication mechanism is negotiated between the client
and the server. The framework uses the level of authentication
needed for securing the session, based on the policies.
Static tunnels are created when the TSP negotiation 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 [RFC4213].
In order to help ensure that the traffic is traceable to its correct
source network, a tunnel server implementation should allow ingress
filtering on the user tunnel [RFC3704].
A customer A behind a NAT can use a large number of (private) IPv4
addresses and/or source ports and request multiple v6udpv4 tunnels.
That would quickly saturate the tunnel server capacity. The tunnel
broker implementation should offer a way to throttle and limit the
number of tunnel established to the same IPv4 address.
9. 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
to negotiate 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.
10. Acknowledgements
This draft is the merge of many previous drafts about TSP. Octavio
Medina has contributed to an earlier draft (IPv4 in IPv6). Thanks to
the following people for comments on improving and clarifying this
document: Pekka Savola, Alan Ford, Jeroen Massar and Jean-Francois
Tremblay.
Blanchet & Parent Expires November 7, 2008 [Page 27]
Internet-Draft Tunnel Setup Protocol (TSP) May 2008
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a
SASL Mechanism", RFC 2831, May 2000.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
[W3C.REC-xml-20040204]
Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T.,
and E. Maler, "Extensible Markup Language (XML) 1.0 (Third
Edition)", W3C REC REC-xml-20040204, February 2004.
11.2. Informative References
[FJ93] Floyd, S. and V. Jacobson, "The Synchronization of
Periodic Routing Messages", Proceedings of ACM SIGCOMM
'93, September 1993.
[I-D.bound-dstm-exp]
Bound, J., Toutain, L., and JL. Richier, "Dual Stack IPv6
Dominant Transition Mechanism", draft-bound-dstm-exp-04
(work in progress), October 2005.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
Tunnel Broker", RFC 3053, January 2001.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
Blanchet & Parent Expires November 7, 2008 [Page 28]
Internet-Draft Tunnel Setup Protocol (TSP) May 2008
[RFC3904] Huitema, C., Austein, R., Satapati, S., and R. van der
Pol, "Evaluation of IPv6 Transition Mechanisms for
Unmanaged Networks", RFC 3904, September 2004.
[RFC3964] Savola, P. and C. Patel, "Security Considerations for
6to4", RFC 3964, December 2004.
[RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057,
June 2005.
[UNP] Stevens, R., Fenner, B., and A. Rudoff, "Unix Network
Programming, 3rd edition", Addison Wesley ISBN 0-13-
141155-1, 2004.
Appendix A. The TSP DTD
<?xml version="1.0"?>
<!DOCTYPE tunnel [
<!ELEMENT tunnel (server?,client?,broker?)>
<!ATTLIST tunnel action
(create|delete|info|accept|reject) #REQUIRED >
<!ATTLIST tunnel type
(v6v4|v4v6|v6anyv4|v6udpv4) #REQUIRED >
<!ATTLIST tunnel lifetime CDATA "1440" >
<!ELEMENT server (address+,router?)>
<!ELEMENT client (address+,router?)>
<!ELEMENT broker (address+)>
<!ELEMENT router (prefix?,dns_server?)>
<!ELEMENT dns_server (address+)>
<!ELEMENT prefix (#PCDATA)>
<!ATTLIST prefix length CDATA #REQUIRED>
<!ELEMENT address (#PCDATA)>
<!ATTLIST address type (ipv4|ipv6|dn) #REQUIRED>
<!ATTLIST address length CDATA "">
<!ELEMENT keepalive (address?)>
<!ATTLIST keepalive interval CDATA #REQUIRED>
]>
Figure 17: TSP DTD
Blanchet & Parent Expires November 7, 2008 [Page 29]
Internet-Draft Tunnel Setup Protocol (TSP) May 2008
Appendix B. Error codes
Error codes are sent as a numeric value followed by a text message
describing the code, similar to SMTP. The codes are sent from the
broker to the client. The currently defined error codes are showned
below. Upon receiving an error, the client will display the
appropriate message to the user.
New error messages may be defined in the future. For
interoperability purpose, the error code range to use should be from
300 to 599.
The reply code 200 is used to inform the client that an action
successfully completed. For example, this reply code is used in
response to an authentication request and a tunnel creation request.
The server may redirect the client to another broker. The details on
how these brokers are knowned or discovered is beyond the scope of
this document. When a list of tunnel brokers follows the error code
as a referal service, then 1000 is added to the error code.
The predefined values are :
200 Success: Successful operation
300 Authentication failed: Invalid userid, password or
authentication mechanism.
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.
310 Server side error: Undefined server error.
500 Invalid request format or specified length: Received request has
invalid syntax or truncated
501 Invalid IPv4 address: IPv4 address specified by the client is
invalid
Blanchet & Parent Expires November 7, 2008 [Page 30]
Internet-Draft Tunnel Setup Protocol (TSP) May 2008
502 Invalid IPv6 address: IPv6 address specified by the client is
invalid
506 IPv4 address already used for existing tunnel A IPv6-over-IPv4
tunnel already exists using the same IPv4 address endpoints.
507 Requested prefix length cannot be assigned The requested prefix
length cannot be allocated on the server
521 Request already in progress The client tunnel request is being
processed by the server. Temporary error.
530 Server too busy Request cannot be process, insufficient
resources. Temporary error.
Authors' Addresses
Marc Blanchet
Viagenie
2600 boul. Laurier, suite 625
Quebec, QC G1V 4W1
Canada
Phone: +1-418-656-9254
Email: Marc.Blanchet@viagenie.ca
Florent Parent
Beon Solutions
Quebec, QC
Canada
Phone: +1 418 353 0857
Email: Florent.Parent@beon.ca
Blanchet & Parent Expires November 7, 2008 [Page 31]
Internet-Draft Tunnel Setup Protocol (TSP) May 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Blanchet & Parent Expires November 7, 2008 [Page 32]