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; 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:

> 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
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops