One document matched: draft-blanchet-v6ops-tunnelbroker-tsp-04.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc comments="no"?>
<?rfc inline="yes"?>
<?rfc editing="no"?>
<rfc ipr="full3978" docName="draft-blanchet-v6ops-tunnelbroker-tsp-04" category="exp">
<front>
<title abbrev="Tunnel Setup Protocol (TSP)">
IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)</title>
<author initials="M." surname="Blanchet" fullname="Marc Blanchet">
<organization>Viagenie</organization>
<address>
<postal>
<street>2600 boul. Laurier, suite 625</street>
<city>Quebec</city>
<region>QC</region>
<code>G1V 4W1</code>
<country>Canada</country>
</postal>
<phone>+1-418-656-9254</phone>
<email>Marc.Blanchet@viagenie.ca</email>
</address>
</author>
<author initials="F." surname="Parent" fullname="Florent Parent">
<organization>Beon Solutions</organization>
<address>
<postal>
<street></street>
<city>Quebec</city>
<region>QC</region>
<code></code>
<country>Canada</country>
</postal>
<phone>+1 418 353 0857</phone>
<email>Florent.Parent@beon.ca</email>
</address>
</author>
<date month="May" year="2008" />
<area>Operations</area>
<keyword>IPv6</keyword>
<keyword>Tunnel</keyword>
<keyword>Transition</keyword>
<keyword>TSP</keyword>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
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.
</t>
<t>
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 <xref
target="RFC2119" />.
</t>
</section>
<section title="Description of the TSP framework">
<t>
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 <xref
target="W3C.REC-xml-20040204" /> basic messaging over TCP or UDP.
The use of XML gives extensibility and easy option processing.
</t>
<t>
TSP negotiates tunnel parameters between the two tunnel
end-points. Parameters that are always negociated are:
</t>
<t>
<list style="symbols">
<t>
authentication of the users, using any kind of authentication
mechanism (through SASL <xref target="RFC4422" />) including
anonymous
</t>
<t>Tunnel encapsulation
<list>
<t>
IPv6 over IPv4 tunnels <xref target="RFC4213"></xref>
</t>
<t>
IPv4 over IPv6 tunnels <xref target="RFC2473"></xref>
</t>
<t>
IPv6 over UDP-IPv4 tunnels for NAT traversal
</t>
</list>
</t>
<t>
IP address assignment for the tunnel endpoints
</t>
<t>
DNS registration of the IP end point address (AAAA)
</t>
</list>
<t>
Other tunnel parameters that may be negotiated are:
</t>
<list style="symbols">
<t>
Tunnel keep-alive
</t>
<t>
IPv6 prefix assignment when the client is a router
</t>
<t>
DNS delegation of the inverse tree, based on the IPv6 prefix assigned
</t>
<t>
Routing protocols
</t>
</list>
</t>
<t>
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.
</t>
<t>
The TSP connection can be established between two nodes, where each
node can control a tunnel end-point.
</t>
<t>
The nodes involved in the framework are:
<list style="numbers">
<t>the TSP client</t>
<t>client tunnel end-point</t>
<t>the TSP server</t>
<t>server tunnel end-point</t>
</list>
1,3 and 4 form the tunnel broker model <xref target="RFC3053" />,
where 3 is the tunnel broker and 4 is the tunnel server (<xref
target="Broker_Model" />). The tunnel broker may control one or many
tunnel servers. </t>
<t>
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
<xref target="Server_Model"/>
</t>
<figure anchor="Broker_Model" title="Tunnel Setup Protocol used on Tunnel Broker model">
<artwork>
_______________
| TUNNEL BROKER |--> Databases (DNS)
| |
| TSP |
| SERVER |
|_______________|
| |
__________ | | ________
| | | | | |
| TSP |--[TSP]-- +---------| |
| CLIENT | | TUNNEL |--[NETWORK]--
[HOST]--| |<==[CONFIGURED TUNNEL]==>| SERVER |
|___________| | |
|________|
</artwork>
</figure>
<figure anchor="Server_Model" title="Tunnel Setup Protocol used on Tunnel Server model">
<artwork>
___________ ________
| | | TSP |
| TSP |-----------[TSP]---------| SERVER |
| CLIENT | | |--[NETWORK]--
[HOST]--| |<==[CONFIGURED TUNNEL]==>| TUNNEL |
|___________| | SERVER |
|________|
</artwork>
</figure>
<t>
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.
</t>
<section title="NAT Discovery">
<t>
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.
</t>
<t>
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.
</t>
<t>A keep-alive mechanism is also included to keep the NAT
mapping active.</t>
<t>The IPv4 NAT discovery builds the most effective tunnel for all
cases, including in a dynamic situation where the client moves.
</t>
</section>
<section title="Any encapsulation">
<t>
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 <xref
target="I-D.bound-dstm-exp"/>.
</t>
</section>
<section title="Mobility">
<t>
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
(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.
</t>
</section>
</section>
<section title="Advantages of TSP">
<t>
<list style="symbols">
<t>
Tunnels established by TSP are static tunnels, which are more secure
than automated tunnels (<xref target="RFC3964" />). No 3rd party relay
required.
</t>
<t>
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.
</t>
<t>
Prefix assignment supported. Can use provider address space.
</t>
<t>
Signaling protocol flexible and extensible (XML, SASL)
</t>
<t>
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.
</t>
<t>
Discovery of IPv4 NAT in the path, establishing the most optimized
tunnelling technique depending on the discovery.
</t>
</list>
</t>
</section>
<section title="Protocol Description">
<section title="Terminology">
<t>
<list style="hanging">
<t hangText="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.
</t>
<t hangText="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.
</t>
<t hangText="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.
</t>
<t hangText="v6v4:">
IPv6-over-IPv4 tunnel encapsulation
</t>
<t hangText="v6udpv4:">
IPv6-over-UDP-over-IPv4 tunnel encapsulation
</t>
<t hangText="v4v6:">
IPv4-over-IPv6 tunnel encapsulation
</t>
</list>
</t>
</section>
<section title="Topology">
<t>
The following diagrams describe typical TSP scenarios. The goal is to establish
a tunnel between Tunnel client and Tunnel server.
</t>
</section>
<section title="Overview">
<t>
The Tunnel Setup Protocol is initiated from a client node to a
tunnel broker. The Tunnel Setup Protocol has three phases:
</t>
<t>
<list style="hanging">
<t hangText="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.
</t>
<t hangText="Command phase:">
The command phase is where the client requests or updates a
tunnel.
</t>
<t hangText="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.
</t>
</list>
</t>
<t>
For each command sent by a Tunnel Client there is an expected response
by the server.
</t>
<t>
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.
</t>
<figure anchor="Message_sequence" title="Tunnel Setup Protocol exchange">
<artwork>
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) |
</artwork>
</figure>
</section>
<section title="TSP signaling">
<t>
The following sections describes in detail the TSP protocol and the
different phases in the TSP signaling.
</t>
<section title="Signaling transport">
<t>
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. <xref
target="TSP_transport_table" /> shows the transport used for TSP
signaling with possible tunnel encapsulation requested.
</t>
<t>
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).
</t>
<t>
<figure anchor="TSP_transport_table" title="TSP signaling transport">
<artwork>
Tunnel
Encapsulation Valid Valid
Requested Transport Address family
------------------------------------------
v6anyv4 TCP UDP IPv4
v6v4 TCP UDP IPv4
v6udpv4 UDP IPv4
v4v6 TCP UDP IPv6
</artwork>
</figure>
</t>
<t>
Note that the TSP framework allows for other type of encapsulation
to be defined, such as IPv6 over GRE or IPv6 over IPv6.
</t>
<section title="TSP signaling over TCP">
<t>
TSP over TCP is sent over port number 3653 (IANA assigned). TSP
data used during signaling is detailed in the next sections.
<figure anchor="TCP_control_phase_packet" title="Tunnel Setup Protocol packet format (TCP)">
<artwork>
+------+-----------+----------+
| IP | TCP | TSP data |
| | port 3653 | |
+------+-----------+----------+
where IP is IPv4 or IPv6
</artwork>
</figure>
</t>
</section>
<section title="TSP signaling over UDP/v4" anchor="udpv4_signaling">
<t>
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.
<figure anchor="UDP_control_phase_packet" title="Tunnel Setup Protocol packet format (UDP)" >
<artwork>
+------+-----------+------------+----------+
| IPv4 | UDP | TSP header | TSP data |
| | port 3653 | | |
+------+-----------+------------+----------+
</artwork>
</figure>
</t>
<t>
The algorithm used to add reliability to TSP packets sent over UDP is
described in section 22.5 in <xref target="UNP" />.
<figure anchor="TSP_header" title="TSP header for reliable UDP">
<artwork>
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 |
...
</artwork>
</figure>
<list style="hanging">
<t>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
<xref target="v6udpv4_establishment" /> </t>
<t hangText="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.</t>
<t hangText="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.
</t>
<t hangText="TSP data:">
Same as in the TCP/v4 case. Content described in latter sections.
</t>
</list>
</t>
<t>
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.
</t>
</section>
</section>
<section title="Authentication phase">
<t>
The authentication phase has 3 steps :
</t>
<t>
<list style="symbols">
<t>Client's protocol version identification</t>
<t>Server's capability advertisement</t>
<t>Client authentication</t>
</list>
</t>
<t>
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:
</t>
<t>
<list style="empty">
<t> VERSION=2.0.0 CR LF</t>
</list>
</t>
<t>
Version 2.0.0 is the version number of this specification. Version 1.0.0 was
defined in earlier drafts.
<vspace blankLines="1"/>
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.
</t>
<figure anchor="NotSupported_1" title="Example of unsupported client version">
<preamble>Example of an unsupported client version (without a server list)</preamble>
<artwork>
-- Successful TCP Connection --
C:VERSION=0.1 CR LF
S:302 Unsupported client version CR LF
-- Connection closed --
</artwork>
</figure>
<figure anchor="NotSupported_2" title="Example of unsupported client version, with server redirection">
<preamble>Example of a version not supported (with a server list)</preamble>
<artwork>
-- 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 --
</artwork>
</figure>
<t>
If the server supports the version sent by the client, then the server sends a
list of the capabilities supported for authentication and tunnels.
</t>
<t>
<list style="empty">
<t>CAPABILITY TUNNEL=V6V4 TUNNEL=V6UDPV4
AUTH=ANONYMOUS AUTH=PLAIN AUTH=DIGEST-MD5 CR LF</t>
</list>
</t>
<t>
Tunnel types must be registered with IANA and their profiles are defined in
<xref target="IANA"/>. Authentication is done using <xref
target="RFC4422">SASL</xref>. Each authentication mechanism should be a
registered SASL mechanism. Description of such mechanisms is not in the scope
of this document.
</t>
<t>
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.
</t>
<t>
The example in <xref target="Failed_Auth"/> shows a failed
authentication where the tunnel client requests an anonymous
authentication which is not supported by the server.
</t>
<t>
Note that linebreaks and indentation within a "C:" or "S:" are
editorial and not part of the protocol.
</t>
<figure anchor="Failed_Auth" title="Example of failed authentication">
<artwork>
-- 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
</artwork>
</figure>
<t>
<xref target="Successful_Auth"/> shows a successful anonymous
authentication.
</t>
<figure anchor="Successful_Auth" title="Successful anonymous authentication">
<artwork>
-- 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
</artwork>
</figure>
<t>
Digest-MD5 authentication with SASL follows <xref target="RFC2831"
/>. <xref target="Digest_success"/> shows a successgul digest-md5
SASL authentication.
</t>
<figure anchor="Digest_success" title="Successful Digest-MD5 authentication">
<artwork>
-- 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
</artwork>
</figure>
<t>
The base64-decoded version of the SASL exchange is:
</t>
<figure>
<artwork>
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
</artwork>
</figure>
<t>
Once the authentication succeeds, the server sends a success return
code and the protocol enters the Command phase.
</t>
</section>
<section title="Command and response phase" anchor="cmd_response_phase">
<t>
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.
<vspace blankLines="1"/>
Spaces can be inserted freely.
</t>
<figure anchor="command_response_sequence" title="Example of a command/response sequence">
<artwork>
-- 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
</artwork>
</figure>
<t>
The example in <xref target="command_response_sequence" /> 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 (<xref target="keepalive" />). Finally, the
client sends an accept message to the server.
</t>
<t>
Once the accept message has been sent, the server and client
configure their tunnel endpoint based on the negotiated tunnel
parameters.
</t>
</section>
</section>
<section title="Tunnel establishment">
<section title="IPv6-over-IPv4 tunnels">
<t>
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 <xref target="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.
</t>
</section>
<section title="IPv6-over-UDP tunnels" anchor="v6udpv4_establishment">
<t>
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.
<figure anchor="IPv6_over_UDP" title="IPv6 transport over UDP">
<artwork>
+------+-----------+--------+
| IPv4 | UDP | IPv6 |
| hdr. | port 3653 | |
+------+-----------+--------+
</artwork>
</figure>
</t>
<t>
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 <xref
target="udpv4_signaling" />. 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.
</t>
</section>
</section>
<section title="Tunnel Keep-alive" anchor="keepalive">
<t>
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 is in the tunnel path.
</t>
<t>
For IPv6-over-IPv4 and IPv6-over-UDP tunnels, the keep-alive
message is an ICMPv6 echo request <xref target="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
(<xref target="cmd_response_phase" />). The echo message is sent
over the configured tunnel.
</t>
<t>
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.
</t>
<t>
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 <xref target="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.
</t>
</section>
<section title="XML Messaging">
<t>
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 (<xref target="DTD_section"/>).
</t>
<section title="Tunnel">
<t>
The client and server use the tunnel token with an action
attribute. Valid actions for this profile are : 'create',
'delete', 'info', 'accept' and 'reject'.
<list style="hanging">
<t hangText="create:">
action used to request a new tunnel or update an existing
tunnel. Sent by the tunnel client.
</t>
<t hangText="delete:">
action used to remove an existing tunnel from the server. Sent by
the tunnel client.
</t>
<t hangText="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.
</t>
<t hangText="accept:">
action used by the client to acknowledge the server that the tunnel
parameters are accepted. The client will establish a tunnel.
</t>
<t hangText="reject:">
action used by the client to signal the server that the tunnel
parameters offered are rejected and no tunnel will be established.
</t>
</list>
</t>
<t>
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.
</t>
<t>
The 'tunnel' message contains three elements:
</t>
<t>
<list style="hanging">
<t hangText="<client>: ">Client's information</t>
<t hangText="<server>: ">Server's information</t>
<t hangText="<broker>: ">List of other server's</t>
</list>
</t>
</section>
<section title="Client Element">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
Optionally a client MAY send a 'router' element to ask for
a prefix delegation.
</t>
<t>
Optionally, a client MAY send a 'keepalive' element which
contains the keep-alive time interval requested by the client.
</t>
</section>
<section title="Server Element">
<t>
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.
</t>
</section>
<section title="Broker Element">
<t>
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.
</t>
<t>
The 'broker' element contains a series of 'address' element(s).
</t>
</section>
</section>
</section>
<section title="Tunnel request examples">
<t>This section presents multiple examples of requests.</t>
<section title="Host tunnel request and reply">
<t>
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.
</t>
<figure anchor="SimpleRequest" title="Simple tunnel request made by a client">
<artwork>
-- 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
</artwork>
</figure>
</section>
<section title="Router Tunnel request with a /48 prefix delegation, and reply">
<t>
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.
</t>
<figure anchor="StaticRequest" title="Tunnel request with prefix and DNS delegation">
<preamble>Tunnel request with prefix and static
routes.</preamble>
<artwork>
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
</artwork>
</figure>
</section>
<section title="IPv4 over IPv6 tunnel request">
<t>This is similar to the previous 'create' action, but with the
tunnel type is set to 'v4v6'.
</t>
<figure title="Simple tunnel request made by a client">
<artwork>
-- 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
</artwork>
</figure>
<t>
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.
</t>
<figure title="IPv4 over IPv6 tunnel response">
<artwork>
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
</artwork>
</figure>
<t>
In DSTM <xref target="I-D.bound-dstm-exp"/>
terminology, the DSTM server is the TSP broker and the TEP
is the tunnel server.
</t>
</section>
<section title="NAT Traversal tunnel request">
<t>
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.
</t>
<t>
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.
<figure title="Tunnel request using v6anyv4 mode">
<artwork>
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
</artwork>
</figure>
</t>
</section>
</section>
<section title="Applicability of TSP in Different Networks">
<t>
This section describes the applicability of TSP in different networks.
</t>
<section title="Provider Networks with Enterprise Customers">
<t>
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 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.
</t>
</section>
<section title="Provider Networks with Home/Small Office Customers">
<t>
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.
</t>
<t>
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.
</t>
<t>
With the NAT discovery function of TSP, providers can use the same TSP
infrastructure for both NAT and non-NAT parts of the network.
</t>
</section>
<section title="Enterprise Networks">
<t>
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 <xref target="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.
</t>
</section>
<section title="Wireless Networks">
<t>
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.
</t>
<t>
In a wireless network where IPv6 is dominant, hosts and networks
move. TSP enables the automatic re-establishment of the IPv4 over IPv6
tunnel.
</t>
</section>
<section title="Unmanaged networks">
<t>
An unmanaged network is where no network manager or staff is available
to configure network devices <xref target="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.
</t>
<t>
An unmanaged network may be behind a NAT, maybe not. With the NAT
discovery function, TSP works automatically in both cases.
</t>
</section>
<section title="Mobile Hosts and Mobile Networks">
<t>
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.
</t>
<t>
Mobile here means only the change of IPv4 address. Mobile-IP mechanisms
and fast hand-off take care of additional constraints in mobile
environments.
</t>
<t>
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.
</t>
</section>
</section>
<section title="IANA Considerations" anchor="IANA">
<t>
A tunnel type registry should be setup by IANA. The following strings
are defined in this document:
</t>
<t><list style="symbols">
<t>"v6v4" for IPv6 in IPv4 encapsulation (using IPv4 protocol 41)</t>
<t>"v6udpv4" for IPv6 in UDP in IPv4 encapsulation</t>
<t>"v6anyv4" for IPv6 in IPv4 or IPv6 in UDP in IPv4 encapsulation</t>
<t>"v4v6" for IPv4 in IPv6 encapsulation.</t>
</list>
</t>
<t>
Registration of a new tunnel type can be obtained on a first come
first served policy <xref target="RFC2434" />. A new registration
should provide a point of contact, the tunnel type string, and a brief
description on the applicability.
</t>
<t>IANA assigned 3653 as the TSP port number.</t>
</section>
<section title="Security Considerations">
<t>
Authentication of the TSP session uses the SASL <xref target="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.
</t>
<t>
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 <xref target="RFC4213" />.
</t>
<t>
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 <xref target="RFC3704" />.
</t>
<t>
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.
</t>
</section>
<section title="Conclusion">
<t>
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.
</t>
</section>
<section title="Acknowledgements">
<t>
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.</t>
</section>
</middle>
<back>
<references title='Normative References'>
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
</t></list></t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t></abstract></front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='ftp://ftp.isi.edu/in-notes/rfc2119.txt' />
<format type='HTML' octets='14486' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5661' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
<reference anchor='RFC4422'>
<front>
<title>Simple Authentication and Security Layer (SASL)</title>
<author initials='A.' surname='Melnikov' fullname='A. Melnikov'>
<organization /></author>
<author initials='K.' surname='Zeilenga' fullname='K. Zeilenga'>
<organization /></author>
<date year='2006' month='June' /></front>
<seriesInfo name='RFC' value='4422' />
<format type='TXT' octets='73206' target='ftp://ftp.isi.edu/in-notes/rfc4422.txt' />
</reference>
<reference anchor='RFC2831'>
<front>
<title>Using Digest Authentication as a SASL Mechanism</title>
<author initials='P.' surname='Leach' fullname='P. Leach'>
<organization /></author>
<author initials='C.' surname='Newman' fullname='C. Newman'>
<organization /></author>
<date year='2000' month='May' /></front>
<seriesInfo name='RFC' value='2831' />
<format type='TXT' octets='58124' target='ftp://ftp.isi.edu/in-notes/rfc2831.txt' />
</reference>
<reference anchor='RFC4443'>
<front>
<title>Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification</title>
<author initials='A.' surname='Conta' fullname='A. Conta'>
<organization /></author>
<author initials='S.' surname='Deering' fullname='S. Deering'>
<organization /></author>
<author initials='M.' surname='Gupta' fullname='M. Gupta'>
<organization /></author>
<date year='2006' month='March' /></front>
<seriesInfo name='RFC' value='4443' />
<format type='TXT' octets='48969' target='ftp://ftp.isi.edu/in-notes/rfc4443.txt' />
</reference>
<reference anchor='W3C.REC-xml-20040204'>
<front>
<title>Extensible Markup Language (XML) 1.0 (Third Edition)</title>
<author initials='F' surname='Yergeau' fullname='François Yergeau'>
<organization />
</author>
<author initials='J' surname='Paoli' fullname='Jean Paoli'>
<organization />
</author>
<author initials='C' surname='Sperberg-McQueen' fullname='C. M. Sperberg-McQueen'>
<organization />
</author>
<author initials='T' surname='Bray' fullname='Tim Bray'>
<organization />
</author>
<author initials='E' surname='Maler' fullname='Eve Maler'>
<organization />
</author>
<date month='February' day='4' year='2004' />
</front>
<seriesInfo name='W3C REC' value='REC-xml-20040204' />
<format type='HTML' target='http://www.w3.org/TR/2004/REC-xml-20040204' />
</reference>
<reference anchor='RFC4213'>
<front>
<title>Basic Transition Mechanisms for IPv6 Hosts and Routers</title>
<author initials='E.' surname='Nordmark' fullname='E. Nordmark'>
<organization /></author>
<author initials='R.' surname='Gilligan' fullname='R. Gilligan'>
<organization /></author>
<date year='2005' month='October' /></front>
<seriesInfo name='RFC' value='4213' />
<format type='TXT' octets='58575' target='ftp://ftp.isi.edu/in-notes/rfc4213.txt' />
</reference>
<reference anchor='RFC2473'>
<front>
<title abbrev='Generic Packet Tunneling in IPv6'>Generic Packet Tunneling in IPv6 Specification</title>
<author initials='A.' surname='Conta' fullname='Alex Conta'>
<organization>Lucent Technologies Inc.</organization>
<address>
<postal>
<street>300 Baker Ave</street>
<city>Concord</city>
<region>MA</region>
<code>01742-2168</code>
<country>USA</country></postal>
<phone>+1 978 287 2842</phone>
<email>aconta@lucent.com</email></address></author>
<author initials='S.' surname='Deering' fullname='Stephen Deering'>
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 West Tasman Dr</street>
<city>San Jose</city>
<region>CA</region>
<code>95132-1706</code>
<country>USA</country></postal>
<phone>+1-408-527-8213</phone>
<email>deering@cisco.com</email></address></author>
<date year='1998' month='December' />
<area>Internet</area>
<keyword>encapsulate</keyword>
<keyword>internet protocol version 6</keyword>
<keyword>IPv6</keyword>
<keyword>tunnel</keyword>
<abstract>
<t>
This document defines the model and generic mechanisms for IPv6
encapsulation of Internet packets, such as IPv6 and IPv4. The model
and mechanisms can be applied to other protocol packets as well, such
as AppleTalk, IPX, CLNP, or others.
</t></abstract></front>
<seriesInfo name='RFC' value='2473' />
<format type='TXT' octets='77956' target='ftp://ftp.isi.edu/in-notes/rfc2473.txt' />
<format type='HTML' octets='93015' target='http://xml.resource.org/public/rfc/html/rfc2473.html' />
<format type='XML' octets='84253' target='http://xml.resource.org/public/rfc/xml/rfc2473.xml' />
</reference>
</references>
<references title='Informative References'>
<reference anchor='RFC3704'>
<front>
<title>Ingress Filtering for Multihomed Networks</title>
<author initials='F.' surname='Baker' fullname='F. Baker'>
<organization /></author>
<author initials='P.' surname='Savola' fullname='P. Savola'>
<organization /></author>
<date year='2004' month='March' /></front>
<seriesInfo name='BCP' value='84' />
<seriesInfo name='RFC' value='3704' />
<format type='TXT' octets='35942' target='ftp://ftp.isi.edu/in-notes/rfc3704.txt' />
</reference>
<reference anchor='RFC2434'>
<front>
<title abbrev='Guidelines for IANA Considerations'>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author initials='T.' surname='Narten' fullname='Thomas Narten'>
<organization>IBM Corporation</organization>
<address>
<postal>
<street>3039 Cornwallis Ave.</street>
<street>PO Box 12195 - BRQA/502</street>
<street>Research Triangle Park</street>
<street>NC 27709-2195</street></postal>
<phone>919-254-7798</phone>
<email>narten@raleigh.ibm.com</email></address></author>
<author initials='H.T.' surname='Alvestrand' fullname='Harald Tveit Alvestrand'>
<organization>Maxware</organization>
<address>
<postal>
<street>Pirsenteret</street>
<street>N-7005 Trondheim</street>
<country>Norway</country></postal>
<phone>+47 73 54 57 97</phone>
<email>Harald@Alvestrand.no</email></address></author>
<date year='1998' month='October' />
<area>General</area>
<keyword>Internet Assigned Numbers Authority</keyword>
<keyword>IANA</keyword>
<abstract>
<t>
Many protocols make use of identifiers consisting of constants and
other well-known values. Even after a protocol has been defined and
deployment has begun, new values may need to be assigned (e.g., for a
new option type in DHCP, or a new encryption or authentication
algorithm for IPSec). To insure that such quantities have consistent
values and interpretations in different implementations, their
assignment must be administered by a central authority. For IETF
protocols, that role is provided by the Internet Assigned Numbers
Authority (IANA).
</t>
<t>
In order for the IANA to manage a given name space prudently, it
needs guidelines describing the conditions under which new values can
be assigned. If the IANA is expected to play a role in the management
of a name space, the IANA must be given clear and concise
instructions describing that role. This document discusses issues
that should be considered in formulating a policy for assigning
values to a name space and provides guidelines to document authors on
the specific text that must be included in documents that place
demands on the IANA.
</t></abstract></front>
<seriesInfo name='BCP' value='26' />
<seriesInfo name='RFC' value='2434' />
<format type='TXT' octets='25092' target='ftp://ftp.isi.edu/in-notes/rfc2434.txt' />
<format type='HTML' octets='37803' target='http://xml.resource.org/public/rfc/html/rfc2434.html' />
<format type='XML' octets='26924' target='http://xml.resource.org/public/rfc/xml/rfc2434.xml' />
</reference>
<reference anchor='RFC3964'>
<front>
<title>Security Considerations for 6to4</title>
<author initials='P.' surname='Savola' fullname='P. Savola'>
<organization /></author>
<author initials='C.' surname='Patel' fullname='C. Patel'>
<organization /></author>
<date year='2004' month='December' /></front>
<seriesInfo name='RFC' value='3964' />
<format type='TXT' octets='83360' target='ftp://ftp.isi.edu/in-notes/rfc3964.txt' />
</reference>
<reference anchor='RFC3053'>
<front>
<title>IPv6 Tunnel Broker</title>
<author initials='A.' surname='Durand' fullname='A. Durand'>
<organization /></author>
<author initials='P.' surname='Fasano' fullname='P. Fasano'>
<organization /></author>
<author initials='I.' surname='Guardini' fullname='I. Guardini'>
<organization /></author>
<author initials='D.' surname='Lento' fullname='D. Lento'>
<organization /></author>
<date year='2001' month='January' /></front>
<seriesInfo name='RFC' value='3053' />
<format type='TXT' octets='27336' target='ftp://ftp.isi.edu/in-notes/rfc3053.txt' />
</reference>
<reference anchor='I-D.bound-dstm-exp'>
<front>
<title>Dual Stack IPv6 Dominant Transition Mechanism</title>
<author initials='J' surname='Bound' fullname='Jim Bound'><organization /></author>
<author initials='L' surname='Toutain' fullname='Laurent Toutain'><organization /></author>
<author initials='JL' surname='Richier' fullname='Jean-Luc Richier'><organization /></author>
<date month='October' day='17' year='2005' />
</front>
<seriesInfo name='Internet-Draft' value='draft-bound-dstm-exp-04' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-bound-dstm-exp-04.txt' />
</reference>
<reference anchor='RFC4057'>
<front>
<title>IPv6 Enterprise Network Scenarios</title>
<author initials='J.' surname='Bound' fullname='J. Bound'>
<organization /></author>
<date year='2005' month='June' /></front>
<seriesInfo name='RFC' value='4057' />
<format type='TXT' octets='33454' target='ftp://ftp.isi.edu/in-notes/rfc4057.txt' />
</reference>
<reference anchor='RFC3904'>
<front>
<title>Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks</title>
<author initials='C.' surname='Huitema' fullname='C. Huitema'>
<organization /></author>
<author initials='R.' surname='Austein' fullname='R. Austein'>
<organization /></author>
<author initials='S.' surname='Satapati' fullname='S. Satapati'>
<organization /></author>
<author initials='R.' surname='van der Pol' fullname='R. van der Pol'>
<organization /></author>
<date year='2004' month='September' /></front>
<seriesInfo name='RFC' value='3904' />
<format type='TXT' octets='46844' target='ftp://ftp.isi.edu/in-notes/rfc3904.txt' />
</reference>
<reference anchor="UNP">
<front>
<title>Unix Network Programming, 3rd edition</title>
<author initials="R." surname="Stevens" fullname="W. Richard Stevens">
<organization/>
</author>
<author initials="B." surname="Fenner" fullname="Bill Fenner">
<organization/>
</author>
<author initials="A." surname="Rudoff" fullname="Andrew M. Rudoff">
<organization/>
</author>
<date year="2004"/>
</front>
<seriesInfo name="Addison Wesley" value="ISBN 0-13-141155-1"/>
</reference>
<reference anchor="FJ93">
<front>
<title>The Synchronization of Periodic Routing Messages</title>
<author initials="S." surname="Floyd" fullname="Sally Floyd">
<organization>Lawrence Berkeley Laboratory</organization>
</author>
<author initials="V." surname="Jacobson" fullname="Van Jacobson">
<organization>Lawrence Berkeley Laboratory</organization>
</author>
<date year="1993" month="September"/>
</front>
<seriesInfo name="Proceedings of ACM" value="SIGCOMM '93"/>
</reference>
</references>
<section title="The TSP DTD" anchor="DTD_section">
<figure anchor="DTD" title="TSP DTD">
<artwork>
<?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>
]>
</artwork>
</figure>
</section>
<section title="Error codes">
<t>
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.
</t>
<t>
New error messages may be defined in the future. For interoperability
purpose, the error code range to use should be from 300 to 599.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
<vspace blankLines="1"/>
The predefined values are :
<vspace blankLines="1"/>
</t>
<t>
<list style="hanging">
<t hangText="200 Success: ">
Successful operation</t>
<t hangText="300 Authentication failed:">
Invalid userid, password or authentication mechanism.</t>
<t hangText="301 No more tunnels available:">
The server has reached its capacity limit.</t>
<t hangText="302 Unsupported client version:">
The client version is not supported by the server.</t>
<t hangText="303 Unsupported tunnel type:">
The server does not provide the requested tunnel type.</t>
<t hangText="310 Server side error:">
Undefined server error.
</t>
<t hangText="500 Invalid request format or specified length:">
Received request has invalid syntax or truncated
</t>
<t hangText="501 Invalid IPv4 address:">
IPv4 address specified by the client is invalid
</t>
<t hangText="502 Invalid IPv6 address:">
IPv6 address specified by the client is invalid
</t>
<t hangText="506 IPv4 address already used for existing tunnel">
A IPv6-over-IPv4 tunnel already exists using the same IPv4 address
endpoints.
</t>
<t hangText="507 Requested prefix length cannot be assigned">
The requested prefix length cannot be allocated on the server
</t>
<t hangText="521 Request already in progress">
The client tunnel request is being processed by the server. Temporary
error.
</t>
<t hangText="530 Server too busy">
Request cannot be process, insufficient resources. Temporary error.
</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:10:58 |