On 2009-11-11 10:05, Roger Marquis wrote: > Brian E Carpenter wrote: >> The harm is generic harm to innovation and applications architecture. > > 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. 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. In many cases that ends up being the misuse of HTTP as a generic transport protocol, since pretty much every NAT/firewall combination lets HTTP through. The node/supernode system in Skype exists mainly for this reason, for example. When I mentioned VoIP, I was not only thinking of the SIP/STUN/ICE/TURN mess. ... >> Mainly because the problems are totally undiagnosable, especially for >> the typical home user/help desk combination. And should we really be >> pushing technology that we know to be unreliable? As an engineer, that's >> actually a violation of my professional ethics. > > As an engineer you should know how to implement logging in such a way that > permits monitoring of your own networks. Some very large NAT'd networks > have no such logging issues. There's nothing vague about the complete lack of useful logging of NAT bindings in the D-Link and LinkSys devices I have used in my home, which makes it totally impossible to track and trace problems. This covers the vast majority of NAT deployment in the Internet. I don't know whether all enterprise-grade NATs keep better logs; I'm glad to hear that some do. Bria _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
