Review: Peer-to-Peer Communication Across Network Address Translators

(As discussed with Stefan, this review is _not_ for "An Architecture
For Content Routing Support..." as the link specifies. It is for the
paper "Peer-to-Peer Communication Across Network Address Translators",
which I wrote prior to the last minute change in the paper-reading
schedule.)

Paper: "Peer-to-Peer Communication Across Network Address Translators"

        As peer-to-peer applications gain popularity, it becomes important for
home users to be able to establish UDP and TCP connections between each
other. However, Network Address Translators (NATs), which may sit
between peers wanting to communicate, make it difficult for such
connections to be easily established. Essentially, the problem is that
the network address that a given node thinks it has is different from
the network address that another node on the opposite side of a NAT
must use in order to communicate with that host. The paper
"Peer-to-Peer Communication Across Network Address Translators"
discusses a solution to this problem and evaluates how well it works in
practice.

        One simple solution that the paper mentions is that of Relaying. In
relaying, peers that wish to communicate with each other, but are
hampered by intermediary NATs, establish a connection to a rendezvous
server. Whenever one peer wants to send a message to another, they
simply send it to the rendezvous server, which forwards it to the other
peer.

        The solution that this paper examines in more depth is called Hole
Punching. UDP Hole Punching, like Relaying, involves the use of a
Rendezvous Server. Peers establish a connection with the rendezvous
server, informing it of their public and private addresses. The public
address of a node is the address as visible on the side of the NAT
opposite from where the node is (i.e., the address that the rendezvous
server sees), and the private address of a node is the address that the
node believes it is assigned. When another peer B wants to send data to
A, it will ask the rendezvous server for help. The server will respond
by telling B about A's public and private address. Furthermore, the
server will tell A that B is trying to send data to it, and at the same
time tell A about B's public and private endpoints. A and B will then
proceed to try to send UDP packets to each other using both the public
and private end points. Data should be able to be sent successfully
using one of these endpoints, as long as the NAT supports consistent
endpoint translation.

        TCP hole punching is very similar, except it requires special
functionality from the operating system's socket API. In particular,
one must be able to listen for connections on the same port on which
outgoing connections are being made. This is supported by many
operating systems via a TCP socket option called SO_REUSEADDR.

        The results of the paper's evaluation were that in 82% of the cases
basic compatibility with UDP hole punching was supported. Furthermore,
in 64% of the cases, basic compatibility with TCP hole punching
existed.

        Overall this was a good paper. The knowledge provided within this
paper provides very relevant information for implementers of NATs so
that they can design their products with an eye to supporting
peer-to-peer communication.
Received on Fri Dec 01 2006 - 15:44:50 EST