10.9 STUN Protocol

STUN was first published as RFC 3489 [8] as Simple Traversal of UDP through NAT. It has been significantly updated and revised and published as RFC 5389 with a new acronym expansion, Session Traversal Utilities for NAT [16]. The basic operation is shown in Figure 10.8. The main function of STUN is for a STUN client to request a mapping request from a STUN server. The STUN packet sent by the client traverses any number of NATs before reaching the STUN server. The STUN server returns the mapped address in a response. Note that this mapped address is just the one of the outer NATs —there may be many mappings happening, but only the outermost one is visible to the STUN server. The address must be hidden from ALGs in NATs in this response packet or the NAT might try to fix the address and replace it. This is done by an exclusive ORing (XOR), the mapped IP address in the response.

There are four main usages of STUN. The first is for basic mapping discovery. The second is to perform a connectivity check with a server or a peer UA. (This is the usage for ICE.) The third is for media relay usage. The extensions are known as TURN and described in Section 10.14. The fourth is as a keep-alive to refresh NAT mappings for UDP. This is used in the SIP outbound extensions. Another usage of STUN is NAT behavior discovery. This relatively new usage is described in [10]. This creative usage of STUN allows:

•NAT address mapping;

•NAT filtering behavior;

•Discovery of the mapping lifetime;

•Discovery of support for hairpinning;

•Determination of fragmentation handling;

Figure 10.8 STUN: session traversal utilities for NAT.