[137780] in North American Network Operators' Group
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6
daemon@ATHENA.MIT.EDU (Chris Grundemann)
Fri Feb 18 20:59:11 2011
In-Reply-To: <142C67D8-9018-40C6-B052-0C6A577F519C@queuefull.net>
Date: Fri, 18 Feb 2011 18:59:00 -0700
From: Chris Grundemann <cgrundemann@gmail.com>
To: Benson Schliesser <bensons@queuefull.net>
Cc: Zed Usser <zzuser@yahoo.com>, nanog@merit.edu
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Fri, Feb 18, 2011 at 16:48, Benson Schliesser <bensons@queuefull.net> wr=
ote:
>
> I agree that it's an imperfect analogy, so I won't bother defending it. :=
) =A0But my point remains: =A0NAT444 is a deployment scenario, which includ=
es a CGN element. =A0Other deployment scenarios that also include a CGN ele=
ment will have the same issues, and perhaps more. =A0And, indeed, a number =
of "transition" (i.e. exhaustion) scenarios include a CGN. =A0Thus it is ap=
propriate to focus on the root of the problem (CGN) rather than pointing at=
just one scenario that leverages it.
That I'll agree with. It seems to me that what's called for is an
expansion of the tests done for the draft in question to include
other, currently in-vogue, CGN/LSN technologies.
> So... =A0I agree that CGN is painful, relative to native connectivity and=
even relative to CPE-based NAT44. =A0But I'd like to understand why NAT444=
is better or worse than other CGN-based scenarios, before I agree with tha=
t conclusion.
That wasn't the conclusion I drew, can't speak for others of course.
My conclusion is that CGN/LSN is broken, as evidenced by brokenness in
NAT444. I agree that a comparison of all (or some reasonable subset of
all) LSN technologies would be valuable, especially as folks may begin
to be forced to choose one. For now I stick with the ideal: Avoid if
possible. (Dual-stack early, dual-stack often?)
>> If we get dual v4+v6 connectivity quickly enough, we do not need LSN
>> (including NAT444).
>
> Amen, brother. =A0I guess I'm just pessimistic about the definition of "q=
uickly" versus operationally realistic timeframes.
Fair enough, I still have hope. =3D)
~Chris
> Cheers,
> -Benson
>
--=20
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.theIPv6experts.net
www.coisoc.org
