Summary

  • En los ensayos presentados por Patrick Sattler en RIPE 92, las versiones probadas de Chrome y Firefox esperaban tanto la respuesta A como la AAAA. Si A tardaba, la página podía tardar pese a disponer de IPv6; Firefox falló en algunos casos.
  • Safari fue el único navegador de ese grupo que aplicó el comportamiento completo de Happy Eyeballs v2, incluido un plazo de resolución DNS. El tiempo de espera del resolutor podía convertirse en tiempo de espera del usuario en los otros clientes medidos.

El sitio no necesitaba arreglar IPv6. El navegador ya había recibido una dirección AAAA utilizable. Lo que faltaba era la respuesta del otro carril, IPv4. Patrick Sattler presentó en RIPE 92 un experimento que convirtió esa espera aparentemente secundaria en el problema principal.

Happy Eyeballs concede una pequeña ventaja a IPv6 y deja competir a IPv4 si la conexión falla o tarda. Sattler miró la cola anterior a las conexiones: las consultas DNS. Su equipo controló los retrasos de un servidor de nombres y de un servicio web, midiendo la decisión del navegador desde fuera. La página oficial de la charla registra la comparación de implementaciones.

En los navegadores y configuraciones probados en mayo de 2026, Chrome y Firefox consultaron A y AAAA y esperaron ambas respuestas. No aplicaron el plazo de resolución de la versión 2. Una respuesta A demorada retenía la carga aunque AAAA ya había llegado; Firefox terminó con error en algunos casos. Safari avanzó por IPv6 cuando AAAA llegó enseguida y A no. Si se retrasaba AAAA, el ejemplo mostrado le concedía unos 50 milisegundos antes de usar IPv4.

Las conexiones propiamente dichas tenían otro reloj. Chrome pasó de IPv6 a IPv4 alrededor de los 300 milisegundos en la prueba, Firefox alrededor de los 250. Safari ajustó el retraso dinámicamente. Sattler advirtió que sistema operativo, proxies y red pueden cambiar el comportamiento; su medidor público estaba entonces alojado sólo en Múnich. La muestra describe ese ensayo, no todas las versiones futuras.

Esto reparte la responsabilidad de una página lenta de forma incómoda. El sitio ofrece IPv6 que funciona. El navegador decide si espera los dos nombres. El resolutor decide cuánto dura la ausencia de A antes de rendirse. Sattler sugirió revisar los tiempos de espera de DNS; el fabricante del navegador puede permitir que una AAAA válida arranque sin esperar interminablemente a su compañera.

Un informe útil de la incidencia necesita las dos marcas temporales DNS, versión del cliente, resolutor y primera dirección que se intentó conectar. Un ping IPv6 correcto no explica la pestaña inmóvil. Sattler llevó el cronómetro hasta el punto donde una respuesta sobrante adquiere poder de veto.

Fuentes: transcripción original de RIPE 92 · página oficial de la ponencia · perfil RACI.