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 original specification in RFC 3489 has been obsoleted by newer methods published as RFC 5389 with the title Session Traversal Utilities for NAT.

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.

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.

NAT characterization algorithm

The original STUN specification (RFC 3489) used the following algorithm to characterize NAT gateways and firewalls according to the address mapping behavior. It should be noted that this algorithm is not reliable and only applicable to a subset of NAT devices deployed today.

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.

Successor to STUN (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 is now obsoleted and new methods and specifications have being formalized. The STUN protocol and method are now being referred to as Session Traversal Utilities for NAT, also abbreviated as STUN (RFC 5389).

See also

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

References

External links

• RFC 3489, STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)
• RFC 5389, Session Traversal Utilities for NAT (STUN)
• NAT traversal White Paper comparing STUN with other NAT traversal techniques such as TURN, ICE, ALGs and Session Border Controllers - Source: Newport Networks
• STUNT - "STUN and TCP too", which extends STUN to include TCP functionality
• Yahoo! - Director of Engineering explaining STUN and TURN (Video)
• stunserver.org an open and freely-available STUN server.

Implementations

• STUN Client and Server library
• JSTUN - A Java STUN implementation
• Java STUN library "stun4j"
• Numb is a free STUN/TURN server.

Why are we here?
All text is available under the terms of the GNU Free Documentation License
This page is cache of Wikipedia. History