The real issue with NAT is not the address translation itself, but the limitations placed on communicating with unsolicited hosts. Network designs, such as client-server and peer-to-peer, are hampered when one or more hosts suffer from NAT -- creating a connection generally requires an unsolicited message somewhere along the line.

Before the client application initiates the connection, or selects a coping strategy, it should determine the NAT limitations of both hosts. While the client can detect its own network type, it generally requires some secondary communication channel for learning the NAT limitations of the remote host -- generally some sort of advertisement or registration process with an arbitrary host on the Internet (maybe even related to the probe server itself).

Regardless how this information is communicated, the client application uses both data points to select an appropriate coping strategy as follows:

Local Host			Remote Host
			Permissive	Protective	Consistent	Restrictive
Permissive			none	match	invite	invite
Protective			none	match	invite	invite
Consistent			none	match	invite	proxy
Restrictive			none	match	proxy	proxy

For the table above, recall that direct network connections are functionally identical to permissive networks. Each strategy assumes that both hosts have already verified that they are online, determined their own network type by contacting a probe server (establishing at least 1 network mapping for the endpoint), and know their own apparent host address and port.

Some of these techniques require negotiation over a secondary communication channel between the hosts: the NAT probe server, a network game tracker, or another host that is connected to both client and server.

Coping Strategies

Matchmaker, Matchmaker

Before the remote host can receive packets from the client, it must create a NAT mapping to a port on the client machine.

1. The client sends a matchmaker request to the remote server over the secondary channel.
2. The server sends an empty packet with TTL=2 to the apparent address of the client.
3. The server's NAT creates a mapping between the endpoints, allowing incoming packets.
4. The client proceeds to connect normally.

This Party Is Invitation Only

Because the remote host cannot receive unsolicited connection requests, it must establish the network mapping for itself.

1. The client sends an empty packet with TTL=2 to the apparent address of the remote server.
2. The client's NAT creates a mapping between the endpoints, allowing incoming packets.
3. The client sends a invitation message to the remote server over the secondary channel.
4. The client starts listening for an incoming connection request.
5. The server proceeds to connect to the client.

The biggest requirement for this process is that both hosts have a consistent address and port number, otherwise one cannot establish a mapping to the other, and incoming packets will be discarded.

Your Proxy Server Or Mine?

Neither host allows unsolicited connection requests, so one finds a well-connected 3rd party to relay packets between them.

1. The client connects to a proxy server on the Internet.
2. The proxy server relays all client traffic through a non-NAT network endpoint.
3. The client sends a invitation message to the remote server over the secondary channel.
4. The client starts listening for an incoming connection request.
5. The server proceeds to connect to the client, relayed by the proxy server.

This proxy server may run as part of the probe server process or a standard proxy protocol like SOCKS, but regardless, it requires bandwidth and adds latency to relay messages between the hosts. However, without the help of a proxy, there is no way for these hosts to connect (short of disabling or reconfiguring their NAT).

Copyright (c) 1999-2003 Matt Slot and Ambrosia Software, Inc.