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

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Sep 2012 17:17:59 +0100

Hi,

As far as I understand it without seeing a complete "life cycle" of
a multihoming failover, this proposal only works because of a three-way
collaboration between both ISPs concerned and the site. Unless I've
misunderstood something, that is almost the same as is required to make
the draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat solution work too.
In both cases, something is needed to avoid packets with ISP A's prefix
being discarded by ISP B's ingress filters. The fact that their internal
prefix has been translated in one case is beside the point.

If that is correct, this common aspect should be in its own draft. Then
we can see a straight comparison between the two approaches.

I'd also like to see a detailed goal-by-goal comparison with the goals defined
in RFC 3582. Back in the MULTI6 WG, that was the approach we took in
comparing proposed solutions.

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.

Regards
   Brian

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 5 Sep 2012 20:40:41 -0400

Hi Brian,

Comments inline.....

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Tuesday, September 04, 2012 12:18 PM
> To: Internet Area; [email-masked]
> Subject: draft-bonica-v6-multihome
> 
> Hi,
> 
> As far as I understand it without seeing a complete "life cycle" of a
> multihoming failover, this proposal only works because of a three-way
> being discarded by ISP B's ingress filters. The fact that their
> internal prefix has been translated in one case is beside the point.

Yes! There is significant commonality between draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat and draft-bonica-v6-multihome. Both drafts set out to satisfy the requirements of RFC 3582. In both drafts, a mechanism is required to prevent outbound packets from being discarded by ISP uRPF filters. In both drafts, that mechanism requires collaboration among the site and its ISPs.

> I'd also like to see a detailed goal-by-goal comparison with the goals
> defined in RFC 3582. Back in the MULTI6 WG, that was the approach we
> took in comparing proposed solutions.

I agree that a compare-and-contrast draft would be helpful! Maybe you, a couple of the authors of draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat and I could collaborate on such a draft. Let's discuss this possibility off line.

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

Also agreed. We might also want to reinvigorate your work on referrals.

                                                Ron

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 11 Sep 2012 00:07:57 +0000

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Sep 2012 08:06:25 +0100

Hi Fred,

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

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

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 11 Sep 2012 07:21:35 +0000

>      behind the same NPTv6 Translator or external to it.

a problem Happy Eyeballs easily addresses, and which RFC 3484 and 3484-bis do not.

> my point is that encouraging NPTv6 propagates this set

Well, yes, but since edge networks are *not* getting PA addresses from each of their upstream providers and putting a /64 on each LAN from each such address, but instead getting PI address space, we have no scalable solution for that issue.

What's that rule called? TAANSTAAFL, as I recall. Pretending won't make it otherwise. Either the service providers deal with the complexities of the IPv4 route table, or the edge networks deal with the complexities of managing prefixes from each of multiple upstream PA prefixes, or DNS advertises inside and outside addresses somehow. Pick one.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Sep 2012 10:36:53 +0100

> What's that rule called? TAANSTAAFL, as I recall. Pretending won't make it otherwise. Either the service providers deal with the complexities of the IPv4 route table, or the edge networks deal with…

This being the Internet, I expect we'll pick several. But indeed, we have
to deal with current reality and also try to influence long term trends
in a desirable way. I think that getting the problem area well described
is the first step.

    Brian

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 11 Sep 2012 16:38:49 +0000

> in a desirable way. I think that getting the problem area well described

I'll suggest that you and I collaborate on a note describing the issue, and why having applications know anything about network layer addresses in the first place is unwise. Sometimes necessary, perhaps, but implies the design decision to make this issue hard for that application, and to be avoided or mitigated when possible. We can refer to RFC 3439's section 2.2.2.