[137776] in North American Network Operators' Group
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6
daemon@ATHENA.MIT.EDU (Benson Schliesser)
Fri Feb 18 18:49:40 2011
From: Benson Schliesser <bensons@queuefull.net>
In-Reply-To: <AANLkTim2SXsymqJeKFHhLOVSBqZy1JF3pDw9A2C3+S2g@mail.gmail.com>
Date: Fri, 18 Feb 2011 17:48:25 -0600
To: Chris Grundemann <cgrundemann@gmail.com>
Cc: Zed Usser <zzuser@yahoo.com>, nanog@merit.edu
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Feb 18, 2011, at 5:27 PM, Chris Grundemann wrote:
> On Fri, Feb 18, 2011 at 16:07, Benson Schliesser =
<bensons@queuefull.net> wrote:
>=20
>> Broken DNS will result in problems browsing the web. That doesn't =
make it accurate to claim that the web is broken, and it's particularly =
weak support for claims that email would work better.
>=20
> I don't think that's a great analogy. NAT444 is CGN, the web is not
> DNS. If I say I can chop down a tree with a red ax, can you disprove
> that by saying that you can chop it down with any color ax?
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.
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.
> 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.
Cheers,
-Benson
