Network Address Translation

Design Guidelines for Applications

• Either make it two-party only (e.g. strict client/server). or have a central party that contacts all of the other parties and looks up those addresses using their DNS names. you cannot expect to set up arbitrary communications paths.
• Don't make any assumption at all about the meanings of, stability of, or uniqueness of, the IP address of the communicating parties
• Use TCP only, with short-lived connections (say, no more than a few minutes, or no more than the TTL of the A record returned from the DNS lookup)
• Instruct your customers that all servers (i.e., all parties that accept connections rather than initiate them) which need to communicate with clients on the other side of a NAT, must be located in public address space.
• Use DNS names, rather than IP addresses, to identify your endpoints for the purpse of reaching them across the net
• All DNS names used in this way need to be evaluated from the same point.
• If you need to log events, assign each party a unique name for logging purposes. don't rely on either the IP address or the DNS name.
• Authenticate using TLS and client certs rather than IPsec.
• Bind your servers to well-known ports rather than having them dynamically assigned.
• Do a DNS lookup of your destination immediately before setting up each TCP connection.
• Don't rely on an DNS inverse address (PTR) lookup to give you the name of a process/service for the purpose of reaching it later.
• Don't rely on a process's idea of its own DNS name for the purpose of reaching it later - many hosts don't know their own names.
• If your application needs to access multiple services on the same host (e.g., NFS mount and NFS access), multiplex all of those service requests on the same port. Don't assume that port A on host address X and port B on host address X actually reach the same host.
• Similarly, don't do protocol feature negotiation using port numbers, and don't do protocol version negotiation using port numbers. design your protocol so that it can negotiate version and/or features in-band. this includes use of TLS/SSL if this is optional.

If you find that you cannot make your application work under these conditions: attempt to detect the presence of NATs so that you can display a reasonable error message, e.g.,

You have a NAT installed between A and B and this application
fundamentally cannot work over a NAT.

You have a NAT installed between A and B.  This application cannot work
over a NAT without the explicit support in the NAT for this
application.  Contact your NAT vendor to determine whether
your NAT can be modified to support this application.

• NAT Check; see also Peer-to-Peer Communication Across Network Address Translators
• On the feasibility of Commercial, Legal P2P Content Distribution (CCR January 2006) claims that "data collected by the MSN Messenger Customer Improvement Program indicate that the percentage of NATed nodes in the United Kingdom and in the US, as of April 2005, was more than 50% of the broadband users."
• NAT Classification Results using STUN
• See also What NATs break.
• UPnP: Internet Gateway Device, a protocol for traversing NATs
• IP Network Address Translation, diploma thesis by Michael Hasenstein, 1997
• AVES: Address Virtualization Enabling Service
• Grenville Armitage has tabulated the fraction of users behind a NAT for Quake III, "Inferring The Extent of Network Address Port Translation at Public/Private Internet Boundaries" (Grenville Armitage)

Last updated by Henning Schulzrinne