Happy Eyeballs – Happiness Defined by Your Perspective
It seems that most people not having a vested interest in status quo agree the socket API is broken. After all, why should every single application ever written have to deal with the idiosyncrasies of two address families?
Not surprisingly, the browser vendors got sick and tired of waiting for a fixed API or a standardized session layer (nothing happened in the last two decades) and decided to implement happy eyeballs – a simple mechanism that creates two TCP sessions (one over IPv4, another one over IPv6) and uses whichever one works better.
What’s wrong with Happy Eyeballs?
Happy Eyeballs seems to be a highly successful kludge – after all, it ensures web browsing works no matter what. Unfortunately, the implementation details vary by browser and even by operating system, ranging from what Geoff Huston calls “Moderately Happy Eyeballs” to “Bemused Eyeballs.” For more details, read the May 2012 issue of The ISP Column and watch Geoff describe Happy(er) Eyeballs @ RIPE64 (PDF).
Happy Eyeballs also make browser behavior non-deterministic: you never know which protocol the browser uses to access the server. I’m positive we’ll face interesting Heisenbergian challenges in the near future as our users start experiencing intermittent irreproducible problems caused by partially failed end-to-end connectivity or web servers (the fact duly acknowledged by RFC 6555). For more fun, add NAT444 caused by (user) CPE NAT44 + (provider) CGN NAT44 to the mix.
NAT44 = Network Address Translation from IPv4 to IPv4 (the NAT and PAT duct tape we’ve been using for the last 20 years).
CGN = Carrier Grade NAT – large-scale NAT performed inside a Service Provider network.
NAT444 = Double NAT44 – what you get when combining NAT44 done by almost every SOHO router with CGN used by the Service Provider to survive the IPocalypse (every ISP can get a single /22 in RIPEland).
To make troubleshooting even more exciting, Happy Eyeballs implementations don’t add information to TCP SYN packets (which is understandable – SYN packets with extra headers would be dropped by many firewalls), making it totally impossible to correlate IPv4 and IPv6 sessions from the same client on the web server side.
Next: Happy Eyeballs algorithm works just above the transport layer; it detects broken IPv6 connectivity (the situation where the SYN+ACK packet doesn’t get back from the server), but cannot cope with bizarre black holes caused by failed path MTU discovery (caused, for example, by IPv6-over-IPv4 tunnels combined with misconfigured firewalls).
Finally (and this is my biggest conceptual grudge), Happy Eyeballs is yet another application layer approach to a session layer problem. Every application that has to survive in unreliable dual-stack environment has to reinvent the same wheel; expediency has yet again trumped over architectural principles.
Squid with 6+4 outside and v4 inside is a common way to bridge from the enterprise LAN to the v6 world. However the experience is a still bit pot-luck, at present.