Visual RFC.
ALL RFCs / RFC 8489
Read the RFC ↗
RFC 8489 / PROTOCOL MECHANISMS

Separate discovery from connectivity and privacy

05

STUN is a tool used by other traversal protocols, not a complete media-relay or identity system.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

DIAGRAM§ 13 ↗
RFC 8489 · § 13EXAMPLE
3 / 3
Separate discovery from connectivity and privacySTUN is a tool used by other traversal protocols, not a complete media-relay or identity system.Discovered reflexive candidatepeerNAT clientattempt direct pathchecks / relay usageSTUN is a tool; a complete usage proves paths or provides relaying
03
A complete usage adds checks or a relay rather than assuming success.

A complete usage adds checks or a relay rather than assuming success.

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
KEY POINT

STUN does not guarantee that a reflexive address accepts traffic from any peer.

  • STUN does not guarantee that a reflexive address accepts traffic from any peer.
  • Learned addresses, authentication, transport protection, and usage-specific connectivity checks are separate concerns.
DETAILS

The drawing is a simplified worked example. Follow the linked RFC and its updates for implementation requirements.

Read the RFC section ↗

Diagrams simplify the RFC. Read the linked sections for complete requirements.

Privacy
All chapters in this RFC
  1. Learn the server-observed address
  2. Match a response to its transaction
  3. Parse the STUN header and attributes
  4. Use credentials for message integrity
  5. Separate discovery from connectivity and privacy
RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗