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

[Michael Richardson <[e-mail]>]

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

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.


--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide