james woodyatt wrote: > On Nov 25, 2008, at 15:11, Sam Hartman wrote: >> >> Keith, would the NAT-66 proposal plus some mechanism for a server >> inside the NAT to ask the NAT for its global address be sufficient to >> meet the needs described above? > > No. RFC 3424 is the IAB Considerations document covering that problem. > I'm tempted to copy and paste highlights from that ancient scripture > here, but I don't think I'd know where to stop. As the kiddies say, > Read The Whole Thing. > > The basic problem with NAT66 is that it introduces the possibility of > more than one global IPv6 address realm. Where there is more than one, > there is *any* number, not just the current realm and the single realm > on the other side of the relevant NAT66 box.
I'm not sure about that. Conflicting use of address space is probably the biggest single source of NAT-related pain that network operators experience. If enterprise network operators can still NAT without reusing the same addresses in different realms, I think they'll mostly do so. And regardless of what else happens with NAT66, I think it's reasonable for IETF to make it really clear that apps aren't expected to deal with conflicting address assignment in IPv6. > Fixing your self-address in whatever address realm any given > communications peer happens to reside is the canonical problem that NAT > causes for applications developers, and NAT66 is no exception to that. No, it's only one of several canonical problems that NAT causes for applications developers. If we narrow the focus to that one problem, we'll miss the boat - we won't produce a "solution" that makes life any easier for apps developers. > If we're going to go very far down this road toward standardizing on a > NAT66 "solution," then I would humbly suggest that it doesn't make much > sense for there to be a single global DNS horizon where we have multiple > global address realms. If we were going down that road, I'd agree with you. But I'll make a stronger statement - any "solution" to NATxx (for any value of xx) that requires split DNS should be considered a non-starter. It doesn't make much sense to improve consistency at the IP naming layer if you're going to degrade consistency at the DNS naming layer. Keith _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
