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

[Fred Baker <[e-mail]>]

On Sep 14, 2011, at 6:35 PM, Dan Wing wrote:

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

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

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

Works for me. Thanks.