Roger Marquis wrote: >>> That is a theoretical harm, or rather an opinion of such. It is not >>> supported by the widespread use of IPv4 NAT. In fact the ubiquity of >>> IPv4 NAT is proof that such criticisms are baseless. >> >> Er, no, it's proof that application designers have found work-arounds >> for the lack of address transparency caused by NAT. > > "lack of address transparency caused by NAT" is rhetorical. It would > be more accurate to point out that application designers fixed > protocols that were poorly designed in the first place. That's completely and utterly false.
1. The core Internet protocol suite was never designed or intended to support NAT. NAT breaks IP routing, because IP routing protocols expect IP address prefixes to mean the same thing for every router that makes decisions based on that information. NAT breaks DNS, because DNS (as designed) expects that an IP address will mean the same everywhere in the network. Yes, two-faced DNS exists, but it's an ugly hack and the addresses *do* leak. Actually if there's a single core assumption in the Internet Protocol, it's that everything on the network will use the same packet format and the same address space. 2. No, for better or worse, the Internet was not designed with expectation that all applications will use higher layer identifiers. DNS didn't even exist when the Internet architecture was being worked out, and DNS names have never been suitable as general-purpose application layer identifiers. > They do this in order to keep state as well as NAT. Since > statefulness has to be preserved anyhow there would be no net gain in > doing away with NAT. That's also incorrect. When application writers find that NATs are getting in the way of their applications, they have little choice other than to provide servers in the network core that can relay traffic between application instances behind NATs. And of course this creates more state that doesn't share fate with the endpoints, but it's unavoidable. Without the NATs in the way, many of those applications would not need state other than at the endpoints. > NAT "translates" layers 3 and 4 the same way routers translate MAC > addresses. Bullshit. Routers don't "translate" MAC addresses. They route packets from one L2 network to another. This doesn't affect IP apps at all because apps don't care what the MAC address is, and there was never any expectation in the Internet that MAC addresses would be preserved end-to-end, or even that they would exist. >> A common technique is of course to add an application-specific >> endpoint identifier above whatever method is used to punch a >> session through the NAT. > > What you call "whatever method" firewalls call statefulness. The > session is "punched" by the state engine. NAT is added to that with > little or no overhead. Little or no overhead to the router, you mean. It's a PITA for everyone else. Keith
_______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
