one-up-manship sucks, but correct information is beneficial. ;)
The problem with the term "NAT" as "Network Address Translation" is the
term is often misused/incorrect; most all modern "NAT" implementations
are actually "PNAT" ("Port and Network Address Translation") where the
translator system modifies both the source address and source port
rather than just modifying the source address.
For notes, the earliest translation implementations really were just
address modification, and hence, really were plain "NAT," but the
problem of conflicting port numbers is the reason why just about every
implementation moved to PNAT.
When running a PNAT implementation, you can exhaust the number of
available TCP ports with enough load from client systems. The number of
available TCP ports is typically, but incorrectly, stated as 2^16 ports,
but in practice, you can't use all of them.
Getting around the TCP port count limitation is entirely possible, and
regularly done in large scale networks. The early implementations were
standard "proxy systems/servers" (typically requiring client-side
configuration like, address, port, user/pass, etc.). More modern
implementations are "transparent proxies" and require no client-side
configuration. Transparent proxy implementations (typically) count on
PNAT in order to be "transparent" to the client systems and prevent the
need for client-side configuration.
The mental leap one needs to make in order to understand how to get past
the TCP port count limitation is, understanding that a single public IP
address can be shared by multiple systems simultaneously without
NAT/PNAT or proxies. There are many ways to do it from "load balancing
appliances," to CARP (Common Address Resolution Protocol - free in
OpenBSD), to VRRP (Virtual Router Redundancy Protocol - patented by
Cisco), to other methods. This is often combined with multiple stateful
firewalls where all of the firewalls share their state tables.
Similarly, pools of public IP addresses can also be shared amongst
multiple systems simultaneously. Let's say your shared state table
already has an entry with your source of "aaa.bbb.ccc.ddd port 1331",
with a pool of address, you now have your choice of changing either the
port number or the source address. --This isn't particularly precise,
but it is a good way to reason through it.
AOL used to (and maybe still does?) run some humongous transparent
proxies. If you search around, you'll find some (historic?) complaints
from sites about not being able to block trolls or malicious traffic
from jerks on AOL without blocking everyone on AOL. The only IP the site
owners got was the from the small block dedicated to the AOL transparent
proxies. I think this issue may have been resolved by the "proxy-for"
header being added eventually (i.e. often called a "non-anonymous
proxy"), but my recollection is a bit fuzzy.
The point to take away from this is, AOL, at its height, was able to
stuff all of it's millions of users behind a couple dozen proxies/IP's,
so the number of TCP ports is only a limitation in theory, but it's not
a limitation in practice.
Yogi Beara once said, "In theory, practice and theory are the same, but
in practice, they're not."
The number of available TCP ports is typically, but incorrectly, stated as 2^16 ports, but in practice, you can't use all of them.
That's mainly why I wrote “at most” instead of trying to compute the exact available number, yes.
You don't even theoretically need application-layer gateways to multiply the effective number of ports by a large factor for common loads, of course, as I mentioned; I just erroneously thought such technique was not in common use, per my reply to eggnet.
one-up-manship sucks, but correct information is beneficial. ;)
The problem with the term "NAT" as "Network Address Translation" is the term is often misused/incorrect; most all modern "NAT" implementations are actually "PNAT" ("Port and Network Address Translation") where the translator system modifies both the source address and source port rather than just modifying the source address.
For notes, the earliest translation implementations really were just address modification, and hence, really were plain "NAT," but the problem of conflicting port numbers is the reason why just about every implementation moved to PNAT.
When running a PNAT implementation, you can exhaust the number of available TCP ports with enough load from client systems. The number of available TCP ports is typically, but incorrectly, stated as 2^16 ports, but in practice, you can't use all of them.
Getting around the TCP port count limitation is entirely possible, and regularly done in large scale networks. The early implementations were standard "proxy systems/servers" (typically requiring client-side configuration like, address, port, user/pass, etc.). More modern implementations are "transparent proxies" and require no client-side configuration. Transparent proxy implementations (typically) count on PNAT in order to be "transparent" to the client systems and prevent the need for client-side configuration.
The mental leap one needs to make in order to understand how to get past the TCP port count limitation is, understanding that a single public IP address can be shared by multiple systems simultaneously without NAT/PNAT or proxies. There are many ways to do it from "load balancing appliances," to CARP (Common Address Resolution Protocol - free in OpenBSD), to VRRP (Virtual Router Redundancy Protocol - patented by Cisco), to other methods. This is often combined with multiple stateful firewalls where all of the firewalls share their state tables.
Similarly, pools of public IP addresses can also be shared amongst multiple systems simultaneously. Let's say your shared state table already has an entry with your source of "aaa.bbb.ccc.ddd port 1331", with a pool of address, you now have your choice of changing either the port number or the source address. --This isn't particularly precise, but it is a good way to reason through it.
AOL used to (and maybe still does?) run some humongous transparent proxies. If you search around, you'll find some (historic?) complaints from sites about not being able to block trolls or malicious traffic from jerks on AOL without blocking everyone on AOL. The only IP the site owners got was the from the small block dedicated to the AOL transparent proxies. I think this issue may have been resolved by the "proxy-for" header being added eventually (i.e. often called a "non-anonymous proxy"), but my recollection is a bit fuzzy.
The point to take away from this is, AOL, at its height, was able to stuff all of it's millions of users behind a couple dozen proxies/IP's, so the number of TCP ports is only a limitation in theory, but it's not a limitation in practice.
Yogi Beara once said, "In theory, practice and theory are the same, but in practice, they're not."