mailing list archives
Re: Common operational misconceptions
From: Owen DeLong <owen () delong com>
Date: Fri, 17 Feb 2012 10:45:26 -0800
On Feb 17, 2012, at 7:20 AM, 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.
Yes... An unfortunate and very damaging side effect to be sure.
An argument you and others have made many times boils down to "but if we never had NAT, think how much better it
To this, the response "so what?" is not unreasonable - organizations which have built up processes and products
around the non-end-to-end model may or may not see a benefit in changing their ways. Asserting that there is
something wrong with existing, succesful business practices is not, by itself, compelling.
People who make money selling weapons don't necessarily see a benefit to peace. People who avoid the high costs of
toxic waste disposal by putting it into ground water don't necessarily see a benefit to having an EPA or laws that
prohibit doing so.
If you're not party to the war and you're not one of the people whose water supply is affected by the toxins flowing
into it, then, the response "so what?" may seem reasonable from your perspective.
NAT is much the same way. It is a form of toxic pollutant that has damaging effects outside of the business that has
chosen to deploy NAT. At best, it started out as a necessary evil for address conservation. Dependence on it beyond
that seems to me to be akin to a form of drug addiction.
While you and I may find this type of packet header manipulation distasteful, there's lots of organizations for which
it's normal operations. The more NAT for v6 gets fought, the more folks will fight to preserve it. Time could be
better spent demonstrating why NAT isn't needed in X or Y use case, and providing configuration snippets / assistance
for non-NAT-based solutions to those various groups.
And I do exactly that when presented with actual use cases where people believe NAT is needed.
You can find several instances of my having done that in previous NANOG threads.