Public Tunnel Setup Protocol

HISTORIC PAGE: This page is kept here for historic reasons, but it is no longer actively worked on. The work has advanced into 6bed4, a much more scalable solution due to its use of direct peer-to-peer connectivity whenever possible.

Contents

Public TSP in ten seconds

...and few more seconds:

Why does this project exist?

In an ideal world, we'd move from IPv4 to IPv6 in a day. In practice, both will live side by side for quite a while. Embedded devices usually lack the space to support both, so they may make conservative choices, thereby halting progress.

To improve the progress of IPv6, it is good to create IPv6-only devices, web-applets and so on. But they need a fallback option if they end up on IPv4-only networks. Public TSP is a simple and effective solution for that: it can pierce through NAT and can run without configuring.

What does this project (want to) do?

The idea is that IPv6-only apps such as embedded devices or web apps will quickly build up a tunnel using the Tunnel Setup Protocol of RFC 5572. They can do this without registering first, as the server side protects against network abuses that are otherwise handled by registration. Any abuse issues over IPv6 can be translated to IPv4 abuse issues.

Local devices wrap IPv6 data in UDP and ship it to a tunnel server over IPv4. The tunnel server unwraps the IPv6 data and forwards it. Reverse traffic receives the opposite treatment.

What does a tunnel server do?

The tunnel server accepts a tunneled IPv6 packet only if it contains the public IPv4 address and UDP port number in the package. This makes egress filtering on IPv4 apply to the IPv6 traffic. It also means that any abuse on the IPv6 network can be traced back to the origin by looking up the responsible party for the IPv4 address.

The whole setup is so simple that the tunnel server can be stateless. So all the tunnel server does is pass packets between sites and a little bit of tunnel descriptive support.

Since this tunnel is stateless, it is possible to send a packet out through one tunnel, and receive one back over another! In other words, it is possible to assign fixed address to both tunnel endpoints, even accross many sites on the Internet.

How can BGP-speakers help?

This setup works well if it is as omnipresent as possible What you could do is easy and possible:

Download software

The link below is for the PubTSP software that implements the idea of a Public TSP facility. It implements the TSP profile described above.

Specifically:

You can:

Talk to us

You are welcome to drop your response to rick at openfortress dot netherlands. We want to make IPv6-only implementations possible, which is why we created this software in the first place!

To give you an idea: We are creating an IPv6-only SIP network. Rather than dealing with NAT traversal and RTP proxies, we think we can create a much better user experience by connecting all people directly over IPv6. And indeed, potential users suddenly see the benefits of IPv6, and want it!

To smoothe the transition to IPv6-only telephony, we are involved in various transitioning techniques, for which we develop open source software: