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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf