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

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: Fred Baker [mailto:[e-mail]]
> 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.
> 
> 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.

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


> On Sep 14, 2011, at 11:17 AM, Dan Wing wrote:
> 
> > 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
> >
> >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops