Iljitsch van Beijnum wrote:
I don't think the IETF creates protocols that fail when used through a
NAT when it's just as easy to make the protocol work though the NAT as
is the case with FTP.
yes, but it's not "just as easy" to make FTP work through the NAT...at
least, not without losing the ability for one host to transfer files
between two other hosts.
(it turns out that in the modern world, this feature of the FTP protocol
is dangerous for security reasons. but it was a useful feature, and the
existence of NATs make it difficult to re-implement that feature.)
However, the reason why MOST protocols/applications have trouble with
NAT is because they need to receive incoming sessions. Short of
rewriting the protocol to work over UDP or through a third-party
server, pretty much the only way to "traverse" NAT in these cases is
to go up to the NAT device, and ask it to open up a TCP port, pretty
please with a cherry on top?
This works well if:
- the NAT device is a fairly modern one created for a market where
this functionality is considered important (i.e., home users)
- the application or the OS implements the necessary open sesame logic
- there is a well-reachable server providing referrals
- there is only a single NAT between the outside and the host trying
to receive incoming TCP sessions
- and the site isn't relying on the NAT to also be a firewall.
...and the only problem I have with the above is that the word MOST can
be misleading. it's not as if most of the problems with NATs would go
away if only all NATs were to suddenly support UPnP extensions to allow
NAT traversal. that would certainly help, but significant brain-damage
would remain. also, your "MOST" is based on how things are today, but
the net seems to change fairly significantly every two years.
The first three are likely to get better in the future, but more than
one NAT is extremely likely to become more common as we run out of
IPv4 addresses. Note though that even with the above in place there
are still problems caused by NAT that can only be solved by additional
application logic or application layer gateways in the NAT.
and only if the NAT can somehow be aware of every application that needs
to traverse it - including proprietary applications, enterprise-specific
applications, applications that need end-to-end encryption, and so on.
in other words, putting ALGs in the NATs is not a practical solution.
(The case where multi-party referrals by IP address happen. Yes, by
FQDN would be better but not every host has a working DNS name.)
which, coupled with several other reasons, implies that FQDNs would not
necessarily be better.
So whichever way you slice it, the best case scenario for NAT is that
it doesn't get in the way. The worst case is that it absolutely,
positively breaks your application despite huge amounts of NAT
workaround logic and a lot time spent debugging the problem. As with
most things in life, some people are lucky enough to live in a best
case world, others are prone to be bitten by the worst case more than
their fair share.
yup. the point is that it's a large and diverse network, and sweeping
generalizations about things like how NAT affects that network are
What I consider the most important problem with NATs is that they
don't fail gracefully.
what I consider the most important problem with NATs is that they're not
accountable for the damage that they do. similarly for interception
proxies. so when the application breaks, the reason it breaks is not
apparent to the user or to the party that installed the box that
modified the traffic, and it's hard to get the problem fixed (e.g. by
firing the sysadmin who installed the damn thing, or by ceasing to do
business with the NAT or proxy vendor that misrepresented his product).
things that actively modify traffic without being visible to end systems
are almost inherently going to cause huge problems if they're widely
Ietf mailing list