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:
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