PUBTSP

pubtsp − server-side daemon for public TSP service

pubtsp [−t /dev/tunX] −l v4addr −L v6prefix/64 pubtsp −h

Through a pubTSP daemon, it is possible to make an IPv6 range of addresses available to IPv4-only users. This means that even an IPv4-only network can host IPv6-only applications, as long as they can fall back on a tunnel based on this profile.

TSP, or the Tunnel Setup Protocol, is documented in RFC 5572. It defines several methods for encapsulating IPv6 traffic in IPv4 packets. It also defines SASL as its generic authentication layer.

This daemon implements a specific profile for the server side of TSP. The profile of RFC 5572 implemented by this daemon supports NAT traversal for public use. The purpose of this profile is to provide a fallback mode to IPv6-only devices running on an IPv4-only network; the idea is to make such a fallback possible without needing to configure a tunnel.

The NAT traversing aspect of this profile is needed to support the normal openness of IPv6 connections. This is achieved by packing IPv6 into UDP and then into IPv4. This is a guaranteed manner of traversing NAT, provided that this daemon listens to a public IPv4 address. The daemon currently does not support any other modes of operation.

The public-use aspect of this profile means that there is no requirement for clients to register. In terms of SASL, this uses the ANONYMOUS method of authentication. However, this does not mean that the use of pubTSP makes it possible to browse IPv6 networks anonymously; in order to ensure traceability of abusive behaviour, the IPv4 address and UDP port of the tunnel client are mentioned in the IPv6 address. See ADDRESS FORMAT below for details, and SECURITY CHECKS for further precautions against abuse.

The foreseen application of servers under this profile of TSP are IPv6-only services that are accessed from an IPv4-only network. The pivotal point of defining IPv6-only service can be simplicity, or making IPv6 more efficient and/or more useful. To avoid making IPv6 a strict requirement, clients for such an IPv6-only service could implement this profile of TSP to provide a simple backward-compatible mode for IPv4-only network nodes, without impairing all advantages of being IPv6-only.

This daemon is in fact a stateless translation between an IPv4 client and the general IPv6 world; the interactions defined by TSP are all handled as required by RFC 5572, but some are strictly speaking not required for pubTSP. We emphesise that their specification should still be met in all clients, so as to avoid dependency on this one implementation of TSP, and/or its current version.

The implementation listens to a UDP socket on TSP standard port 3653 on the IPv4 side, and to a tunnel endpoint to capture all traffic matching an IPv6 prefix. It basically tosses traffic back and forth between these interfaces, but not without performing the SECURITY CHECKS desribed below on what is tossed at it.

−h

−−help

Print usage information and exit.

−t /dev/tunX

−−tundev /dev/tunX

Instead of creating a tunnel for the duration that pubTSP runs, use one that already exists and that has already been setup with the proper IPv6 prefix. This option makes it possible for non-root users to run pubTSP. All that is required is acccess to the tunnel device by the user that runs pubTSP. Optional on Linux.

−l v4addr

−−v4listen v4addr

Bind to the given local IPv4 address and listen for incoming TSP tunnel commands and packaged-IPv6 traffic. Required.

−L v6prefix/64

−−v6prefix v6prefix/64

Bind to the given IPv6 address range through a tunnel device, and forward incoming IPv6 messages to IPv4-based UDP tunnel endpoints. See ADDRESS FORMAT below for an explanation of the lower half of the IPv6 addresses. Required.

If no −t option is given, a tunnel will be created for the time that pubTSP is running, and the v6prefix/64 is used as a router address on that interface. Routing table entries will not be setup by publicTSP, nor will the general ablity to forward IPv6 traffic.

An IPv6 address used from pubTSP reveals the IPv4 address and UDP port used by the tunnel endpoint. This format is checked on sending from the IPv4 tunnel to IPv6, and used to reconstruct the IPv4 tunnel access information for traffic from IPv6 to the IPv4 tunnel.

The format of the IPv6 addresses managed by pubTSP are:

v6prefix + v4addr + udp-port + localnet

In this format, the v6prefix is configured with the −L option, and the v4addr with the −l option. The udp-port is noted on arrival of a packet on the IPv4 tunnel side of pubTSP.

The localnet defaults to 0, but may be used to differentiate up to 65,536 different hosts accessible through the same TSP client. As the main application foreseen for pubTSP is to get IPv6-only tools and devices working on an IPv4-only network, this is not a probable setup, but it is nevertheless possible. The current version of pubTSP does not actually hand this over as a subnet.

The router address that pubTSP chooses for itself consists of the v6prefix with zeroes appended; this falls outside the setup above, because neither IPv4 addresses nor UDP port numbers are not permitted te be zero-valued.

Incoming IPv6 traffic destined for a serviced address is first checked as specified under SECURITY CHECKS, and then forwarded to udp-port at v4addr. In doing so, the IPv6 packet is embedded in whole inside the UDP packet. The IPv6 addresses are not altered, but only used to derive IPv4 contact information.

Outgoing IPv6 traffic arriving on the IPv4 tunnel side of pubTSP will be checked to have been sent from the right v6prefix and mention the v4addr and udp-port matching the client’s public side. That is, NAT may translate the IPv4 address and UDP port used, but these parts of the IPv6 address should show how it is forwarded to pubTSP. Note that the TSP protocol provides this necessary information at the time the TSP tunnel is created.

It is recommended to keep NAT state in tact by regularly sending over the UDP port to the tunnel endpoint. At the very least, a regular ping could do that. Alternatively, a client-mode only daemon could ensure that it is sending regularly during the times that an outside party might wish to send to it. This is under the assumption that no explicit mapping in NAT overtakes this responsibility of an active mapping between the internal and external address space.

Not everything will be passed through pubTSP, even if this would be technically possible. A few security checks are applied to silently drop traffic that looks evil.

Packets should be long enough to at least contain the IPv6 traffic and a minimal payload size. Also, it should not exceed a predefined MTU of 1280 bytes for IPv6.

IPv6 traffic uploaded through the IPv4 side should reveal the proper IPv4 settings in the IPv6 source address, as specified under ADDRESS FORMAT above. This is basically the tunnel aspect of egress filtering.

Tunnel commands should adhere to the format of RFC 5572 and may not contain any NUL characters.

Currently, pubTSP does not use ICMP notifications at the IPv4 level to provide smart feedback to an IPv6 client. It is undecided at this point if this would add value.

To be able to fallback to this TSP profile, an IPv6-only application needs to find a pubTSP or similar service. A general naming or numbering scheme is needed to make that straightforward. The pubTSP service could be setup privately and configured in individual IPv6-only nodes, but it could accelerate the introduction of IPv6-only nodes if this were organised by network providers.

Ideally, pubTSP would be near all heavily connected nodes of the Internet. There, they would improve connectivity without being a detour for the traffic. Alternatively, it would be located in various uplinks. To optimise routing, it is possible to assign a fixed IPv4 address and IPv6 prefix for pubTSP running anywhere; its stateless operation means that traffic going back and forth can go through different instances of pubTSP without posing problems.

The pubTSP daemon is a piece of highly efficient code, and it should be able to handle very high bandwidths. A stress test has not been conducted yet.

Released under a BSD-style license without advertisement clause.

The 0cpm project is an example of an IPv6-only SIP application that can use pubTSP and comparable TSP tunnel services to demonstrate the advantages of IPv6 to end users. It is also a typical example of a transitionary need for something like pubTSP.

http://0cpm.org/ − the homepage of the 0cpm project.

http://devel.0cpm.org/pubtsp − the homepage of pubTSP.

RFC 5572 − the authoritative description of TSP, of which pubTSP is implements a specific profile for public service under NAT traversal.

pubTSP was written by Rick van Rein from OpenFortress. It was created to support the 0cpm project.