STUN

Session Traversal Utilities for NAT (STUN, English for tools to traverse NATs ) is a simple network protocol to detect the presence and type of firewalls and NAT routers and penetrate the latter. It should allow easy use of devices ( eg SIP phones ) and computer programs in home networks, which want to receive data from the Internet.

STUN can the currently public IP address of the terminal determine. Thus, for example, a SIP phone determine its currently valid IP address and share. This is necessary so that the other party can address their call data correctly. Currently STUN is probably used most in the VoIP sector ( mainly relating to SIP).

STUN is defined in RFC 3489 and was at that time still for Simple traversal of UDP through NATs. Light of experience and new definitions from other RFCs STUN was then revised and in Session Traversal Utilities for NAT renamed (RFC 5389 ​​). This STUN has been redefined as a framework, and all the functions disappeared up to the base functionality; it was, however, defines how extensions are possible.

Operation

STUN is a UDP -based client - server protocol. For a request two STUN server with different IP addresses are required. A STUN request consists of the following parameters:

The response contains the public IP port address that sees the STUN server. With IP port address is the combination of IP address and the sender's UDP port the client is meant. This address is encoded with an XOR mask, so that they will not be translated by the NAT router. In addition, the alternate IP address of the secondary STUN server and the address of the responding server is being sent.

STUN algorithm

If the client receives no response after repeated Repeat, UDP packets are probably blocked and the request is aborted. Does the IP address in the STUN response of the network card, so no NAT is used and the client is directly connected (eg via a modem) to the Internet. Otherwise, the type of NAT needs to be examined more closely. These further tests are required.

In the case of direct connection the firewall only needs to be tested. To this end, a request to the first STUN server is sent again, but with set alternatives and alternatives IP port bit. So that the response is sent from the second server, and not from the first. If the client receives a response, so incoming connections are unrestricted. If no response is received, then a firewall. This allows only incoming packets from senders when a packet was sent to this sender before. The firewall prevents incoming connections and therefore is not suitable for VoIP.

If a NAT is detected, the same request will be sent with set alternatives and alternatives IP port bit to the first server exactly. Does the NAT router, the response of the second STUN server through, so it is a Full Cone NAT. Incoming connections are fully redirects to the client as soon as they are addressed to the public IP port address of the client that it has received in the response of the STUN server in the first Test. The full cone NAT assigns the port of the client in the local network a fixed port with the public IP address (mapping), which is then no longer be changed.

Receives the answer begins the third test. It sends a normal request without bits set to the second STUN server. It then compares the public IP port address, the second server has determined, with the first of the response. This is different because the UDP port is different, so a symmetrical NAT is used. These uses for each IP address of the target server to another port assignment ( mapping). Incoming connections to a specified IP port address are not possible.

If the IP port address, however, identical, a fourth test is performed. The client sends back a request is put in only the Alternate Port bit. The server responds by another port, but at the same public IP port address. If the response is passed to the client, so it is a Restricted NAT. Although this maintains the same port assignment (mapping) regardless of the destination address of the packet, but allows incoming packets only when a packet has been sent to the source in advance.

After the client, however, no response, a Port Restricted NAT is in use. This behaves similar to the Restricted NAT. In contrast, the destination port number of the previously outgoing packet with the source port number of the now incoming packet must match, otherwise it is discarded. In the last two cases, VoIP is also possible that the client previously only needs to send a packet to the remote site, so that the port is enabled for them.

Implementations

• STUN Client and Server library
• JSTUN - Java implementation