RFC6555 Happy Eyeballs and RFC8305 Happy Eyeballs 2

RFC6555 Happy Eyeballs: Success with Dual-Stack Hosts

https://datatracker.ietf.org/doc/html/rfc6555

RFC3484 gives IPv6 addresses higher precedence than IPv4 addresses. Because of this when IPv6 connectivity is impaired, IPv6-capable applications incur many seconds of delay before falling back to IPv4.

Happy Eyeballs aims to provide a fast connection for users, by quickly attempting to connect using IPv6 and (if that connection attempt is not quickly successful) to connect using IPv4.

from RFC6555

RFC8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency

https://datatracker.ietf.org/doc/html/rfc8305

Happy Eyeballs 2 adds the following features on top of RFC6555

Asynchronous DNS queries.

The diagram below shows how the DNS queries are handled asynchronously. Implementations SHOULD NOT wait for both families of answers to return before attempting connection establishment. If one query fails to return or takes significantly longer to return, waiting for the second address family can significantly delay the connection establishment of the first one.

This is a workaround for faulty resolvers that take a long time to return results after AAAA queries are made.

Sorting of resolved destination addresses

Whichever address family is first in the list should be followed by an address of the other address family; that is, if the first address in the sorted list is IPv6, then the first IPv4 address should be moved up in the list to be second in the list.

 

Asynchronous connection attempts

After "Connection Attempt Delay" has passed after starting a connection attempt for an address, start a new connection attempt to the next address. This shouldn’t affect previous attempts, as multiple connection attempts may occur in parallel.