Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)

[Owen DeLong <owen () delong com>]

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:
> > 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.
>
> 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.
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.
>
> 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?)
Agreed.

> > > If we get dual v4+v6 connectivity quickly enough, we do not need LSN
> > > (including NAT444).
> >
> > Amen, brother.  I guess I'm just pessimistic about the definition of "quickly" versus operationally realistic 
> > timeframes.
>
> Fair enough, I still have hope. =)
> ~Chris
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