Simple traversal of UDP over NATs

Simple Traversal of User Datagram Protocol through Network Address Translators (NATs) (abbreviated STUN), is a standards-based IP protocol used as one of the methods of NAT traversal in applications of real-time voice, video, messaging, and other interactive IP communications.The protocol allows applications operating through a NAT to discover the presence and specific type of NAT, and obtain the mapped (public) IP address (NAT address) and port number that the NAT has allocated for the application's User Datagram Protocol (UDP) connections to remote hosts. The protocol requires assistance from a 3rd-party network server (STUN server) located on the opposing public site of the NAT, usually the public Internet. The protocol is defined in RFC 3489.

Protocol overview

STUN is a light-weight client-server protocol. The client side resides in a protocol library linked into an application, such as a voice-over-IP (VOIP) phone or instant messaging client. The client, operating inside the NAT masqueraded network, initiates a short sequence of requests to a STUN protocol server listening at two IP addresses in the network on the public side of the NAT, traversing the NAT. The server responds with the results, which are the mapped IP address and port on the 'outside' of the NAT for each request to its two listeners. From the results of several different types of requests, the client application can learn the operating method of the network address translator, including the live-time of the NAT's port bindings.

NAT devices are implemented in a number of different types of address and port mapping schemes.STUN does not work correctly with all of them. It does work with primarily three types: full cone NAT, restricted cone NAT, and port restricted cone NAT. In the cases of restricted cone or port restricted cone NATs, the client must send out a packet to the endpoint before the NAT will allow packets from the endpoint through to the client. STUN does not work with symmetric NAT (also known as bi-directional NAT) which is often found in the networks of large companies. Since the IP address of the STUN server is different than that of the endpoint, in the symmetric NAT case, the NAT mapping will be different for the STUN server than for endpoint. For better results with symmetric NAT, see TURN. For details on the different types of NAT, see article on network address translation.

The standard STUN server listening port is 3478.

Once a client has discovered its external addresses, it can communicate with its peers. If the NAT is the full cone type then either side can initiate communication. If it is restricted cone or restricted port cone type both sides must start transmitting together.

Protocols like RTP and SIP use UDP packets for the transfer of sound/video/text and signaling traffic over the Internet.

In many application scenarios it is common that both endpoints are behind a NAT. This double-NAT problem is not easily overcome even with STUN, usually an intermediate application proxy server is required.

Algorithm

STUN uses the following algorithm (adapted from RFC 3489) to discover the presence of NAT gateways and firewalls:

Where the path through the diagram ends in a red box, UDP communication is not possible. Where the path ends in a yellow or green box, communication is possible.

Successors to STUN according to RFC 3489

The methods of RFC 3489 have proven too unreliable to cope with the plethora of different NAT implementations and application scenarios encountered in production networks. The document has now been deprecated and new methods are being formalized, but are still in draft status, as of July 2008 ( [http://tools.ietf.org/html/draft-ietf-behave-rfc3489bis draft-ietf-behave-rfc3489bis] ).

See also

*Network address translation
*NAT traversal
*Interactive Connectivity Establishment (ICE)
*Traversal Using Relay NAT (TURN)
*UDP hole punching

External links

* RFC 3489, STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)
* [http://tools.ietf.org/html/draft-ietf-behave-rfc3489bis Latest revision (bis) to the RFC] - draft-ietf-behave-rfc3489bis
* [http://www.newport-networks.com/whitepapers/nat-traversal1.html NAT traversal White Paper] comparing STUN with other NAT traversal techniques such as TURN, ICE, ALGs and Session Border Controllers - Source: Newport Networks
* [http://nutss.gforge.cis.cornell.edu/stunt.php STUNT] - "STUN and TCP too", which extends STUN to include TCP functionality
* [http://www.youtube.com/watch?v=9MWYw0fltr0&eurl=http%3A%2F%2Fwww%2Evoip%2Dnews%2Ecom%2Ffeature%2Ftop%2Dvoip%2Dvideos%2D051707%2F Yahoo! - Director of Engineering explaining STUN and TURN (Video)]
* [http://www.stunserver.org/ stunserver.org an open and freely-available STUN server.]

Implementations

* [http://sourceforge.net/projects/stun/ STUN Client and Server library]
* [http://jstun.javawi.de/ JSTUN - A Java STUN implementation]
* [https://stun4j.dev.java.net/ Java STUN library "stun4j"]
* [http://numb.viagenie.ca/ Numb] is a free STUN/TURN server.