[149989] in North American Network Operators' Group
Re: Common operational misconceptions
daemon@ATHENA.MIT.EDU (David Barak)
Fri Feb 17 10:21:40 2012
Date: Fri, 17 Feb 2012 07:20:37 -0800 (PST)
From: David Barak <thegameiam@yahoo.com>
To: "nanog@nanog.org" <nanog@nanog.org>
In-Reply-To: <BE94FC87-74BF-4791-95D4-2336C3298F79@delong.com>
Reply-To: David Barak <thegameiam@yahoo.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
>From: Owen DeLong owen@delong.com=0A=0A>Sigh... NAT is a horrible hack tha=
t served us all too well in address conservation. Beyond that, it is merely=
a source of pain.=0A=0AI understand why you say that - NAT did yeoman's wo=
rk in address conservation.=A0 However, it also enabled (yes, really) lots =
of topologies and approaches which are *not* designed upon the end-to-end m=
odel.=A0 Some of these approaches have found their way into business proces=
es.=A0 =0A=0AAn argument you and others have made many times boils down to =
"but if we never had NAT, think how much better it would be!"=A0 =0A=0ATo t=
his, 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.=A0 Asserting that there is somet=
hing wrong with existing, succesful business practices is not, by itself, c=
ompelling.=A0 =0A=0AWhile you and I may find this type of=A0packet header m=
anipulation distasteful, there's lots of organizations for which it's norma=
l operations.=A0 The more NAT for v6 gets fought, the more folks will fight=
to preserve it.=A0 Time could be better spent demonstrating why NAT isn't =
needed in X or Y use case, and providing configuration snippets / assistanc=
e for non-NAT-based solutions to those various groups.=0A=0ADavid Barak=0AN=
eed Geek Rock? Try The Franchise: =0Ahttp://www.listentothefranchise.com
