On Feb 18, 2011, at 5:27 PM, Chris Grundemann wrote: > On Fri, Feb 18, 2011 at 16:07, Benson Schliesser <bens...@queuefull.net> > wrote: > >> 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. > > 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
