computer science

Traversal Using Relays around NAT

Traversal Using Relays around NAT is a computer science topic covered in the lgStudy science library. This page brings together a partial reference excerpt, illustrations, worked examples, real-world applications and a short study plan, so you can understand Traversal Using Relays around NAT rather than just read about it. In short: Traversal Using Relays around NAT (TURN) is a protocol that assists in traversal of network address translators (NAT) or firewalls for multimedia applications. It may be used with the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP).

Key takeaways

Traversal Using Relays around NAT belongs to computer science; place it in that map before memorising details.
Learn the definition first, then one example that makes the definition concrete.
Connect Traversal Using Relays around NAT to a quantity you can measure, compute or draw — that is where exam questions come from.
Reproduce the core statement of Traversal Using Relays around NAT from memory before moving on to harder problems.

Reference excerpt

Traversal Using Relays around NAT (TURN) is a protocol that assists in traversal of network address translators (NAT) or firewalls for multimedia applications. It may be used with the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). It is most useful for clients on networks masqueraded by symmetric NAT devices. TURN does not aid in running servers on well known ports in the private network through a NAT; it supports the connection of a user behind a NAT to only a single peer, as in telephony, for example. TURN is specified by RFC 8656. The TURN URI scheme is documented in RFC 7065.

Introduction Network address translation (NAT), a mechanism that serves as a measure to mitigate the issue of IPv4 address exhaustion during the transition to IPv6, is accompanied by various limitations. The most troublesome among these limitations is the fact that NAT breaks many existing IP applications, and makes it more difficult to deploy new ones. Guidelines have been developed that describe how to build "NAT friendly" protocols, but many protocols simply cannot be constructed according to those guidelines. Examples of such protocols include multimedia applications and file sharing. Session Traversal Utilities for NAT (STUN) provides one way for an application to traverse a NAT. STUN allows a client to obtain a transport address (an IP address and port) which may be useful for receiving packets from a peer. However, addresses obtained by STUN may not be usable by all peers. Those addresses work depending on the topological conditions of the network. Therefore, STUN by itself cannot provide a complete solution for NAT traversal. A complete solution requires a means by which a client can obtain a transport address from which it can receive media from any peer which can send packets to the public Internet. This can only be accomplished by relaying data through a server that resides on the public Internet. Traversal Using Relays around NAT (TURN) is a protocol that allows a client to obtain IP addresses and ports from such a relay. Although TURN almost always provides connectivity to a client, it is resource intensive for 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 The process begins when a client computer wants to contact a peer computer for a data transaction, but cannot do so due to both client and peer being behind respective NATs. If STUN is not an option because one of the NATs is a symmetric NAT (a type of NAT known to be non-STUN compatible), TURN must be used. 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 it may contact a peer. If allocation is possible, the server allocates an address for the client to use as a relay, and sends the client an "Allocation Successful" response, which contains an "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 a 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, the client has two choices for sending the actual data, (1) it can use the Send mechanism, or (2) it can reserve a channel using the ChannelBind request. The Send mechanism is more straightforward, but contains a larger header, 36 bytes, that can substantially increase the bandwidth in a TURN relayed conversation. By contrast, the ChannelBind method is lighter: the header is only 4 bytes, but it requires a channel to be reserved which needs to be periodically refreshed, among other considerations. Using either method, Send or channel binding, the TURN server receives the data from the client and relays it to the 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 the permissions and if they are valid, forwards it to the client. This process gets around even symmetric NATs because both the client and peer can at least talk to the TURN server, which has allocated a relay IP address for communication. While TURN is more robust than STUN in that it assists in traversal of more types of NATs, a TURN communication relays the entire communication through the server requiring far more server bandwidth than the STUN protocol, which typically only resolves the public facing IP address and 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 only when dealing with symmetric NATs or other situations where STUN cannot be used.

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

References

Worked examples

Example 1 — a first encounter with Traversal Using Relays around NAT

Start with the simplest possible case. Write down what Traversal Using Relays around NAT claims or describes in one sentence, then invent the smallest concrete situation in which that sentence is true. In computer science, the smallest case is usually a single object, a single equation or a single measurement. Check that every symbol or term in your sentence has a meaning in that case.

Example 2 — changing one variable

Take the situation from Example 1 and change exactly one quantity: double it, halve it, or set it to zero. Predict what should happen to Traversal Using Relays around NAT before you calculate. Comparing your prediction with the result is the fastest way to find out whether you understand the idea or only the words.

Example 3 — an exam-style question

Typical questions about Traversal Using Relays around NAT ask you to (a) state it precisely, (b) apply it to given data, and (c) explain a limitation. Practise writing all three answers in under five minutes; the third part is what separates a full-mark answer from an average one.

Applications of Traversal Using Relays around NAT

In research: Traversal Using Relays around NAT appears in computer science research whenever the underlying quantities have to be modelled precisely. Papers usually cite it as a starting assumption and then explore where it breaks down.
In technology and industry: Engineering practice reuses Traversal Using Relays around NAT in design rules, simulations and safety margins. Knowing the idea lets you read a specification sheet and understand why the numbers look the way they do.
In the classroom: Traversal Using Relays around NAT is common in secondary-school and first-year university syllabi. It links to neighbouring topics Application layer protocols, Internet protocols, Network address translation, so understanding it makes those chapters shorter.
In everyday life: Look for Traversal Using Relays around NAT outside the textbook — in sport, cooking, traffic, electronics or the sky above you. An example you found yourself is remembered far longer than one you were given.

Affiliate

Preply — study more efficiently by working with a personal tutor. 50% off.

How to study Traversal Using Relays around NAT in 20 minutes

Read the reference excerpt below once, without taking notes.
Close the page and write down what Traversal Using Relays around NAT means in your own words.
Compare your version with the excerpt and mark what you missed.
Work through the three examples above with pen and paper.
Explain Traversal Using Relays around NAT out loud to somebody else — or to Teacher Smith in the lgStudy chat.

Frequently asked questions

What is Traversal Using Relays around NAT in simple terms?

Why does Traversal Using Relays around NAT matter?

Because it connects several computer science ideas at once: it gives you a definition you can apply, a quantity you can calculate, and a way to check whether a result is plausible.

How should I study Traversal Using Relays around NAT?

Read the excerpt, restate it from memory, then work through the examples and applications listed on this page. The five-step study plan above takes about twenty minutes.

What does this page cover?

It gives you a compact reference excerpt plus original lgStudy explanations, examples, applications and study material on Traversal Using Relays around NAT.