pCDN:NAT

From NMSL
Revision as of 21:19, 27 February 2008 by Mbagheri (talk | contribs)

NAT

Network Address Translation (NAT) is a technique that allows multiple hosts on a private network to access the Internet using a single IP address. This involves overwriting the IP address and port numbers of packets in the router. A NAT device keeps track of the connections initiated by hosts inside its private network and adds a port mapping for each. Any incoming packet is examined to check if it belongs to a session initiated by one of the hosts inside the private network. The packet is forwarded to the appropriate host if a mapping exists for it, otherwise the packet is dropped. Therefore, hosts behind a NAT cannot act as a server unless the NAT device is configured to forward the traffic appropriately. This causes problems for P2P file sharing and VoIP applications.

NAT Traversal

Since NAT behavior is not standardized, no one solution exists for the above problem. However in some situations NAT Traversal techniques are useful. Some of the techniques such as STUNT require a public server with global access to assist in discovering the NAT behavior. Other techniques take advantage of NAT configuration protocols such as UPnP IGD to learn the public IP address and add port mappings.

In pCDN, a peer receives a list of potential senders from the server in response to its query for a specific file. The peer chooses some of these senders, connects to them over TCP, and downloads the requested file. All potential senders are listening for incoming connections from other peers. If peers are behind NAT however, no connection can be established unless the NAT device is configured properly to pass the traffic through. Moreover, the downloading peer needs to be aware of the public IP and external port of the sender it is going to connect to. This information should be discovered by each peer through examining and configuring the NAT device it is behind, and reporting it to the pCDN server. The pCDN server in turn provides downloading peers with this information.

Issues

  • Not all NAT devices support UPnP IGD protocol, therefore we cannot rely on the NAT device to be easily configurable.
  • The behavior of NAT devices can not be predicted precisely. A NAT device may assign a new port number for a connection established on the same local port twice. Therefore, even if we discover the mapping for a connection on local port through some mechanism similar to STUNT, closing the connection and opening it again does not hold the same mapping.
  • No new mapping is automatically created unless a packet is sent from within the private network. Therefore, only listening on a local port number does not allow incoming traffic.