Session Traversal Utilities for NAT

from Wikipedia, the free encyclopedia

Session Traversal Utilities for NAT ( STUN , English for tools for traversing NATs ) is a simple network protocol to recognize the existence and type of firewalls and NAT routers and direct connections between devices that are located behind a NAT firewall, build up. This enables devices that are operated behind certain types of NAT firewalls to set up direct bidirectional connections between the end nodes. Examples of the use of STUN are SIP telephones and computer programs in home networks.

General

STUN is used to determine the information such as the public IP address and port number for establishing direct contact between two end devices, which normally cannot reach each other directly, in order to then provide the clients with this information independently of STUN Enable contact. STUN is used, among other things, in the VoIP sector (especially in connection with SIP ) and for online games from game consoles.

STUN was defined in RFC 3489 and at that time still stood for English Simple traversal of UDP through NATs . Based on the experience gained and new definitions from other RFCs, STUN was then revised and renamed to English Session Traversal Utilities for NAT ( RFC 5389 ). In doing so, STUN was redefined as a framework, and all functions except for the basic functionality disappeared; however, it was defined how extensions are possible.

A similar in function protocol provides TURN represents the abbreviation stands for English Traversal Using Relays around NAT which an external, located on the public Internet relay server uses as opposed to STUN, to build up a connection between clients with a direct communication channel . This also allows communications where the direct connection between end devices is blocked by certain restrictive NAT firewalls. The disadvantage is that the normally encrypted data transfer has to run via the TURN server and this connection represents a bottleneck with many connections.

functionality

STUN is a client-server protocol based on UDP. It is used to determine an external IP address and to analyze the connection of a client to the Internet. It determines whether NAT is used and which NAT type is present. It is not used to completely penetrate firewalls ( hole punching ). Two STUN servers with different IP addresses are required for a complete analysis of the connection types (NAT types). RFC3489 is now marked as obsolete, RFC5389 and RFC7350 contain modified and extended STUN variants.

A STUN request (according to RFC3489) consists of the following parameters:

Transaction ID
Assigned by the client. Used to distinguish other STUN connections.
Reply address
The STUN server should send its response to this address, which consists of an IP address and a UDP port. If the field is empty, it sends the response to the sender address of the request.
Alternative IP
If this bit is set, the answer will be answered by the second STUN server.
Alternative port
This bit instructs the server not to answer the response from the same UDP port to which the request was sent.

The answer contains the public IP port address that the STUN server sees. The IP port address means the combination of the IP address and the sender UDP port of the client. This address is coded with an XOR mask so that it is not translated by the NAT router. In addition, the alternative IP address of the second STUN server and the address of the responding server are sent.

STUN algorithm

STUN algorithm

If the client does not receive a response after repeating the procedure several times, UDP packets are likely to be blocked and the request is aborted. If the IP address in the STUN response corresponds to that of the network card, NAT is not used and the client is connected directly (e.g. via a modem) to the Internet. Otherwise the type of NAT must be examined more closely. This will require further testing.

In the case of a direct connection, only the firewall needs to be tested. To do this, a request is sent to the first STUN server again, but with the alternative IP and alternative port bit set. This means that the answer is sent from the second server and not from the first. If the client receives an answer, incoming connections are possible without restrictions. If no response is received, a firewall is used. This only allows incoming packets from senders through if a packet was previously sent to this sender. The firewall prevents incoming connections and is unsuitable for VoIP.

If a NAT is detected, exactly the same request with the alternative IP and alternative port bit set is sent to the first server. If the NAT router lets the response from the second STUN server through, it is a full cone NAT . Incoming connections are redirected to the client without restriction as soon as they are directed to the client's public IP port address that he received in the response from the STUN server in the first test. The full cone NAT assigns a fixed port with the public IP address to the client's port in the local network (mapping) , which is then no longer changed.

If there is no answer, the third test begins. It sends a normal request without any bits set to the second STUN server. It then compares the public IP port address found by the second server with that from the first response. If this is different because the UDP port is different, a symmetrical NAT is used. This uses a different port assignment (mapping) for each IP address of the target server. Incoming connections to a specified IP port address are therefore not possible.

On the other hand, if the IP port address is the same, a fourth test is carried out. The client sends another request in which only the alternative port bit is set. The server replies from a different port, but to the same public IP port address. If the response is passed on to the client, it is a restricted NAT . Although this retains the same port assignment (mapping) regardless of the destination address of the packet, it only lets incoming packets through if a packet has been sent to its source beforehand.

If, on the other hand, the client does not receive a response, a port restricted NAT is in use. This is similar to Restricted NAT . In contrast, the destination port number of the previously outgoing packet must match the source port number of the now arriving packet, otherwise it will be discarded. In the last two cases, VoIP is also possible, except that the client must first send a packet to the remote station so that the port is enabled for it.

Implementations

Web links