New IP paylods, e.g., transport layer technologies, such as SCTP and DCCP, or TCP with new options, have well-known problems with deployment on the Internet. Firewalls drop IP packets with unknown (too new) transport protocol types, and NAT boxes do not know how to translate these protocols.

Tunnelling over UDP has often been mentioned as a means to traverse middleboxes. Mostly the solutions are ad-hoc and protocol-specific. In order to make deployment of UDP tunnelling at least somewhat consistent, our GUT draft proposes a simple mechanism to realise the goal. The benefit is that with a generic solution we avoid the need to define tunneling specifications for each IP protocol separetely. The fundamental goal of GUT is to mitigate the problem of existing NATs and firewalls, while still allowing middleboxes that deliberately want to block to do so.

The basic idea of GUT is to encapsulate the native transport protocol and its payload (in general the whole IP payload) within a UDP packet destined to the well-known port GUT_P. Between the outer UDP header and the inner transport header, we have a 4-byte GUT header that carries information about the encapsulated protocol.

GUT does not specify, nor need, a specific tunnel setup protocol. It just encapsulates the native protocol and its payload - to any middlebox on the way this looks like a normal UDP flow to port GUT_P. If the native protocol has a handshake or any back-and-forth messaging, these are run automatically within the UDP-tunnel created by GUT. GUT is meant to be fully transparent to the native protocol. GUT can also tunnel protocol types that do not employ ports, such as RSVP or ICMP. The GUT encapsulation is agnostic to the IP protocol version being used (IPv4 or IPv6).

Latest GUT specification: GUT draft on the IETF repository

Downloads:

• Readme
• GUT 0.1 for Linux (first official release to the public)

Todo: add more protocols, proxy-mode and support for BSD.