Re: Common operational misconceptions

[Owen DeLong <owen () delong com>]

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 
> would be!"  
>
> 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.

Owen