NAT Traversal

Note: work in progress

Overview

NAT (Network Address Translation) is widely used to connect private networks to the internet. The main idea is to map several private IP addresses to only one public IP address. Having in mind that P2P network clients should be able to communicate with each other, one basic question comes into mind: how can internet hosts communicate with a host in a private network? We will first have a look at NAT itself and problems it brings. Then, we show how to traverse NATs by either changing router's configuration or by using other tricks.

Network Address Translation

A network address is simply the IP address ( + Port number for UDP/TCP). A NAT router receives an incoming IP packet, saves the address in its NAT table, rewrites sender address to one of its public addresses and sends the packet to the destination address. Now, the NAT router accepts incoming packets on this public address (NAT endpoint). These packets are forwarded to the private host. The most important facts are:

• The mapping depends on the sender's port number. If the private host uses two different outgoing port numbers, the NAT endpoints will differ.
• The private host has to send first. Otherwise no incoming packets will be forwarded to the private host.
• The client does not know all that... (NAT should be completely transparent to the client)

The behavior of the NAT router is not standardized. The only thing that works with every NAT router is simple request and answer. That means the remote host answers a request using the port number the client used for its request. Some NATs allow replies from other ports or even hosts, some use different endpoint mappings for every session.

According to their behavior, NATs can be classified into four types:

• Full Cone
• Restricted Cone
• Port Restricted Cone
• Symmetric

Full Cone NAT A private host (PH) sends an initial request to A. As a result, the NAT router opens a public endpoint. Every connection to any remote host from PH's port A will be mapped to the same port A' at the NAT router. If PH uses port B, the mapping will be B' and not A'. Now NAT's endpoint is availiable to all remote hosts. Every host may send a message from any source port to NAT's endpoint.

Figure 1: Full Cone NAT

Restricted Cone NAT The behavior of Restricted Cone NATs is nearly the same as Full Cone NATs, except that not every other host may send a message to the public endpoint. Depending on the implementation, NAT router rejects the packet or simply drops it. In case the PH sends a message to another remote host, this host will be able to give an answer. Whether the same NAT endpoint is used or not depends on the port PH uses for sending the message (see above).

Figure 2: Restricted Cone NAT

Port Restricted Cone NAT This type of NAT implements a stronger restriction then Restricted NAT. The restriction now focusses on the target port (and the target host since it is a higher restriction).

Figure 3: Port Restricted Cone NAT

Symmetric NAT Here are the highest restrictions. In opposition to cone NATs, every target host and port will be mapped to another endpoint. While Cone NATs use the same endpoint for every PH's source port, Symmetric NAT uses different endpoints. One endpoint mapps to exactly one (IP,Port_R,Port_PH)-Tuple. Port_R means remote port, Port_PH means private host's source port.

Figure 4: Symmetric NAT

Router configuration

todo

Port forwarding

Ein probates Mittel für NAT-Traversal ist die manuelle Konfiguration des NAT-Routers. Dabei wird der NAT-Router so konfiguriert, dass er bestimmte Datenpakete an einen bestimmtem lokalen Rechner weiterleitet. Die Weiterleitung bestimmt der NAT-Router in der Regel auf Grund des Zielportes im Datenpaket. Der NAT-Router benötigt somit für das Port-Forwarding eine Portnummer (bzw. einen Portbereich) und die IP-Adresse des lokalen Rechners. Über diese feste Weiterleitung anhand der Portnummer ist der lokale Rechner außerhalb des Netzwerkes über diesen festgelegten Port (bzw. Portbereich) erreichbar (NAT-Traversal).

Der grosse Vorteil vom Port-Forwarding ist, dass es für viele Anwendungsfälle die einzig wirklich funktionierende NAT-Traversal-Technik darstellt. Demgegenüber stehen jedoch einige Nachteile:

• Andere lokale Rechner können durch die feste Zuordnung von einer Portnummer zu einen bestimmten Rechner, diesen Port nicht nutzen
• viele Anwendungen wählen den Port dynamisch, so dass dieser vorher schwer bestimmbar ist oder wählen einen Port aus einem grossen Port-Bereich
• Port-Forwarding setzt einen Zugang zum Router und technisches Verständnis voraus

UPnP

Eine andere Möglichkeit, ausgehend vom Port-Forwarding, ist den Vorgang der Routerkonfiguration zu automatisieren. Der Gedanke hierbei ist, dass Anwendungen auf den lokalen Rechnern den NAT-Router nach ihren Bedürfnissen steuern können. Die Bedürfnisse hierbei sind vor allem das Port-Forwarding und die Kenntnis darüber welche öffentliche IP-Adresse der NAT-Router besitzt. Es wird bei dieser Technik davon ausgegangen, dass sich im lokalen Netzwerk, indem sich die loklalen Rechner und der NAT-Router befinden, niemand mit böswilliger Absicht aufhält und der Zugang zum lokalen Netzwerk entsprechend gesichert ist. Durch diese Technik werden einige Nachteile des manuellen Port-Forwarding behoben. Realisiert werden kann diese NAT-Traversal-Technik durch "Universal Plug and Play" (UPnP). UPnP wurde 1999 durch das UPnP-Forum spezifiziert und wird von diesem ständig weiterentwickelt. UPnP wurde nicht für NAT-Traversal entwickelt, sondern für eine herstellerunabhängige Steuerung von elektronischen Geräten über ein IP-Netzwerk und kann somit für NAT-Traversal benutzt werden. UPnP wurde so entworfen, dass es bereits vorhandene Netzwerkprotokolle und Datenformate, wie HTTP, SSDP, XML, usw. benutzt. Voraussetzung für die Implementierung von UPnP auf einem Gerät ist, dass auf diesem ein Betriebssystem und eine Netzwerkschnittstelle vorhanden ist. Viele im Handel erhältliche NAT-Router unterstützen bereits UPnP, sodass NAT-Traversal mittels UPnP bereits in Anwendung ist. Der allgemeine Ablauf für eine Kommunikation zwischen einem UPnP-Gerät (z.B. NAT-Router) und einem UPnP-Kontrollpunkt (z.B. lokaler Rechner) sieht im Groben folgendermaßen aus:

1. Das UPnP-Gerät macht sich und seine Dienste im lokalen Netzwerk über Multicast bekannt. Der UPnP-Kontrollpunkt erhält über diese Multicast-Nachrichten (Simple Service Discovery Protocol) Information darüber, um was für ein Gerät es sich handelt (z.B. Internet Gateway Device, Printer Device, HVAC (heating, ventilation, air conditioning) usw.) und unter welcher Adresse er detaillierte Informationen über das Gerät erhalten kann.
2. Der UPnP-Kontrollpunkt kann sich über diese Adresse die detaillierte Geräte- und Dienstbeschreibung (XML) vom Gerät holen.
3. Anhand dieser Informationen wird der Kontrollpunkt in die Lage versetzt, das Gerät zu steuern. Der Kontrollpunkt kann nun über spezielle Nachrichten (SOAP) Aktionen aufrufen (z.B. AddPortMapping).

Aufgrund der vom UPnP-Forum standardisierten Geräte kann diese Kommunikation mit einem UPnP-Gerät durch eine Client-Anwendung ausgeführt werden.

STUN

todo

TURN

todo

Hole punching

Hole punching deals with the problem that two clients have behind NAT routers, when they want to establish direct connections. Here, a client A cannot establish a connection with client B, because B is behind a NAT and vice versa. However, using a slightly modified STUN server enables both clients to obtain the public NAT endpoint addresses and the clients' private addresses. Now hole punching can be tried: both clients send messages to one another. Now, the following happens: client A's message is the first one. It will be rejected or dropped at B's NAT. Hence, A's NAT opened a public endpoint for A's connection. Now, B sends his message. This message will be forwarded by A's NAT. As a result, both NATs have open endpoints; direct communication is established. One special case is when A and B send their messages synchronously. Here, both messages will reach their targets. What about Symmetric NAT? That's the problem case hole punching cannot handle. We require public endpoint addresses obtained by STUN; so here is the failure. Symmetric NAT assigns different endpoints to different communication partners, so connection attempts from other servers than the STUN server automatically fail.

Figure 5: Hole punching

Since hole punching works for two clients behind different NATs, we now focus on a special case when two clients are behind the same NAT. Remember the restrictions to the STUN protocol: the clients may find out they are behind the same NAT, but they actually do not know whether they are in the same private network (--> cascaded NATs). Now the clients can try normal hole punching. If this works or not depends on the NAT's ability of doing so-called hairpin translation. Since clients from private network try to connect to NAT's public addresses, the NAT may deny this communication. In the best case, the NAT will translate the request internally by opening a direct route to the NATed client. Also possible were to send the request to the internet and receive it like a normal request, but this is inefficient. To achieve the best performance, clients may try to connect to the private address obtained from STUN server. If the clients are located in the same subnet, this will work. By the way, this is a possible method for traversing symmetric NATs.

Figure 6: Hairpin translation

Conclusion: hole punching is not a cure-all for traversing NATs, but works fine for Cone-type NATs. Symmetric NATs cannot be traversed by using these simple methods. Hairpin translation is a special case for hole punching and may allow direct communication for clients behind the same symmetric NAT. If all that does not work, the fallback strategy is to establish relayed connections using the TURN protocol.

NAT and Voice over IP

todo

Refereces

• Ford, Srisuresh, Kegel: Peer-to-Peer Communication Across Network Address Translators (link)
• Rosenberg, Huitema, Mahy: Traversal using relay NAT (TURN), Internet Draft (link)
• Rosenberg, Weinberger, Huitema, Mahy: STUN – simple traversal of user datagram protocol (UDP) through network address translators (NATs), March 2003, RFC3489 (link)
• Rosenberg: Interactive Connection Establishment (ICE), Internet Draft (link)
• Schulzrinne: diverse documents concerning NAT and SIP, e.g. NAT Types.pdf (NAT and SIP)
• STUN Client und Server (link)