NAT Traversal through Tunneling (NATTT)

Network Address Translation (NAT) is prevalent in today's Internet as it is deployed everywhere from large enterprise networks to millions of residential home networks. NAT allows networks to use private IP addresses internally while still being able to access the public Internet, but it does not allow external hosts to initiate communication to private internal addresses, a hurdle to many emerging applications, such as VoIP and P2P. Although a plethora of NAT traversal solutions have been proposed in recent years, they suffer from being application-specific, complex, or dictated by specific NAT implementations. Given NAT is likely to be with us for a long time, we need a simple, generic NAT traversal solution for all applications.

Highlights

Objective: To allow an external host to initiate a connection to a host behind a NAT such that:

1. the connection works with all applications and transport protocols,
2. it supports nested NATs,
3. and the solution is incrementally deployable and easy to deploy.

Key concepts in our design include the use of UDP tunnels and a sequence of NAT box addresses and private IP addresses to uniquely identify a host. We propose simple and incrementally deployable changes to DNS as a mechanism to learn the addresses (e.g., the sequence of tunnels and private addresses) and require only minimal modifications as discussed below .

Overview

Our NAT traversal design aims to achieve two main goals. First, the solution should be generic. It should support all applications and transport protocols, and it should also support nested NATs. Second, it should be incrementally deployable. It should be compatible with existing infrastructures, including NAT boxes, hosts, and applications, and the cost and gains of deploying the solution should align at the same place.

The basic idea is to tunnel packets through NAT boxes to restore end-to-end reachability. Suppose an external host A wants to initiate communication with an internal host B behind a NAT box Y. If A knows both Y's public address (Y_pub) and B's private address, A can tunnel packets to B as follows. The outer header of a packet is destined to Y_pub, so that the packet can be routed over the public Internet to reach Y; The inner header is addressed to B, so that when Y receives the packet, it can remove the outer header and find out where to forward the packet within the private network.

To implement this idea, three main design questions must be answered. (1) How does the initiator of communication learn the tunnel end-point(s) at the destination network? (2) Although tunneling can solve the reachability problem for hosts behind NAT, those hosts still suffer from the non-uniqueness problem of their NAT addresses. That is, even if a host A can reach other hosts behind NATs, these other hosts may be behind different NATs and happen to have the same private IP addresses, how can A distinguish different remote hosts when they use the same (private) IP addresses? (3) How can the new design handle the current NAT traffic, and work with the existing NAT boxes?

A successful design must answer these questions with the two main goals in mind: be generic and be easy to deploy. We propose to use DNS to learn tunnel end-point addresses, use a generic user-level program on the client host to mask the non-uniqueness of private IP addresses from transport protocols and applications, and use UDP tunnels (instead of IP-in-IP tunnels) to encapsulate packets which can traverse deployed NAT boxes. In the rest of the document we will outline our solution and deployment considerations.

Tunneling Through NAT