On Oct 25, 2010, at 8:42 AM, Chris Engel wrote: > Regardless, nothing the authors are doing with this flavor of NAT (unless I'm > mistaken about it) should break end to end connectivity between devices > running IPv6 since it's a 1:1 stateless mapping. A FW with statefull > inspection and packet filtering rules would...but in that case the person > deploying the FW WANTS that connectivity broken. If you're trying to argue > that people should not be allowed to deploy FW's.... well then, good luck > with that.
Agreed. Not that there are not issues with prefix translation; there are applications and application deployments that make the (for the past 15 years indefensible) assumption that an address carried as a literal in an application will be meaningful to its peer, and those applications will have the same RFC 2993 problems that IPv4 NAT imposes. However, as your say, prefix translation enables any two interfaces in the network to communicate as long as the application doesn't depend on that assumption. By the way, those applications have problems with IPv4 to IPv6 transition even without the NAT. Imagine that Alice and Bob have IPv6 connectivity but not IPv4 connectivity - we have progressed to a point at which either one of them lacks an IPv4 address at all or routing between their IPv4 domains is broken. Imagine Alice connects to Bob to open an http, sip, or whatever session, and Bob replies with either an IPv4-literal referral or an image pointer that contains an IPv4 literal. Alice won't be able to access it. So, from my perspective, the time has come to get over it. Applications should deal in application concepts like DNS names, and should not impose any coupling to the network layer. That has to become true with or without NAT for the transition to occur. Once we have done that, giving the edge networks independence from their upstream (internally they can use a ULA or whatever) and the transit networks the ability to assume that prefixes are PA (there are O(10^4) networks they care about, not O(10^7) or greater) should be straightforward. _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
