Common operational misconceptions

Sat Feb 18 11:31:52 UTC 2012

David Barak wrote:

>> From: Owen DeLong owen at 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