Re: [Int-area] draft-bonica-v6-multihome

[Brian E Carpenter <[e-mail]>]

Hi Fred,

On 11/09/2012 01:07, Fred Baker (fred) wrote:
> 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.

That's true, but those proposals did respect e2e address transparency
and uniqueness as far as the least significant 64 address bits went.
I really think everybody took it for granted.

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

Indeed, and the nub of that from the point of view of referrals is this:

   o  An application instance wishing to establish communication with a
      peer "behind" an NPTv6 Translator may need to use a different
      address to reach that peer depending on whether the instance is
      behind the same NPTv6 Translator or external to it.

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

Well yes, that is the whole point of the referrals discussion, which
also includes discussion of the fact that DNS isn't a complete
solution. My point is that encouraging NPTv6 propagates this set
of problems in the IPv6 world. They aren't going to go away
along with IPv4.

If that's going to be part of the future I think we'd better face up
to it (hence http://tools.ietf.org/html/draft-carpenter-referral-ps).

   Brian