The IETF has developed solutions that promote a healthy IPv4 and IPv6 co-existence. The happy eyeballs algorithm for instance, provides recommendations to application developers to help prevent bad user experience in situations where IPv6 connectivity is broken. We study the effectiveness of the happy eyeballs algorithm.
getaddrinfo(...) resolves a service name to a list of endpoints in an order that prioritises an IPv6-upgrade path  . The order can dramatically reduce the application’s responsiveness when IPv6 connectivity is broken. The degraded user experience can be subverted by implementing the happy eyeballs algorithm  . The algorithm recommends that a host, after resolving the service name, tries a TCP
connect(...) to the first endpoint. However, instead of waiting for a timeout, it waits for 300ms, after which it must initiate another TCP
connect(...) to an endpoint with a different address family and start a competition to pick the one that completes first.
We have defined a metric that uses the TCP connection establishment times as a parameter to measure the algorithm’ effectiveness. The methodology also helps examine the impact of tunnelling mechanisms employed by early adopters. The input parameter of the metric is a (IP address, port number) tuple and the output is the connection establishment time, typically measured in microseconds.
We have developed
happy , a simple TCP happy eyeballs probing tool that conforms to the definition of our metric. It uses non-blocking
connect(...) calls to concurrently establish connections to all endpoints of a service and measures the elapsed time. The tool enforces a small delay between concurrent
connect(...) calls to avoid bursty TCP SYN traffic. The initially performed service name resolution is not accounted in the connection establishment elapsed time.
We use the Alexa top 1M list as input to prepare a top 100 dual-stacked service names list. We run
happy on our internal test-bed of multiple measurement agents with different flavours of connectivity ranging from native IPv4, native IPv6, IPv6 tunnel broker endpoints, Teredo and tunnelled IPv4.
Data Analysis Insight
The initial results show higher connection times and variations over IPv6 as shown in Figure 1 below (you can click on the image to enlarge it). It appears that an application never uses IPv6 using Teredo except when IPv4 connectivity is broken. We noticed, that a 300ms advantage leaves a dual-stacked host only 1% chance to prefer a IPv4 route even though it may be significantly faster than IPv6. We also measured the margin by which happy eyeballs is inhibiting the fastest available route by comparing the slowness of a happy eyeballed winner to that of the loser.
Fig 1. Mean time and its standard deviations to establish TCP connections to a list of web services. The measurement agent is a server located at the University of Braunschweig. It has native IPv4 and IPv6 connectivity via the German Research Network [AS13237]
We have performed a preliminary study on evaluating the effectiveness of happy eyeballs. We noticed several cases where the algorithm does not select the best route and instead hampers the user experience. We want to run this test on a large-scale measurement platform to develop a more comprehensive picture to help improve the algorithm.
This work was presented within the IPv6 working group at the RIPE 66 meeting. The presentation video and slides are available at: https://ripe66.ripe.net/archives/video/1208 .
The original manuscript in the PDF form is available at: http://vaibhavbajpai.com/documents/papers/manuscripts/happy-ripe66.pdf
 D. Thaler, R. Draves, A. Matsumoto, and T. Chown, “Default Address Selection for Internet Protocol Version 6 (IPv6),” RFC 6724 (Proposed Standard), Internet Engineering Task Force, Sep. 2012. [Online]. Available: http://www.ietf.org/rfc/rfc6724.txt
 D. Wing and A. Yourtchenko, “Happy Eyeballs: Success with Dual- Stack Hosts,” RFC 6555 (Proposed Standard), Internet Engineering Task Force, Apr. 2012. [Online]. Available: http://www.ietf.org/rfc/rfc6555.txt