The problem is when two nodes in the Solipsis network are each behind a NAT device (firewall, gateway, etc.) and want to connect to each other. There are in fact two problems :

• getting each other's addresses/ports as seen from the Internet (i.e. as shown to the outside by the NAT)
• connecting to each other by opening a hole through the NAT

As with most end-user applications, we don't want to rely on the system administrator to open dedicated inbound ports for us to listen to. Thus we need a way to play with the NAT's features/limitations so as to pass through.

STUN

Simple Traversal of UDP through NATs (http://www.faqs.org/rfcs/rfc3489.html) is an IETF protocol. It allows a NATted client to a connect to an arbitrary STUN server on the Internet (outside the NAT). This public STUN server will send back some information :

• the client's IP address and port as seen from the Internet
• what features and limitations the STUN server has been able to detect on the NAT device

With this information, the NATted client can know : 1) if the NAT can be traversed back by UDP packets depending on what UDP packets the client sends outside 2) what address and port number the client must give to its peers so that they can call it back.

STUN is not an elegant and complete solution. It is rather a kludge to alleviate the problem that each NAT has its own functioning. As per the RFC :

"This protocol is not a cure-all for the problems associated with NAT. It does not enable incoming TCP connections through NAT. It allows incoming UDP packets through NAT, but only through a subset of existing NAT types. In particular, STUN does not enable incoming UDP packets through symmetric NATs (defined below), which are common in large enterprises. STUN's discovery procedures are based on assumptions on NAT treatment of UDP; such assumptions may prove invalid down the road as new NAT devices are deployed. STUN does not work when it is used to obtain an address to communicate with a peer which happens to be behind the same NAT. STUN does not work when the STUN server is not in a common shared address realm."

uPNP NAT Traversal

Universal Plug'n'Play is a forum led by Microsoft and others aimed at making computer hardware discover each other seamlessly. Amongst others, it has a specification for applications to talk to NATs and tell them what ports they want to use/open : the Internet Gateway Device (IGD) Standardized Device Control Protocol V 1.0 (http://www.upnp.org/standardizeddcps/igd.asp).

There are several problems :

• it is said to be quite a complex protocol, involving a complex XML grammar
• it is based on the willingness of system administrators to allow arbitrary applications to tell the NAT to open ports on the outside ; it is unlikely many NAT administrators are willing to take that risk (any trojan / virus infecting a PC behind the NAT would then be able to open the private network to the outside)

Discussion of different methods

An interesting document in French can be found here (http://www.iro.umontreal.ca/~jaumard/Research_Projects/Mitacs_Project2/Publications/Report1.pdf).

Some SIP applications use STUN for traversing NAT. Although not quite elegant, this solution seems mature.

A recent discussion (http://www1.ietf.org/mail-archive/web/sip/current/msg10657.html) on the IETF SIP mailing-list.

Chownat (http://chownat.lucidx.com/) is a cool app allowing two parties, each behind NATs to communicate without a middle man or other 3rd party.

Implementations

Shtoom (http://www.divmod.org/Home/Projects/Shtoom/index.html) is a very interesting project (http://www.python.org/pycon/dc2004/papers/6/) that builds a complete phone-over-IP application in Python, including the SIP stack itself. It has built-in STUN support using Twisted (see here (http://www.divmod.org/cvs/trunk/shtoom/shtoom/stun.py?rev=699&root=Shtoom&view=log) and here (http://www.divmod.org/cvs/trunk/shtoom/shtoom/rtp.py?rev=576&root=Shtoom&view=log)).