mailing list archives
Re: Common operational misconceptions
From: Masataka Ohta <mohta () necom830 hpcl titech ac jp>
Date: Sat, 18 Feb 2012 20:31:52 +0900
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
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.