summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5572.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5572.txt')
-rw-r--r--doc/rfc/rfc5572.txt1795
1 files changed, 1795 insertions, 0 deletions
diff --git a/doc/rfc/rfc5572.txt b/doc/rfc/rfc5572.txt
new file mode 100644
index 0000000..df6590c
--- /dev/null
+++ b/doc/rfc/rfc5572.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Independent Submission M. Blanchet
+Request for Comments: 5572 Viagenie
+Category: Experimental F. Parent
+ISSN: 2070-1721 Beon Solutions
+ February 2010
+
+
+ IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)
+
+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 within the
+ model of the tunnel broker model.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for examination, experimental implementation, and
+ evaluation.
+
+ This document defines an Experimental Protocol for the Internet
+ community. This is a contribution to the RFC Series, independently
+ of any other RFC stream. The RFC Editor has chosen to publish this
+ document at its discretion and makes no statement about its value for
+ implementation or deployment. Documents approved for publication by
+ the RFC Editor are not a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc5572.
+
+IESG Note
+
+ The content of this RFC was at one time considered by the IETF, and
+ therefore it may resemble a current IETF work in progress or a
+ published IETF work.
+
+
+
+
+
+
+Blanchet & Parent Experimental [Page 1]
+
+RFC 5572 Tunnel Setup Protocol (TSP) February 2010
+
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blanchet & Parent Experimental [Page 2]
+
+RFC 5572 Tunnel Setup Protocol (TSP) February 2010
+
+
+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 .....................................19
+ 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 ..........................................30
+ Appendix B. Error Codes ..........................................31
+
+
+
+
+Blanchet & Parent Experimental [Page 3]
+
+RFC 5572 Tunnel Setup Protocol (TSP) February 2010
+
+
+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 set up tunnel
+ parameters between two tunnel endpoints. TSP is implemented as a
+ tiny client code in the requesting tunnel endpoint. The other
+ endpoint is the server that will set up the tunnel service. TSP uses
+ XML [W3C.REC-xml-2004] basic messaging over TCP or UDP. The use of
+ XML gives extensibility and easy option processing.
+
+ TSP negotiates tunnel parameters between the two tunnel endpoints.
+ Parameters that are always negotiated are:
+
+ o Authentication of the users, using any kind of authentication
+ mechanism (through Simple Authentication and Security Layer (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 endpoint 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 Experimental [Page 4]
+
+RFC 5572 Tunnel Setup Protocol (TSP) February 2010
+
+
+ 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 endpoint.
+
+ The nodes involved in the framework are:
+
+ 1. the TSP client
+
+ 2. the client tunnel endpoint
+
+ 3. the TSP server
+
+ 4. the server tunnel endpoint
+
+ 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
+ endpoint (1 and 2 on the same node), and the second node is the
+ server configured as the other tunnel endpoint (3 and 4 on the 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 Experimental [Page 5]
+
+RFC 5572 Tunnel Setup Protocol (TSP) February 2010
+
+
+ ___________ ________
+ | | | 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 that 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 NATs are 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 is used
+ in the Dual-Stack Transition Mechanism (DSTM) together with TSP
+ [DSTM].
+
+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 Experimental [Page 6]
+
+RFC 5572 Tunnel Setup Protocol (TSP) February 2010
+
+
+ (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 third-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: IPv6 in IPv4, IPv4
+ in IPv6, IPv6 over UDP over IPv4. Can be extended to other
+ encapsulation types, such as IPv6 in IPv6.
+
+ o Discovery of IPv4 NAT in the path, establishing the most optimized
+ tunneling technique depending on the discovery.
+
+4. Protocol Description
+
+4.1. Terminology
+
+ Tunnel Broker: In a tunnel broker model, the broker is taking charge
+ of all communication between tunnel servers (TSs) and tunnel
+ clients (TCs). Tunnel clients query brokers for a tunnel and the
+ broker finds a suitable tunnel server, asks the tunnel server to
+ set up the tunnel, and sends the tunnel information to the tunnel
+ Client.
+
+ Tunnel Server: 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 endpoint.
+
+ Tunnel Client: 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
+ endpoint.
+
+
+
+
+Blanchet & Parent Experimental [Page 7]
+
+RFC 5572 Tunnel Setup Protocol (TSP) February 2010
+
+
+ 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 from 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 Experimental [Page 8]
+
+RFC 5572 Tunnel Setup Protocol (TSP) February 2010
+
+
+ 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 describe in detail the TSP 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 being 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 Experimental [Page 9]
+
+RFC 5572 Tunnel Setup Protocol (TSP) February 2010
+
+
+ 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 Generic Routing Encapsulation (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 of [UNP].
+
+
+
+
+
+
+
+Blanchet & Parent Experimental [Page 10]
+
+RFC 5572 Tunnel Setup Protocol (TSP) February 2010
+
+
+ 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 4-bit field (0-3) is set to 0xF. This marker is used by the
+ tunnel broker to identify a TSP signaling packet that is sent
+ after an IPv6 over UDP is established. This is explained in
+ 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 later
+ 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 Experimental [Page 11]
+
+RFC 5572 Tunnel Setup Protocol (TSP) February 2010
+
+
+ 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 documents.
+
+ 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 Experimental [Page 12]
+
+RFC 5572 Tunnel Setup Protocol (TSP) February 2010
+
+
+ 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 fit its needs. If the tunnel client chooses to
+ continue, it authenticates to the server using one of the advertised
+ mechanisms 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 that 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
+
+
+
+
+
+
+
+
+
+
+
+
+Blanchet & Parent Experimental [Page 13]
+
+RFC 5572 Tunnel Setup Protocol (TSP) February 2010
+
+
+ Digest-MD5 authentication with SASL follows [RFC2831]. Figure 12
+ shows a successful digest-MD5 SASL 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 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 sends 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 Experimental [Page 14]
+
+RFC 5572 Tunnel Setup Protocol (TSP) February 2010
+
+
+ -- 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
+
+
+
+
+
+
+Blanchet & Parent Experimental [Page 15]
+
+RFC 5572 Tunnel Setup Protocol (TSP) February 2010
+
+
+ parameters and indicates its acceptance of the keep-alive period
+ (Section 4.6). Finally, the client sends an accept message to the
+ 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 complete, 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 the 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
+
+
+
+Blanchet & Parent Experimental [Page 16]
+
+RFC 5572 Tunnel Setup Protocol (TSP) February 2010
+
+
+ re-establishment. In the case of IPv6-over-UDP tunnels, periodic
+ keep-alive messages can help refresh the connection state in a NAT if
+ such a device 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.
+
+
+
+
+
+
+Blanchet & Parent Experimental [Page 17]
+
+RFC 5572 Tunnel Setup Protocol (TSP) February 2010
+
+
+ accept: action used by the client to acknowledge the server that the
+ tunnel parameters are accepted. The client will establish a
+ tunnel.
+
+ 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 has 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 servers
+
+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 that contains the
+ keep-alive time interval requested by the client.
+
+
+
+
+
+
+
+Blanchet & Parent Experimental [Page 18]
+
+RFC 5572 Tunnel Setup Protocol (TSP) February 2010
+
+
+4.7.3. Server Element
+
+ The 'server' element contains two 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.
+
+4.7.4. Broker Element
+
+ The 'broker' element is used by a tunnel broker to provide an
+ 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 an 'address' element or a series of
+ 'address' elements.
+
+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 that 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 Fully-Qualified
+ Domain Name (FQDN) of the assigned client IPv6 address is also
+ returned to the tunnel client.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blanchet & Parent Experimental [Page 19]
+
+RFC 5572 Tunnel Setup Protocol (TSP) February 2010
+
+
+ -- 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 a prefix consists of a 'tunnel' element that
+ contains an 'address' element and a 'router' element. The 'router'
+ element also contains the 'dns_server' element that is used to
+ request a 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 Experimental [Page 20]
+
+RFC 5572 Tunnel Setup Protocol (TSP) February 2010
+
+
+ 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 Experimental [Page 21]
+
+RFC 5572 Tunnel Setup Protocol (TSP) February 2010
+
+
+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
+
+ Figure 17: 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 Experimental [Page 22]
+
+RFC 5572 Tunnel Setup Protocol (TSP) February 2010
+
+
+ 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
+
+ Figure 18: IPv4 over IPv6 Tunnel Response
+
+ In DSTM [DSTM] terminology, the DSTM server is the TSP broker and the
+ Tunnel Endpoint (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 Experimental [Page 23]
+
+RFC 5572 Tunnel Setup Protocol (TSP) February 2010
+
+
+ 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
+
+ Figure 19: 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 tunneled
+ 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 Points
+
+
+
+Blanchet & Parent Experimental [Page 24]
+
+RFC 5572 Tunnel Setup Protocol (TSP) February 2010
+
+
+ of Presence (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 with other techniques.
+
+6.2. Provider Networks with Home/Small Office Customers
+
+ In a provider network where IPv4 is dominant, a tunneled
+ infrastructure can be used to provide IPv6 services to the home/small
+ office customers, before a full IPv6 native infrastructure is built.
+ The small networks such as Home/Small offices have a non-upgradable
+ gateway with NAT. TSP with NAT traversal is used to offer IPv6
+ connectivity and a prefix to the internal network.
+
+ Automation of the prefix assignment and DNS delegation, done by TSP,
+ is a very important feature for a provider in order to substantially
+ decrease support costs. The provider can use the same
+ Authentication, Authorization, and Accounting (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 tunneled
+ infrastructure can be used to provide 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
+ the enterprise a fully controlled 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 changes.
+
+ 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 Experimental [Page 25]
+
+RFC 5572 Tunnel Setup Protocol (TSP) February 2010
+
+
+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
+ endpoint parameters, prefix assignment, DNS delegation, and routing.
+
+ An unmanaged network may (or may not) be behind a NAT. 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 an office, home, etc., are examples. They often have IPv4
+ connectivity, but not necessarily IPv6. The 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 always be 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 has been created 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 [RFC5226]. A new registration should provide a
+ point of contact, the tunnel type string, and a brief description on
+ the applicability.
+
+
+
+Blanchet & Parent Experimental [Page 26]
+
+RFC 5572 Tunnel Setup Protocol (TSP) February 2010
+
+
+ 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 tunnel 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 endpoints the ability
+ to negotiate tunnel parameters, as well as prefix assignment, DNS
+ delegation and routing in an authenticated session. It also provides
+ an IPv4 NAT discovery function by using the most effective
+ encapsulation. It also supports the IPv4 mobility of the nodes.
+
+10. Acknowledgements
+
+ This document is the merge of many previous documents about TSP.
+ Octavio Medina has contributed to an earlier document (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 Experimental [Page 27]
+
+RFC 5572 Tunnel Setup Protocol (TSP) February 2010
+
+
+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-2004] 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
+
+ [DSTM] Bound, J., Toutain, L., and JL. Richier, "Dual
+ Stack IPv6 Dominant Transition Mechanism", Work
+ in Progress, October 2005.
+
+ [FJ93] Floyd, S. and V. Jacobson, "The Synchronization
+ of Periodic Routing Messages", Proceedings of
+ ACM SIGCOMM, September 1993.
+
+ [RFC3053] Durand, A., Fasano, P., Guardini, I., and D.
+ Lento, "IPv6 Tunnel Broker", RFC 3053,
+ January 2001.
+
+
+
+
+Blanchet & Parent Experimental [Page 28]
+
+RFC 5572 Tunnel Setup Protocol (TSP) February 2010
+
+
+ [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for
+ Multihomed Networks", BCP 84, RFC 3704,
+ March 2004.
+
+ [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.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for
+ Writing an IANA Considerations Section in RFCs",
+ BCP 26, RFC 5226, May 2008.
+
+ [UNP] Stevens, R., Fenner, B., and A. Rudoff, "Unix
+ Network Programming, 3rd edition", Addison
+ Wesley ISBN 0-13-141155-1, 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blanchet & Parent Experimental [Page 29]
+
+RFC 5572 Tunnel Setup Protocol (TSP) February 2010
+
+
+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 20: TSP DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blanchet & Parent Experimental [Page 30]
+
+RFC 5572 Tunnel Setup Protocol (TSP) February 2010
+
+
+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 shown
+ 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 known or discovered is beyond the scope of this
+ document. When a list of tunnel brokers follows the error code as a
+ referral 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: The received request
+ has invalid syntax or is truncated.
+
+ 501 Invalid IPv4 address: The IPv4 address specified by the client
+ is invalid.
+
+ 502 Invalid IPv6 address: The IPv6 address specified by the client
+ is invalid.
+
+
+
+
+Blanchet & Parent Experimental [Page 31]
+
+RFC 5572 Tunnel Setup Protocol (TSP) February 2010
+
+
+ 506 IPv4 address already used for existing tunnel: An 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 processed, 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 265 7357
+ EMail: Florent.Parent@beon.ca
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blanchet & Parent Experimental [Page 32]
+