I spent last week in Phoenix, Arizona. My eyeballs are very happy – one week of blue skies and a lot of good network labs in my SIP training class. In the beginning of the week I had a discussion about Happy Eyeballs – the way modern web browsers running in dual stack connects to the web server without bad affects on the user experience. The person I discussed with thought the problem was solved – he had not realized that this affects all application protocols – from SIP to Email, chat and p2p applications. Let’s discuss Happy Eyeballs and how to test it!
Happy Eyeballs – a quick introduction
When both a client and a server runs dual IP stacks, both IPv4 and IPv6, the client needs to find the best possible – and working – connection between the two computers. In the early days of IPv6, client computers set up automatically configured tunnels of various types, that usually was blocked in the firewall. The client believed it had a working IPv6 Internet connection and, following the standards, tried with IPv6 first. After failure, some clients failed and some retried with IPv4. The big problem was that the failure took time – between 15 and 30 seconds, depending on the protocol used. The user actually had a working connection path – over IPv4 – but running dual stacks caused delays and broken connection attempts. In total, not a good solution.
The Happy Eyeballs RFC from IETF suggests a change in procedure. The client now sets up connections over all possible network paths at the same time. The connection that succeeds first is the one used. No priority over any specific type of IP protocol, just get connected and make the user happy.
Making all protocols happier – testing, testing, testing
While this is was initially applied to HTTP, it affects all applications. A priority is applications where the user is waiting for a response, for some actions on the screen or in the headset – like SIP call setups, Email delivery to a mail server and of course game interaction. We’re going to take a look at wget and curl in this example, to show you the problem and how you can set up a test.
Start with setting up records in DNS
A requirement for testing happy eyeballs are that both client and server are dual stack. You need to set up one DNS name with two addresses, one for each family. In my example I’ve set up two DNS names – badipv6.test.ipv6friday.org and badipv4.test.ipv6friday.org
badipv6.test IN AAAA 2001:DB8::2042:3042
badipv6.test IN A 212.3.14.213
badipv4.test IN AAAA 2a02:920:212e::213
badipv4.test IN A 192.168.42.42
So what’s the trick with these? Well, the IPv6 address for the badipv6 entry is a documentation address, not routable anywhere. It simply does not work. The IPv4 address is the address for this site. For badipv4, the IPv6 address is the address for this site. The IPv4 address however, is an RFC1918 private IPv4 address, again an address that is not routable on the Internet. A perfect setup for Happy Eyeballs!
Testing with wget
You can surely test this with any browser. If they are old enough, you will encounter a problem trying to access badipv6. The rule used to be that dual stack clients should try IPv6 first. In this case, it’s not going to work. An HTTP client that has no support for Happy Eyeballs will fail. Let’s test with wget, a popular Linux/Unix command line tool to fetch files with HTTP.
# wget badipv6.test.ipv6friday.org --2012-11-15 18:06:53-- http://badipv6.test.ipv6friday.org/ Resolving badipv6.test.ipv6friday.org... 2001:db8::2042:3042, 212.3.14.213 Connecting to badipv6.test.ipv6friday.org|2001:db8::2042:3042|:80... failed: Operation timed out. Connecting to badipv6.test.ipv6friday.org|212.3.14.213|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 226 [text/html] Saving to: `index.html.1'
wget clearly has a happy eyeballs problem. You do not see the time it took for it to time out on the IPv6 address before it failed over to IPv4. Running wget to badipv4 was no fun, since wget starts with IPv6 and succeeds directly.
So let’s try another similar tool, curl v 7.24 by Daniel Stenberg, one of my friends. I’ve talked with Daniel many times about Happy Eyeballs, but curl still has the issue. It tries IPv6 and waits forever, then times out and fails over to IPv4. (I guess that it may have something todo with me not being able to attend the Stockholm FOSS beer meetings…)
curl -v http://badipv6.test.ipv6friday.org * About to connect() to badipv6.test.ipv6friday.org port 80 (#0) * Trying 2001:db8::2042:3042... * Operation timed out * Trying 212.3.14.213... * connected * Connected to badipv6.test.ipv6friday.org (212.3.14.213) port 80 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.24.0 (amd64-portbld-freebsd8.2) libcurl/7.24.0 OpenSSL/0.9.8q zlib/1.2.3 > Host: badipv6.test.ipv6friday.org > Accept: */* > < HTTP/1.1 200 OK ...
The good thing coming out of this test is that while both clients show the issue, both of them actually fail over to IPv4. Curl is also a library, used in many applications. One of them is the Asterisk Open Source PBX . In Asterisk CURL is frequently used in dialplan processing. A timeout on over ten seconds is not acceptable while setting up a call. If you use Curl in your application, you need to buy Daniel a beer or two so that we all get this fixed. Or fund his work so he can assign time to work on making your eyeballs more happy.
Test your own applications
Testing HTTP is low hanging fruit. The same problem applies to all TCP based protocols (and possibly UDP too). With a DNS setup like the one I used for the tests documented here you can run your own tests. I’ve done it with SIP clients and the results are not pretty. The TCP/IP community needs you, so do not forget to report back and tell others about your findings. Your favorite SSH client is affected, your FTP client as well as your e-mail software. We have a lot of work todo. The web browsers have worked with this issue for a long time, and have shared their implementation experience. I am working in the SIP Forum IPv6 working group trying to find out how we can proceed in fixing this – where are you going to start?
Have a great IPv6 week!
/Olle