m:n-Translation, m>=1 and m>=n
Dynamic address translation is necessary when the number of IPs to
translate does not equal the number of IPs to translate to, or they
are equal but for some reason it is not desirable to have a static
mapping. The number of hosts communicating is generally limited by
the number of NAT IPs available. When all NAT IPs are being used than
no other connections can be translated and must therefore be rejected
by the NAT router, for example by sending back 'host unreachable'.
Dynamic NAT is more complex than static NAT, since we must keep track
of communicating hosts and possibly even of connections which requires
looking at TCP information in packets.
As mentioned above, dynamic NAT may also be useful when there are enough NAT IPs, i.e. when m=n. Some people use this as a security measure: it is impossible for someone outside a network to get useful IP numbers to connect to of hosts behind a NAT router doing dynamic address translation by looking at connections that take place, since next time the same host may connect using a completely different IP. In this special case even having more NAT IPs than IPs to be translated (m<n) may make some sense. As I might put it, there is no idea that is not going to be used by someone somewhere, and it will even be right to do so because it is impossible to foresee the infinity of possible situations.
Connections from outside are only possible when the host that shall
be reached still has a NAT-IP assigned, i.e. if it still has an entry
in the dynamic NAT table, where the NAT router keeps track of which
internal IP is mapped to which NAT IP. For instance, non-passive FTP
sessions, where the server attempts to establish the data-channel,
are no problem (for protocol specific problems see Section ), since
when the server sends its packets to the FTP-client there is already
an entry for the client in the NAT-table, and it is extremely likely
it still contains the same client-IP to NAT-IP mapping that were there
when the client started the FTP-control channel, unless the FTP session
has been idle for longer than the timeout of the entry.
However, if an outsider wants to establish a connection to a certain
host on the inside at an arbitrary time there are two possibilities:
the inside host does not have an entry in the NAT-table and is therefore
unreachable, or it has an entry, but which NAT-IP must be used is
unknown, except, of course, the IP to connect to is known because
the internal host is communicating with the outside. In the latter
case, however, only the NAT-IP is known but not the internal IP of
the host, and this knowledge is valid only while the communication
of the internal host takes place plus the timeout of the entry in
the NAT routers table.
Example: