Network Address Translation
flexnes: flexible NAT
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
- 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
- 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
- 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.
Internet Technical Notes and Resources
by Henning Schulzrinne