STUN is a standardized set of methods, including a network protocol, used in NAT traversal for applications of real-time voice, video, messaging, and other interactive IP communications. STUN is an acronym for Session Traversal Utilities for NAT, and is documented in RFC 5389.[1] RFC 5389 obsoletes the previous specification, entitled Simple Traversal of User Datagram Protocol (UDP) through Network Address Translators (NATs), documented in RFC 3489.[2] The obsolete version of STUN, sometimes referred to as Classic STUN, was intended as a complete solution for NAT traversal, and featured an algorithm to allow endpoints to determine NAT behaviour. The current version of STUN is presented as a tool to be used by other protocols, such as ICE, removes the NAT classification algorithm, and defines an extensible packet format.
The STUN protocol allows applications operating through a network address translator (NAT) to discover the presence of a network address translator 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 original version of the protocol also specified methods to ascertain the specific type of NAT, but those methods have been deprecated in the newer specification, because of the plethora of specific NAT implementation behavior in various networking equipment and the resulting intractability of the problem and the deficiencies of the method used.
| Internet protocol suite |
|---|
| Application layer |
| Transport layer |
| Internet layer |
| Link layer |
Contents |
Network address translation is implemented via a number of different address and port mapping schemes, none of which are standardized.
STUN is not a self-contained NAT traversal solution applicable in all NAT deployment scenarios and does not work correctly with all of them. It is a tool among other methods and it is a tool for other protocols in dealing with NAT traversal, most notably Traversal Using Relay NAT (TURN) and Interactive Connectivity Establishment (ICE).[1]
STUN 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 from that of the endpoint, in the symmetric NAT case, the NAT mapping will be different for the STUN server than for an endpoint. TURN offers better results with symmetric NAT.
STUN is a lightweight client-server protocol requiring only simple query and response. The client side is implemented in the user's communications application, such as a Voice over Internet Protocol (VoIP) phone or instant messaging client.
The base protocol operates essentially as follows. The client, often operating inside a private network, sends a binding request to a STUN server on the public Internet. The STUN server sends a success response that contains the IP address and port as observed from its perspective. The result is usually XOR mapped to avoid translation of packet contents.
STUN usually operates on a User Datagram Protocol (UDP) messaging transport. Since UDP does not provide reliable transport guarantees, reliability is achieved by application-controlled retransmissions of the STUN requests. STUN servers do not implement any reliability mechanism for their responses.[1] When reliability is mandatory, the Transmission Control Protocol (TCP) may be used, but induces extra networking overhead. In security-sensitive applications, STUN may be transported and encrypted by Transport Layer Security (TLS).
An application may automatically determine a suitable STUN server for communications with a particular peer by querying the Domain Name System (DNS) for the stun (for UDP) or stuns (for TCP/TLS) server record (SRV) resource record, e.g., _stun._udp.example.com. The standard listening port number for a STUN server is 3478 for UDP and TCP, and 5349 for TLS. Alternatively, TLS may also be run on the TCP port if the server implementation can de-multiplex TLS and STUN packets. In case no STUN server is found using DNS lookups, the standard recommends that the destination domain name should be queried for address records (A or AAAA) which would be used with the default port numbers.
In addition to using protocol encryption via TLS, STUN also has built-in authentication and message-integrity mechanisms via specialized STUN packet types.
When a client has discovered its external address, it can use this as a candidate for communicating with peers by sharing the external NAT address rather than the private address (which is, by definition, not reachable from peers on the public network).
If both peers are located in different private networks behind a NAT, the peers must coordinate to determine the best communication path between them. Some NAT behavior may restrict peer connectivity even when the public binding is known. The Interactive Connectivity Establishment (ICE) protocol provides a structured mechanism to determine the optimal communication path between two peers. Session Initiation Protocol (SIP) extensions are defined to enable the use of ICE when setting up a call between two hosts.
Classic STUN specified an algorithm to characterize NAT behavior according to the address and port mapping behavior. This algorithm is not reliably successful and only applicable to a subset of NAT devices deployed.
The algorithm consists of 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.