STUN (Session Traversal Utilities for NAT; originally Simple Traversal of User Datagram Protocol (UDP) through Network Address Translators) is a standardized set of methods, including a network protocol, for traversal of network address translator (NAT) gateways in applications of real-time voice, video, messaging, and other interactive communications.
STUN is a tool used by other protocols, such as Interactive Connectivity Establishment (ICE), the Session Initiation Protocol (SIP), and WebRTC. It provides a tool for hosts to discover the presence of a network address translator, and to discover the mapped, usually public, Internet Protocol (IP) address and port number that the NAT has allocated for the application's User Datagram Protocol (UDP) flows to remote hosts. The protocol requires assistance from a third-party network server (STUN server) located on the opposing (public) side of the NAT, usually the public Internet.
STUN was first announced in RFC 3489 in 2003; the title was changed in a specification of an updated set of methods published as RFC 5389 in 2008, retaining the same acronym.
History
thumb|Original NAT characterization algorithm of RFC 3489
STUN was first announced in RFC 3489 in 2003. The original specification 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. The methods of RFC 3489 proved too unreliable to cope with the plethora of different NAT implementations and application scenarios encountered in production networks. The STUN protocol and method were updated in RFC 5389, retaining many of the original specifications as a subset of methods, but removing others.
The title was changed in a specification of an updated set of methods published as RFC 5389 in 2008, retaining the same acronym.
Design
STUN is a tool for communications protocols to detect and traverse network address translators that are located in the path between two endpoints of communication. It is implemented as a light-weight client–server protocol, requiring only simple query and response components with a third-party server located on the common, easily accessible network, typically the Internet. The client side is implemented in the user's communications application, such as a Voice over Internet Protocol (VoIP) phone or an instant messaging client.
The basic protocol operates essentially as follows: The client, typically operating inside a private network, sends a binding request to a STUN server on the public Internet. The STUN server responds with a success response that contains the IP address and port number of the client, as observed from the server's perspective. The result is obfuscated through exclusive or (XOR) mapping to avoid translation of the packet content by application layer gateways (ALGs) that perform deep packet inspection in an attempt to perform alternate NAT traversal methods.
STUN messages are sent in User Datagram Protocol (UDP) packets. Since UDP does not provide reliable transport, reliability is achieved by application-controlled retransmissions of the STUN requests. STUN servers do not implement any reliability mechanism for their responses.