David Barak wrote:
From: Owen DeLong owen@delong.com
Sigh... NAT is a horrible hack that served us all too well in address conservation. Beyond that, it is merely a source of pain.
I understand why you say that - NAT did yeoman's work in address conservation. However, it also enabled (yes, really) lots of topologies and approaches which are *not* designed upon the end-to-end model. Some of these approaches have found their way into business proceses.
I'm afraid both of you don't try to understand why NAT was harmful to destroy the end to end transparency nor the end to end argument presented in the original paper by Saltezer et. al: The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. While plain NAT, which actively hide itself from end systems, which means there can be no "knowledge and help of the application" expected, is very harmful to the end to end transparency, it is possible to entirely neutralize the harmful effects, by let NAT boxes ask help end systems.
An argument you and others have made many times boils down to "but if we never had NAT, think how much better it would be!"
The reality is much better that NAT is not so harmful if NAT clients and gateways are designed properly to be able to reverse the harmful translations by NAT gateways. I have running code to make the reverse translations, with which protocols such as ftp with PORT commands are working. Masataka Ohta