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 extremely dubious. > 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 deployed. Keith _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf