[137781] in North American Network Operators' Group
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6
daemon@ATHENA.MIT.EDU (Owen DeLong)
Sat Feb 19 01:04:08 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <AANLkTinhkZ44QysSe3BpE6QELBOEMe0jCCndyO51J-FB@mail.gmail.com>
Date: Fri, 18 Feb 2011 22:00:00 -0800
To: Chris Grundemann <cgrundemann@gmail.com>
Cc: nanog@merit.edu, Zed Usser <zzuser@yahoo.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Feb 18, 2011, at 5:59 PM, Chris Grundemann wrote:
> On Fri, Feb 18, 2011 at 16:48, Benson Schliesser =
<bensons@queuefull.net> wrote:
>>=20
>> I agree that it's an imperfect analogy, so I won't bother defending =
it. :) But my point remains: NAT444 is a deployment scenario, which =
includes a CGN element. Other deployment scenarios that also include a =
CGN element will have the same issues, and perhaps more. And, indeed, a =
number of "transition" (i.e. exhaustion) scenarios include a CGN. Thus =
it is appropriate to focus on the root of the problem (CGN) rather than =
pointing at just one scenario that leverages it.
>=20
> 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.
>=20
That's a serious expansion to the testing matrix.
I would rather see those other technologies get their own draft with =
their
own testing matrix as this is far more likely to be achievable.
>> So... I agree that CGN is painful, relative to native connectivity =
and even relative to CPE-based NAT44. But I'd like to understand why =
NAT444 is better or worse than other CGN-based scenarios, before I agree =
with that conclusion.
>=20
> 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?)
>=20
Agreed.
>>> If we get dual v4+v6 connectivity quickly enough, we do not need LSN
>>> (including NAT444).
>>=20
>> Amen, brother. I guess I'm just pessimistic about the definition of =
"quickly" versus operationally realistic timeframes.
>=20
> Fair enough, I still have hope. =3D)
> ~Chris
>=20
My thinking is that faced with disconnection after the fact suddenly =
causing
me to choose between restoration by dual stacking vs. restoration by =
NAT444
(or almost any other form of LSN) leads any sane person to restoration =
by dual
stacking.
Owen
