On Sep 4, 2012, at 9:17 AM, Brian E Carpenter wrote: > The multihoming-without-ipv6nat draft notes that e2e address transparency > wasn't listed as a goal in RFC 3582. Having been co-chair of that WG, I'm > pretty sure that's because we never imagined anyone proposing anything else > for IPv6. That was obviously a failure of the imagination. But apart from > that, I don't think it's reasonable to sweep it (and the referral problem > that derives from it) under the carpet. It's a problem faced by essentially > every distributed app. So I think all proposals for multihoming that affect > e2e address transparency need to analyse their impact on referrals.
If the working group that came up with 3582 had a failure of imagination, it also had a failure of memory. The GSE proposal of 1996 and the 8+8 proposal that came later certainly imagined that the locator might change its encoding as the packet wandered around. In any event, the implications for the fact that the locator might change end to end is addressed in https://tools.ietf.org/html/rfc6296#section-5. The same considerations apply to ILNP when it is permitted to translate between internal and external prefixes in the locator. In short, DNS needs to somehow know that the translation occurs and what the related addresses are, so that it can deliver them all in a DNS response. RFC 6296 also discussed hair pinning, because RFC 4787 among others do as well. IMHO, that is actually something that should be disabled; the host should use Happy Eyeballs, and should discover (whether from a split DNS or by trying all the addresses) that the one that works internally is the internal one. That addresses a list of ills. Similar considerations apply to SIP/SDP and probably other protocols that are silly enough to use a network layer address as an application layer identifier - and so, by the way, have problems with mobility. _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
