STUN
acronymStands for: Session Traversal Utilities for NAT
A protocol that lets a host behind NAT ask a server which public address and port its packets arrived from.
Session Traversal Utilities for NAT (RFC 8489) serves voice, video and peer-to-peer applications: it reports the mapping a NAT created, checks connectivity between endpoints and keeps mappings alive. It is not a NAT traversal solution by itself, but a tool that such solutions use.
A client sends a Binding request, by default to port 3478 over UDP or TCP, or 5349 over TLS or DTLS. The server copies the source address and port it sees, the reflexive transport address created by the NAT nearest the server, into an XOR-MAPPED-ADDRESS attribute in the response.
The XOR is a defence against middleboxes. Some NATs rewrote any binary field holding their public address, a misguided generic ALG that broke STUN and its integrity check, so the port is XORed with the top 16 bits of the magic cookie 0x2112A442 and an IPv4 address with the whole cookie. A mapping of 203.0.113.1:51234 travels as port 0xE930 and address 0xEA12D543.
What STUN learns is useful only if the NAT reuses the mapping for every destination: RFC 4787 makes endpoint-independent mapping a MUST so that such methods work, and UDP hole punching depends on it. Older texts sort NATs with STUN's original cone and symmetric names, which RFC 4787 retired as a source of confusion. RFC 8489 obsoletes RFC 5389.
Also known as: stun server, xor-mapped-address, reflexive transport address, rfc 8489, rfc 5389
Sources
- RFC 8489, Session Traversal Utilities for NAT (STUN), February 2020: abstract and sections 2, 5, 8.1 and 14.2 (read 2026-10-19)
- RFC 4787, Network Address Translation (NAT) Behavioral Requirements for Unicast UDP, January 2007: sections 3 and 4.1 (read 2026-10-19)
- RFC 5128, State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs), March 2008: sections 3.3 and 5.1 (read 2026-10-19)