STUN
From Wikipedia, the free encyclopedia
STUN is a standards-based set of methods and a network protocol used in NAT traversal for applications of real-time voice, video, messaging, and other interactive IP communications. In the original specification in RFC 3489, STUN was an acronym for Simple Traversal of User Datagram Protocol through Network Address Translators (NATs), but this title has been changed in a specification of an updated set of methods published as RFC 5389 with the title Session Traversal Utilities for NAT, retaining the same acronym.
The original STUN protocol allows applications operating through a network address translator (NAT) to discover the presence and the specific type of NAT, and to 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) side of the NAT, usually the public Internet.
| The Internet Protocol Suite | |
| Application Layer | |
|---|---|
| BGP · DHCP · DNS · FTP · GTP · HTTP · IMAP · IRC · Megaco · MGCP · NNTP · NTP · POP · RIP · RPC · RTP · RTSP · SDP · SIP · SMTP · SNMP · SOAP · SSH · Telnet · TLS/SSL · XMPP · (more) | |
| Transport Layer | |
| TCP · UDP · DCCP · SCTP · RSVP · ECN · (more) | |
| Internet Layer | |
| IP (IPv4, IPv6) · ICMP · ICMPv6 · IGMP · IPsec · (more) | |
| Link Layer | |
| ARP · RARP · NDP · OSPF · Tunnels (L2TP) · Media Access Control (Ethernet, MPLS, DSL, ISDN, FDDI) · Device Drivers · (more) | |
Contents |
[edit] 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, the TURN method should be used. For details on the different types of NAT, see article on network address translation.
The standard STUN server listening UDP port is 3478.
When 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.
[edit] 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 a reliably successful procedure and only applicable to a subset of NAT devices deployed today. The method has therefore been officially removed from the latest version of the standard (RFC 5389).
The diagram maps the algorithm through a series of tests to be performed by an application. When the path through the diagram ends in a red box, UDP communication is not possible and when the path ends in a yellow or green box, communication is possible.
[edit] Successor to original STUN specification
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 obsolete 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). Many of the original specifications are still included, as a subset of methods, but others have been dropped from the standard.
[edit] Implementations
- STUN Client and Server library
- JSTUN - A Java STUN implementation
- Java STUN library "stun4j"
- Numb is a free STUN/TURN server.
[edit] See also
- Network address translation
- NAT traversal
- Interactive Connectivity Establishment (ICE)
- Traversal Using Relay NAT (TURN)
- UDP hole punching
[edit] References
[edit] 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.
