Re: [v6ops] [Alldispatch] Dispatching Happy Eyeballs Version 3

[Tim Chown <[e-mail]>]

Hi,

> On 26 Jan 2024, at 17:01, Michael Richardson <[e-mail]> wrote:
> 
> Tommy Pauly <tpauly=[e-mail]> wrote:
>> We’d like to propose a draft to be dispatched at IETF 119. This draft
>> was discussed in a couple different working groups (V6OPS and TSVWG) at
>> IETF 118. One of the main points of discussion within those groups was
>> the question of which working group would be most appropriate to take
>> on the draft.
> 
> To me, the rework is either a set of trivial rejigging of some parameters, or
> it's really entirely new work that would actually benefit from a new WG.
> 
>> This work was originally developed in v6ops, and was primarily focused
>> on handling the selection of IPv6 vs IPv4 options.
> 
> Yes.  But, it seems to me that we now really have to do make selections among
> IPv6 ULA, GUA, multiple GUA from multiple routers,  X {TCP, QUIC}.

Indeed, and there is also an ongoing 6man WG draft on updating IPv6 address selection, with a focus on ULAs, but happy eyeballs is related to address selection, as are the topics mentioned below.  HE certainly matters when address selection doesn’t give an optimal result.  An open question is what should be explicitly stated in either update about commonalities, if anything?

> To me, this work is probably wasted unless we are defining new APIs.
> My understanding is that Apple has some such APIs.  I think that there is a
> tuscle that a WG needs to deal with between connect to "name" and connect to
> "address", and also connection caching vs HE-results caching vs multiple
> users/applications.  {Android applications are basically different users.  I
> don't know how IOS does this.  It would be good to spread this notion to all platforms}
> 
>> - SVCB/HTTPS records (RFC 9460), which provide additional ways to get
>> address hints, add priority between A/AAAA answers, indicate supported
>> ALPNs, and indicate support for TLS encrypted client hello
> 
>> - Growing support for QUIC (RFC 9000); previously, Happy Eyeballs was
>> defined in terms of TCP connections, and needs to have some text
>> adaptation
>> - New techniques for supporting v6-only networks and address synthesis
> 
> I am not really associated with any OS distribution, so whether or not I
> think this work should proceed may be irrelevant.  What I think we need for
> success is:
> * some core Microsoft "libc" people
> * some GNU glibc people
> * some Ubuntu/Fedora/Azure-server/Oracle-Linux people
> * some Android people
> * some Apply people (more than just Tommy)
> 
> Yes, this is API work, which some think we don't do, but this is squarly in
> the space of updating our own RFCs, and yes, fixing the "BSD socket API" for
> this century.

That would be a bold project!

Tim

> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops