m:n-Translation, m>=1 and n=1
A very special case of dynamic NAT is m:1-translation, a.k.a. masquerading
which became famous under that name because Linux can do it. It is
probably the kind of NAT-technique that is used most often these days.
Here many IP numbers are hidden behind a single one. In contrast to
the original dynamic NAT this does not mean there can be only one
connection at a time. In masquerading an almost arbitrary number of
connections is multiplexed using TCP port information. The number
of simultaneous connections is limited only by the number of TCP-ports
available.
A special problem of masquerading is that some services on certain hosts only accept connections coming from privileged ports in order to ensure that it does not come from an ordinary user. The assumption that only the superuser can access those ports is not valid, since on DOS or Windows machines everybody can use them, nethertheless, some programs rely on this and cannot be used over a masqueraded connection. The reason that at least by the Linux implementation no privileged ports are used for masquerading is not to interfere with 'regular' connections to these ports. Masquerading usually uses ports in the upper range, in Linux this range starts at port 61000 and ends at 61000+4096, which is the default and can easily be changed by editing linux/include/net/ip_masq.h. This also shows that the Linux implementation by default only allows 4096 concurrent connections. To allow masqueraded connections on ports outside of such a port range requires keeping and managing even more information about the state of connections. Linux, for example, simply treats all packets with destination IP = local IP and destination port is inside the range used for masquerading , as packets that have to be demasqueraded, i.e. they are answers to packets that have been masqueraded on their way out.
Incoming connections are impossible with masquerading, since even
when a host has an entry in the masquerading table of the NAT device
this entry is only valid for the connection being active. Even ICMP-replies
that belong to connections (host/port unreachable) do not get
through to the sender automatically but must be filtered and relayed
by the NAT-routers software.
While it is true that incoming connections are impossible we can take
additional measures to enable them, but they are not part of the masquerading
code. We could, for an example, set up the NAT-device so that it relays
all connections coming in from the outside to the telnet-port to a
host on the inside. However, since we have just one IP that is visible
outside for enabling incoming connections for the same service but
for different hosts on the inside we must listen on different ports
on the NAT-device, one for each service and internal IP. Since most
applications listen on well-known ports that cannot be easily (and
transparently!) changed, this is quite inconvenient and often no option,
especially not for public services. The only solution is to have as
many (external) IPs as the number of services that shall be provided.
An external IP can still be shared by different services, and then
be remapped to different internal IPs using NAT, but that is not part
of masquerading, then.
Example:
The greatest advantage of masquerading for many people is that they only need one official IP-address but the entire internal network can still directly access the Internet. This is so important because IP addresses have become quite expensive. As long as there are application level gateways we do not need any IPs or any kind of NAT and one IP is still enough, but for some protocols, e.g. all UDP based services, there is just no gateway so direct IP connectivity is necessary.
At the time of this writing ther existed an Internet Draft (which I should not reference here, since it is just a draft) from the same people who wrote RFC 1631 (NAT). It explains masquerading, that they call Network Address Port Translation (NAPT), in great depth. There is no IETF-paper (none that I could find, at least) on more recent forms of NAT like the ones introduced in the following chapters, although there are (commercial) implementations of them. It seems like for the IETF NAT only exists for helping to solve the classical Internet address space shortage problems described above.