[v6ops] Re: Dispatching Happy Eyeballs Version 3

[Jeremy Duncan <[e-mail]>]

1000% agree here.

HE is masking IPv6 network problems we need to add some sort of notification/alerting somewhere.

-Jeremy


From: [e-mail] <jordi.palet=[e-mail]>
Sent: Saturday, July 13, 2024 1:01 PM
To: Tommy Pauly <tpauly=[e-mail]>
Cc: [e-mail]; V6 Ops List <[e-mail]>; [e-mail]
Subject: [v6ops] Re: Dispatching Happy Eyeballs Version 3

CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you validate the sender and know the content is safe. Please forward this email to [e-mail]<mailto:[e-mail]> if you believe this email is suspicious.
I think it is a must that the proposed charter also includes the reporting mechanism or APIs that allow reporting, so ISPs, or relevant parties can be aware of the automatic switching.

I understand that there is some text about that, but is not clear how this could be turned into a real “compete” solution.

HEv3 can’t continue hiding the switching and not have an embedded way to report it. In many IPv6 deployments this brings to artificial failed deployments, which is a real problem, instead of a solution. Time for definitively fix it.

Regards,
Jordi

@jordipalet


El 13 jul 2024, a las 0:21, Tommy Pauly <tpauly=[e-mail]<mailto:tpauly=[e-mail]>> escribió:

At IETF 118 and 119, we shared our work on updating the Happy Eyeballs RFCs with draft-pauly-v6ops-happy-eyeballs-v3 [1]. Specifically at IETF 119, we presented at the ALLDISPATCH session, and got the feedback to consider a new short-lived working group [2].

The authors have worked on a proposed charter for the HAPPY WG (Heuristics and Algorithms to Prioritize Protocol deploYment), and we’ve scheduled some side meeting time at IETF 120 to discuss and get feedback.

https://wiki.ietf.org/en/meeting/120/sidemeetings
When: 16:30-17:30 Pacific Time
Where: Prince of Wales / Oxford

The initial text we’d be proposing for a charter can be found here:
https://github.com/tfpauly/draft-happy-eyeballs-v3/blob/main/charter.md

Feel free to also reply to this email, or file issues [3]!

Best,
Tommy, David, Nidhi, & Kenichi

[1] https://www.ietf.org/archive/id/draft-pauly-v6ops-happy-eyeballs-v3-01.html
[2] https://datatracker.ietf.org/meeting/119/materials/minutes-119-alldispatch-202403172230-00
[3] https://github.com/tfpauly/draft-happy-eyeballs-v3/issues?q=is%3Aissue+is%3Aopen+label%3Acharter


On Jan 23, 2024, at 3:51 PM, Tommy Pauly <[e-mail]<mailto:[e-mail]>> wrote:

Hi ALLDISPATCH,

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.

The draft is "Happy Eyeballs Version 3", which is an update to RFC 8305, which was Version 2. For those not familiar with Happy Eyeballs, it’s the name for the algorithm network clients use to create multiple connection attempts in parallel, with a small delay between attempts, for servers that are reachable on multiple IP addresses. This technique allows clients to have preferences for specific protocols or features, such as IPv6, while still making a user’s “eyeballs” happy in cases where there may be misconfigurations on networks or servers that cause the preferred protocols to fail or be slow. This work was originally developed in v6ops, and was primarily focused on handling the selection of IPv6 vs IPv4 options.

In the years since RFC 8305 was published, there have been numerous changes to the protocol ecosystem that required a refresh on the document. Some of the changes include:
- 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

While the algorithm overall still focuses on selection of IP addresses and preferred address families, some of the new considerations (around transport protocol selection, ALPN selection, and preferences due to TLS encrypted client hello) cause the scope to potentially grow beyond the core expertise of V6OPS. Hence, we’d like to figure out where this work should go.

The draft can be found here:
https://datatracker.ietf.org/doc/draft-pauly-v6ops-happy-eyeballs-v3/
https://www.ietf.org/archive/id/draft-pauly-v6ops-happy-eyeballs-v3-00.html

Slides from IETF 118 can be found here:
https://datatracker.ietf.org/meeting/118/materials/slides-118-v6ops-happy-eyeballs-v3-00

Thanks,
Tommy (& co-authors)

_______________________________________________
v6ops mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.