Subject: [v6ops] posted draft-ietf-v6ops-happy-eyeballs-04

From: "Dan Wing" <[email-masked]>
Date: Wed, 14 Sep 2011 11:17:15 -0700

We just posted draft-ietf-v6ops-happy-eyeballs-04, which includes the
following changes:

   o  Better explained why IPv6 needs to be preferred
   o  Don't query A6

and some other general editing and clarification based on feedback we
received.

Side-by-side differences are at
http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-happy-eyeballs-04.txt

Comments welcome.  The authors feel this document is probably about ready
for WGLC -- there isn't much more that can be said about this topic.

-d

---

From: Fred Baker <[email-masked]>
Date: Wed, 14 Sep 2011 12:00:12 -0700

Reading through, I could imagine some edits for english prose, which I might suggest during last call, but unless the WG has comments, I think it's close. That said...

I find it a little odd to make this about IPv6 vs IPv4; the same problem happens if the system has multiple IPv4 addresses, one of which has inconsistent connectivity or routing, or if the system has multiple IPv6 addresses one of which has inconsistent connectivity or routing. You see it as an IPv6 deployment problem that conceivably goes away with IPv4; I see it as a multihoming problem that will happen to any system that has multiple viable addresses. If you want, I can suggest text changes that would reflect a multihoming perspective.

One place where this comes up in spades is in section 4.4, the comment that

      HTTP:  The design of some sites can break because of HTTP cookies
      that incorporate the client's IP address and require all
      connections be from the same IP address. 

No doubt some http sites are of that persuasion. I'll bet they change their persuasion as Microsoft's privacy addressing (which changes the address it initiates connections with daily) becomes prevalent. In an IPv4 world it might make some sense, although laptops that move from LAN to LAN frequently are an issue. In an IPv6 world with constantly-changing addresses, it is untenable. I think it might be of value to simply say that.

If I were to suggest text, it would start from the perspective that at any given time a host has a set of addresses, which might at any time include zero or more (not just zero or one) IPv4 and zero or more (not just zero or one) IPv6 addresses, and in any event changes over time for multiple reasons. Any state maintained might score prefix pairs (peer prefix and my prefix) and over time be used both in suggesting the first to try and one that might want to be retried in case something had changed.

On Sep 14, 2011, at 11:17 AM, Dan Wing wrote:

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Keith Moore <[email-masked]>
Date: Wed, 14 Sep 2011 15:07:44 -0400

On Sep 14, 2011, at 3:00 PM, Fred Baker wrote:

> I find it a little odd to make this about IPv6 vs IPv4; the same problem happens if the system has multiple IPv4 addresses, one of which has inconsistent connectivity or routing, or if the system has multiple IPv6 addresses one of which has inconsistent connectivity or routing. You see it as an IPv6 deployment problem that conceivably goes away with IPv4; I see it as a multihoming problem that will happen to any system that has multiple viable addresses.

+1.  And the problem certainly doesn't go away when IPv4 goes away; actually the v6 idea of having multiple prefixes per network segment exacerbates the problem.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Sep 2011 10:16:54 +1200

> +1.  And the problem certainly doesn't go away when IPv4 goes away; actually the v6 idea of having multiple prefixes per network segment exacerbates the problem.

I can't speak to multiple IPv4 addresses, which strikes me as an uninteresting
problem since we are within ~3 years of running out of them.

For multiple IPv6 addresses, we already have a standardised solution,
and there are learnings from that solution about the performance of
reachability testing. If I may toot my own trumpet:

http://www.cs.auckland.ac.nz/~brian/iccnt2010_reap.pdf
H. Naderi, B. Carpenter, A Performance Study on REAchability Protocol in Large Scale
IPv6 Networks, Second International Conference on Computer and Network Technology
(ICCNT 2010), Bangkok, (April 2010) 28-32.

The advantages of shim6 are that its logic is hidden below the socket interface,
and that it directly negotiates the address set in use, bypassing extra DNS calls.
This seems like a useful complement to happy-eyeballs.

   Brian

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 14 Sep 2011 18:35:57 -0700

> -----Original Message-----
> From: Fred Baker [mailto:[email-masked]]
> Sent: Wednesday, September 14, 2011 12:00 PM
> To: Dan Wing
> Cc: IPv6 Operations
> Subject: Re: [v6ops] posted draft-ietf-v6ops-happy-eyeballs-04
> 
> Reading through, I could imagine some edits for english prose, which I
> might suggest during last call, but unless the WG has comments, I think
> it's close. That said...
> 
> I find it a little odd to make this about IPv6 vs IPv4;

That is the industry's pain point at the moment.  

> the same
> problem happens if the system has multiple IPv4 addresses, one of which
> has inconsistent connectivity or routing, or if the system has multiple
> IPv6 addresses one of which has inconsistent connectivity or routing.

Happy Eyeballs is trying to solve the immediate problem, which is
a host with one IPv4 address and one IPv6 address.  Most hosts don't
have multiple (active) IPv4 interfaces today.  It's true that many of
us plug our laptops into Ethernet while our radios are on (thus, two
IPv4 addresses), but I do not believe it has been a significant 
enough problem that it warrants the IETF making suggestions to 
implementers for IPv4.

I agree that a host with multiple IPv6 addresses will occur.  But those
other addresses are also likely to have special characteristics, such 
as additional cost or bandwidth limits (e.g., 3G, satellite) which will
cause people to only use them as a very "last resort" or only after
doing something special to enable that "costly" interface.  Andrew 
gave a presentation at IETF81 in MIF about the future of 
draft-chen-mif-happy-eyeballs-extension (*) where we hope to 
bring together "policy" (to filter which interfaces a user 
wants to use) with happy eyeballs (to quickly make connection
attempts using those interfaces as the source address).

(*) http://www.ietf.org/proceedings/81/slides/mif-4.ppt

> You see it as an IPv6 deployment problem that conceivably goes away
> with IPv4; I see it as a multihoming problem that will happen to any
> system that has multiple viable addresses. If you want, I can suggest
> text changes that would reflect a multihoming perspective.
> 
> No doubt some http sites are of that persuasion.

There are not many.  I know of a specific banking site that does 
exactly that.  I know both Google Plus and Facebook do not directly
include the client IP address as authentication information, as I 
remain am often able to use them without re-authenticating 
when my IP address changes.  These sorts of things can be done
smartly, too -- if you use the same 3-4 addresses, for example;
and to accommodate IPv6 privacy addressing, the authentication could
just remember the first 64 bits of the IPv6 address.

> I'll bet they change
> their persuasion as Microsoft's privacy addressing (which changes the
> address it initiates connections with daily) becomes prevalent.

Yes, I agree some sites may not want to force the user to re-
authenticate every day -- it creates an extra burden to using the
site.

> In an
> IPv4 world it might make some sense, although laptops that move from
> LAN to LAN frequently are an issue. In an IPv6 world with constantly-
> changing addresses, it is untenable. I think it might be of value to
> simply say that.
> If I were to suggest text, it would start from the perspective that at
> any given time a host has a set of addresses, which might at any time
> include zero or more (not just zero or one) IPv4 and zero or more (not
> just zero or one) IPv6 addresses, and in any event changes over time
> for multiple reasons.

I revised the paragraph as follows.  New and modified lines start 
with "*",

   HTTP:  The design of some sites can break because of HTTP cookies
   that incorporate the client's IP address and require all connections
   be from the same IP address.  If some connections from the same
   client are arriving from different IP addresses (or worse, different
*  IP address families), such applications will break.  Such a design is
*  discouraged, because the host may legitimately change its IP address
*  because of IPv6 Privacy Addresses [RFC4941], because one interface
*  went down, traffic on an interface was slow (and became a less-
*  preferred interface), or network policy changed
*  [I-D.ietf-6man-addr-select-opt]).  Additionally for HTTP, using the
   non-winning connection can interfere with the browser's Same Origin
   Policy (see Section 5.8).

If we want to provide more guidance to developers of HTTP sites and
how they can work with IPv6, it probably needs to be in a W3C 
documents or an IETF apps-area document?

> Any state maintained might score prefix pairs
> (peer prefix and my prefix) and over time be used both in suggesting
> the first to try and one that might want to be retried in case
> something had changed.

A browser's same origin policy will already 'stick' with the previously-
working address.  Right now, that is only overridden by someone doing
a Shift-Reload (or equivalent).

-d

---

From: Fred Baker <[email-masked]>
Date: Wed, 14 Sep 2011 19:22:37 -0700

> That is the industry's pain point at the moment.  

Well, yes, but RFCs often last for a while longer than "the industry pain point of the moment"

> documents or an IETF apps-area document?

Works for me. Thanks.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Sep 2011 15:55:04 +1200

Dan,

> -- if you use the same 3-4 addresses, for example;

Um, that would "authenticate" anyone on the same subnet, for
example someone else on the same free public Wi-Fi.

Regards
   Brian Carpenter

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 14 Sep 2011 21:50:44 -0700

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Wednesday, September 14, 2011 8:55 PM
> To: Dan Wing
> Cc: 'Fred Baker'; 'IPv6 Operations'

The 64 bits would not be the sole authenticator, any more so
than the IPv4 address at Starbucks is not today's sole 
authenticator.  

-d

---

From: Fred Baker <[email-masked]>
Date: Wed, 14 Sep 2011 22:41:09 -0700

> example someone else on the same free public Wi-Fi.

I think he means the EID. That doesn't help with privacy addresses, but it helps with EUI-64.

---

From: Joel jaeggli <[email-masked]>
Date: Sat, 17 Sep 2011 13:30:13 -0700

On 9/14/11 12:07 , Keith Moore wrote:
>> I find it a little odd to make this about IPv6 vs IPv4; the same
>> problem happens if the system has multiple IPv4 addresses, one of
>> which has inconsistent connectivity or routing, or if the system has
>> multiple IPv6 addresses one of which has inconsistent connectivity or
>> routing. You see it as an IPv6 deployment problem that conceivably
>> goes away with IPv4; I see it as a multihoming problem that will
>> happen to any system that has multiple viable addresses.
> 
> +1.  And the problem certainly doesn't go away when IPv4 goes away;
> actually the v6 idea of having multiple prefixes per network segment
> exacerbates the problem.

how is multiple prefixes per segment different than multiple segments
with different prefixes?

joel

---

From: Keith Moore <[email-masked]>
Date: Sat, 17 Sep 2011 17:18:02 -0400

> how is multiple prefixes per segment different than multiple segments

If the prefixes on a segment aren't assured to be equivalent in terms of scope and routability, it isn't.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 18 Sep 2011 10:45:17 +1200

> If the prefixes on a segment aren't assured to be equivalent in terms of scope and routability, it isn't.

Indeed. As MIF has been discussing without exactly saying it, the concept
of "default router" can become meaningless in some scenarios, and there
is a complex relationship between which first-hop router the host
chooses, which egress router that first-hop router chooses, and the
existence or otherwise of ingress filtering in the transit provider
that the egress router chooses.

This is not simple and doesn't seem to be any business of application
layer software.

   Brian

---

From: Keith Moore <[email-masked]>
Date: Sat, 17 Sep 2011 18:57:45 -0400

> This is not simple and doesn't seem to be any business of application

...except that the choice of source interface, source address, and destination address are inherently influenced by application considerations.   It really matters to your application whether it gets a path that is low or high bandwidth, low or high jitter, low or high packet loss, low or high cost, whether the network connection continues to forward packets as the host moves,  whether the address-to-host bindings are stable or ephemeral, whether the addresses used have global or limited scope, global or limited reachability, are filtered by firewalls, etc.   

Traditional internet service tries to be "good enough" in most of these areas for most applications, but applications keep making more demands of the network.  But when you add wireless services, LSNs, ULIAs, etc. to the mix you end up with different tradeoffs.   Right now, the only way for many applications to work effectively in a multiple interface / multiple address environment is to try to manage interface and address selection by itself.

Keith

---

From: Fred Baker <[email-masked]>
Date: Sat, 17 Sep 2011 16:13:55 -0700

> ...except that the choice of source interface, source address, and destination address are inherently influenced by application considerations.   It really matters to your application whether it ge…

True enough. I'm drawing a blank, though. I once worked on a protocol that would enable an application to get answers to those kinds of questions. I don't know of applications that use it or any other OS API that would get them that information, and I'm not altogether sure, if someone asked me which one might help them, what API to point them to.

As near as I can tell, applications translate a name into a set of addresses, and by some algorithm pick a source address and connect to a destination address. The history of RFC 3484 and its successors tells me that absent information that hosts usually don't have - which you just specified - picking an address pair is Really Hard. At most, you can guess that if one address pair has a longer string of most significant bits that are the same than another address pair has, that might be a reasonable guess at which pair to try first. But it is just that - a guess - and counterexamples abound.

From my perspective, the Happy Eyeballs considerations don't answer all of those questions, but they do come up with a route (from the host's perspective, an address pair) that can successfully exchange datagrams in human-reasonable elapsed time. We haven't automated the job of network design, nor have we put the operator out of a job.

---

From: Keith Moore <[email-masked]>
Date: Sat, 17 Sep 2011 19:20:34 -0400

> True enough. I'm drawing a blank, though. I once worked on a protocol that would enable an application to get answers to those kinds of questions. I don't know of applications that use it or any ot…

And I once tried to design an API that would do that, and it ended up looking so complex that I couldn't convince myself that it would get much use.  (Which doesn't mean, of course, that my first stab at the problem is the best solution possible.  Actually I think that multipath TCP has a lot of promise at being more general - though not universal -, particularly if the app can somehow tell the network stack something about what kinds of paths to favor.)

> As near as I can tell, applications translate a name into a set of addresses, and by some algorithm pick a source address and connect to a destination address. The history of RFC 3484 and its succe…

yes.

> From my perspective, the Happy Eyeballs considerations don't answer all of those questions, but they do come up with a route (from the host's perspective, an address pair) that can successfully exchange datagrams in human-reasonable elapsed time.

Happy Eyeballs is just fine for the part of the problem that it purports to solve.  Last time I looked anyway, it didn't claim to be an all-encompassing solution.  It's definitely worth abstracting happy eyeballs for applications that work well with it, we just shouldn't pretend that it solves the general problem.

> We haven't automated the job of network design, nor have we put the operator out of a job.

No, but there has been pressure of various kinds to make the host and/or app take on part of the role of what traditionally was exclusively the networks' job.

Keith

---

From: Fred Baker <[email-masked]>
Date: Sat, 17 Sep 2011 16:41:16 -0700

> And I once tried to design an API that would do that, and it ended up looking so complex that I couldn't convince myself that it would get much use.  (Which doesn't mean, of course, that my first s…

Well, yes, sort of. What mptcp can do is open a single session from a set of addresses to a set of addresses. In operation, it could send data across the cross-product of those sets and discard address pairs that seem suboptimal. Note "seem"; it doesn't know the rate of the bottleneck on any given path, nor its current routing, nor much of anything else. It knows that last time it tried an address pair it liked or didn't like what it experienced. 

> Happy Eyeballs is just fine for the part of the problem that it purports to solve.  Last time I looked anyway, it didn't claim to be an all-encompassing solution.  It's definitely worth abstracting…

To my knowledge, nobody has suggested it solved a general problem. It does a better job on the problem it does try to solve than approaches that preceded it.

I would invite a better solution. If it involves a protocol, and I can't imagine it doesn't (today's routing protocols don't address the set of issues you bring up either, and I think you're describing routing in at least a general sense), I would suggest you take it to the routing ADs and ask advice on where it might fit.

---

From: Keith Moore <[email-masked]>
Date: Sat, 17 Sep 2011 20:15:35 -0400

> Well, yes, sort of. What mptcp can do is open a single session from a set of addresses to a set of addresses. In operation, it could send data across the cross-product of those sets and discard add…

One thing that I like is the ability of the mptcp approach to not only adapt to initial conditions, but also dynamically adapt to changing conditions, as viewed by the endpoints.   But if there were some sort of protocol between hosts and the network that tried to give hosts a way to compare conditions along different paths without having to actively probe those conditions, that help a lot with allowing hosts or apps to make good choices for initial conditions.

> To my knowledge, nobody has suggested it solved a general problem. It does a better job on the problem it does try to solve than approaches that preceded it.

agree.

Keith