TSP - Tunnel Setup Protocol

TSP is specified in RFC 5572, "IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)", February 2010 (Experimental category, not Standards Track). TSP was originally proprietary, and was created by Marc Blanchet (et al) while he was with Hexago. When the details were released in RFC 5572, this meant that anyone could create an implementation of the protocol based on the RFC, without paying royalties or requiring permission. Marc also created freenet6, which was one of the early sources of free tunneled IPv6 (using TSP, of course). Freenet6 is still around. Marc left Hexago some time ago (he is now with Viagenie, where among other things, he is working on NAT64/DNS64). Hexago evolved into a new company called gogo6. The Hexago products (including a TSP based TunnelBroker appliance and the TSP client) are now owned and distributed by gogo6. This company has created some new products and does extensive social networking and conferences. I highly recommend that you join their online community, and if it is convenient for you, that you attend their events (you can even attend them online).

IPv6Now in Australia runs a Hexago/gogo6 TunnelBroker appliance, and offers both free and commercial tunneled service (along with IPv6 training and consulting).

TSP is actually quite a good design, compared to other IPv6 over IPv4 tunnel mechanisms. It includes NAT traversal (like Teredo), but if you happen to have a public IPv4 address, NAT Traversal isn't used. Like most other IPv6 tunnel protocols, TSP is based on 6in4 way down deep. A mechanism was added to allow automatic tunnel creation, including authentication (I don't believe any other tunnel mechanism includes this feature). It can also provide IPv4 tunneled over IPv6, making it the only open source 4in6 mechanism I know of. TSP can provide a single address (e.g. IPv6 /128 address), or route a block of addresses (e.g. IPv6 /64 or /48). The TSP client (now called gogoCLIENT) has been ported to numerous operating systems (Windows 32bit, Windows 64 bit, Linux, FreeBSD, Mac OS-X, etc), and can be downloaded for free. Source is available. The Windows versions are the only ones provided in executable installer format. It is quite simple to install the client. You must join gogo6 before you can download the gogoCLIENT, but there is no charge for this. There is a hardware TSP client called gogoCPE.

From the RFC:

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.

TSP supports three tunnel mechanisms:

  • IPv6 over IPv4 (RFC 4213) This requires public IPv4 addresses at each end
  • IPv6 over UDP-IPv4 with NAT Traversal - using udp/3653 (works behind most NAT44 gateways)
  • IPv4 over IPv6 (RFC 2473)

It also supports:

  • Authentication of the client to the Tunnel Broker (including anonymous)
  • IP address assignment for the tunnel endpoints
  • Dynamic DNS registration for the tunnel endpoints
  • Negotiation of keep-alive
  • Assignment of IPv6 prefix for clients that are routers
  • Delegation of DNS reverse zone, based on the IPv6 prefix assigned
  • Negotiation of routing protocols
  • Determination of need for NAT traversal

There are actually four separate components in TSP:

  1. The TSP client
  2. The client tunnel endpoint
  3. The TSP server
  4. The server tunnel endpoint

Components 1, 3 and 4 together constitute a Tunnel Broker, as specified in RFC 3053, "IPv6 Tunnel Broker", January 2001.

You can deploy the Tunnel Broker and Tunnel Server on two separate nodes. The first node ("Tunnel Broker") contains component 3, and the other node ("Tunnel Server") contains component 4. In this case, a single Tunnel Broker node can control multiple Tunnel Server nodes. Each Tunnel Server node can handle a large number (thousands) of Tunnel Clients.

                          | TUNNEL BROKER |--> Databases (DNS)
                          |               |
                          |  TSP          |
                          | SERVER        |
                              |     |
         __________           |     |          ________
        |           |         |     |         |        |
        |   TSP     |--[TSP]--      +---------|        |
        |  CLIENT   |                         | TUNNEL |--[NETWORK]--
[HOST]--|           |<==[CONFIGURED TUNNEL]==>| SERVER |
        |___________|                         |        |

It is also possible to deploy the Tunnel Broker and Tunnel Server on a single box which contains components 3 and 4. The gogo6 Tunnel Broker appliance uses this model. In this case, the model looks like this:

         ___________                           ________
        |           |                         |  TSP   |
        |   TSP     |-----------[TSP]---------| SERVER |
        |  CLIENT   |                         |        |--[NETWORK]--
[HOST]--|           |<==[CONFIGURED TUNNEL]==>| TUNNEL |
        |___________|                         | SERVER |

In both models, components 1 and 2 are on a client computer (which can be a host or a router). We implemented the TSP client into SolidGate. This allows you to obtain tunneled IPv6 for an entire subnet, even from behind NAT.

Note that once the Tunnel Broker has negotiated and set up a tunnel, the tunnel is actually static. This is more reliable than fully automated tunnels.

Unlike 6rd, the routed IPv6 block is not dependent on the underlying IPv4 address.

The TSP client includes a Router Advertisement Daemon which gets the prefix from the TSP server and communicates it to other nodes in the client subnet with Router Advertisements. That node becomes the IPv6 default gateway for the subnet. This is as expected when the TSP client is built into the border gateway, but may be a bit confusing to some users if the TSP client is on an internal node, such as a Windows computer, or gogoCPE device. The gogoCPE can replace some CPE devices, but it can also be deployed as a node in the LAN side of an existing CPE. In this case, the TSP tunnel goes through the existing border gateway and is terminated at the node containing the TSP client.

This diagram shows how a TSP client authenticates to the Tunnel Broker, negotiates a tunnel, and then tunnels packets back and forth over that tunnel.

       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)            |

For full details of the messages sent back and forth, see RFC 5572. They are easy to follow since they are in XML ASCII format.