User:Entropy111/sandbox

TURN (Traversal Using Relays around NAT) is a protocol that allows for an element behind a network address translator (NAT) or firewall to receive incoming data over TCP or UDP connections. It is most useful for elements behind symmetric NATs or firewalls that wish to be on the receiving end of a connection to a single peer. TURN does not allow for users to run servers on well known ports if they are behind a NAT; it supports the connection of a user behind a NAT to only a single peer. In that regard, its role is to provide the same security functions provided by symmetric NATs and firewalls, but to turn the tables so that the element on the inside can be on the receiving end, rather than the sending end, of a connection that is requested by the client.

TURN is specified by RFC 5766. An update to TURN for IPv6 is specified in RFC 6156.

NAT Traversal Solution

Network Address Translation (NAT) (CITE NAT PAGE) is the process of modifying IP address information in IP packet headers while in transit across a traffic routing device. NATs are used to alleviate the consequences of IPv4 address exhaustion. (cite article). With a NAT, a small network in a home or business can use whichever IP addressing system is most convenient for internal uses even if those addresses are in use elsewhere in on the Internet.

The NAT does this by receiving packets from an internal host that are bound for the Internet, changing the packets source IP address from the internal host IP to a NAT public facing IP address, sending out the packets, and when they return form the outside host, looking up where the packets should be routed to in a table, and finally routing them back to the original internal host. During this process, the outside host does not see or know the internal hosts IP address; rather, the destination host only deals with the NAT IP address.

While a NAT fixes the original IPv4 exhaustion issue, it presents a new issue because the outside host never knows the internal hosts IP address, only the IP address of the NAT. If a outside host tries contact a host behind a NAT, but only addresses its packets to NAT public facing IP address, the packets will reach the NAT and be dropped, as the NAT does not know which internal host to direct the traffic to.

Session Traversal Utilities for NAT (STUN) provides one means for an application to traverse a NAT, however, STUN does not work with all network topological conditions. In particular, STUN does not work with symmetric NATs because symmetric NATs remap each different internal/external host transaction to a unique IP and Port and the STUN server IP and end-point IP address will not match up, and therefore be rejected by the NAT. In this situation, TURN offers better results.

Although TURN will almost always provide connectivity to a client, it comes at high cost to the provider of the TURN server. It is therefore desirable to use TURN as a last resort only, preferring other mechanisms (such as STUN or direct connectivity) when possible. To accomplish that, the Interactive Connectivity Establishment (ICE) methodology can be used to discover the optimal means of connectivity.

Protocol Overview

The base protocol operates essentially as follows.

Client, who is behind a NAT, asks a TURN server to allocate a relayed transport address so that Peer may later use it to relay data to the client. Assuming the allocation is successful, the Client sets up permissions so the TURN server can later validate communications the Peer and TURN server. Next, Client sends data to TURN server using a TURN message (which contain TURN protocol specific header data). The TURN server receives the message, extracts the underlying data, repackages the data and sends it to Peer using UDP datagram. The Peer replies with a UDP datagram addressed to the Relayed Transport Address, which Client reserved using the earlier Allocation request. The TURN server receives the UDP datagram, packages it into a TURN message and sends it back to Client.

While TURN is more robust than STUN in that it can traverse more types of NATs, it is prudent to note that a TURN communication relays the entire communication through the server requiring far more bandwidth than STUN protocol (which typically only resolves the public facing IP address then relays the information to Client and Peer for them to use in direct communication). For this reason, the ICE protocol mandates STUN usage as a first resort, and TURN usage when dealing with symmetric NATs, or other situations where STUN cannot be used.

Detailed Example

First, the Client contacts a TURN server with an "Allocate" request. The Allocate request asks the TURN server to allocate some of its resources for the Client so that he/she may contact Peer. If allocation is possible, the server will allocate an address for Client to use as a relay, and send the Client a "Allocation Successful" response, which contains a "allocated relayed transport address" located at the TURN server.

Second, the Client sends in a CreatePermissions request to the TURN server to create a permissions check system for Peer/Server communications. In other words, when Peer is finally contacted and sends information back to the TURN server to be relayed to Client, the TURN server uses the permissions to verify that the Peer to TURN server communication is valid.

After permissions have been created, Client has two choices of sending the actual data, (1) he/she can use the Send mechanism, or (2) he/she can reserve a channel using the ChannelBind request. The Send mechanism is more straight forward, but contains a larger header, 36 bytes, that can substantially increase the bandwidth in a TURN relayed conversation. In contrast, the channel method is lighter: the header is only 4 bytes, but it requires a channel being reserved which needs to be periodically refreshed, among other considerations.

Using either method, Send or channel binding, the TURN server will receive the data from Client and relay it to Peer using UDP datagrams, which contain as their Source Address the "Allocated Relayed Transport Address". The Peer receives the data and responds, again using a UDP datagram as the transport protocol, sending the UDP datagram to the relay address at the TURN server.

The TURN server receives the Peer UDP datagram, checks permissions and if they are valid, sends it back to Client.

See also

• Session Traversal Utilities for NAT (STUN)
• Interactive Connectivity Establishment (ICE)

External links

• Traversal Using Relays around NAT (TURN): RFC5766
• Traversal Using Relays around NAT (TURN) Extension for IPv6: RFC5766

Implementations

• Restund OpenSource Modular STUN/TURN Server (BSD License)
• Numb is a free STUN/TURN server.
• TurnServer - OpenSource TURN server.
• reTurn - opensource STUN/TURN server and client library (C++)
• AnyFirewall - STUN, TURN & ICE library.

Category:Internet protocols Category:Network protocols Category:Network address translation Category:VoIP terminology & concepts Category:Application layer protocols