Single-stack platforms

Most transition scenarios assume that we will support IPv4 and IPv6 side-by-side during a long period, possibly tens of years. Basically, the assumption is that all the old IPv4-only devices must be sweated out of the Internet. The inability of pinpointing a D-Day for changes in the Internet probably means that we will never phase out IPv4 completely. What a great opportunity for bugs and virusses to pray on innocent networks!

Dual-stack systems are certainly the desktop practice of today, but it is not the best solution everywhere. Firewalls need to protect twice the entrance points and will probably be setup with twice the rules, if funds can be raised to support both in parallel; and failure in the less-popular protocol may go unnoticed for quite a while in less actively monitored organisations, thus depriving the Internet of its good name and probably blaming IPv6 for any problems.

More importantly perhaps is the lack of space for code in small applications. An embedded device or a Java applet may simply not have the space to support two address families. Clients grow in complexity if they need to care for both NAT traversal and IPv6 transitioning techniques.

In short, there will always be single-stack applications.

In a world dominated by IPv4, with a few newcomers trying to pray the gospel of IPv6, it is fairly obvious what choices will be made for single-stack applications... and they won't be favouring progress or a quick switch to IPv6.

Independence of questionable routers

Many Internet connections are built up through a router of questionable quality, as these are usually programmed in a modern, cost-optimising fashion. This type of device easily gets upset with new developments such as DNSEXT, 6in4, 6to4, barren IPv6 and so on.

In contrast with this, most transitioning techniques assume co-operative routers. 6to4 and 6in4 can only work if a router recognises protocol 41, or at least forwards it to a node that can unwrap it.

Teredo is a mistake

Although it is good to have large players on the side of convergence on IPv6, the Teredo standard may be more of a disadvantage to the progress of IPv6 than an advantage. The core problem is that it only works for client-server connections, and not client-client (or, more popularly phrased, peer-to-peer) connectivity. So basically, Teredo does not provide a transparent v6 Internet.

In effect, all problems caused by NAT are passed over to IPv6 when Teredo is used. This means that the disadvantages of IPv4 are still felt with Teredo's 2001:0::/32 dedicated address range. In short, it is too limited to be of any real value to any real users. In practice, it even causes users to be downcast about IPv6, because their first encounters with it reveal slow response times and unreliably connections. If IPv6 can be stopped, it is likely that Teredo is the cause!

Currently available tunnels

There are two types of tunnel that can traverse NAT. Their trick is simply to wrap traffic inside UDP instead of directly inside IPv4. This suffices to achieve complete transparancy, in spite of NAT and (as far as we have seen to date) in spite of the quality of network routers.

The current tunnels that can transparantly traverse NAT are:

• SIXXS offers fast connections, but proper registration is required to get it setup. Although this is quite alright to unleash the powers of IPv6 onto a home or office network, it is not ideal for a single-stack embedded device on an IPv4-only network, as it requires manual setup and device configuration. It would actually make such a device so much less attractive that it will probably never be built. As far as Java connectivity to IPv6-only services goes, it is not sensible to mention credentials in an applet as this will go public and thus create opportunities of abusive use.
• Freenet6 offers anonymous access, but it is slow and not very reliable. Connectivity has round-trip times of half a second, and at least their Amsterdam server often plays hard to get. Perhaps more importantly though, the access is really anonymous, in that an IPv6 address is assigned that is unrelated to the IPv4 address for the Internet user. This makes abuse a little more likely to succeed.

From this, we derive that there is a vacancy for a NAT-traversing protocol that supports use without registration, but not anonymously.

The gap that Public TSP fills

The idea of Public TSP is to support single-stack IPv6 applications (also known as IPv6-only applications) to connect to an IPv6 server even if they are connected to an IPv4-only local network. NAT should be traversed, and no credentials should need to be supplied to get onto the IPv6 network.

Given this formulation, the trick is straightforward: All we need to do is mention the IPv4 address as part of the IPv6 address. This is simple, as IPv6 addresses offer a lot of space for such information.

So, what Public TSP does, is offer IPv6 addresses for use to IPv4 clients that include the IPv4 address as well as the publicly used UDP port in the lower part of the IPv6 address. The tunnel will verify this information on traffic from tunneled to native IPv6, and extract the IPv4/UDP information from traffic from native to tunneled IPv6. If any abuse complaints come in, they will be forwarded to the IPv4 address folded into the IPv6 address that is the subject of a complaint.

How you may help

Having realised this problem, we decided to write a solution. It is the PubTSP software presented on this site. It is available under a BSD license to maximise its freedom to actually be used.

It is another thing to host this application throughout the world. This is a useful task for BGP speakers, which does not include us.

If you would like to run a setup of PubTSP and announce its IP addresses, please talk to rick at openfortress dot Netherlands.