Resumen

  • RFC 6555 introdujo en 2012 una carrera breve entre familias de direcciones; RFC 8305 la sustituyó en 2017 por una secuencia completa de resolución, ordenación, intentos escalonados y cancelación.
  • El retardo predeterminado recomendado de 250 ms reparte el coste entre la espera del usuario y la carga de conexiones especulativas.
  • El mecanismo mejora la disponibilidad percibida, pero puede ocultar averías de IPv6 o IPv4, conservar dependencias de IPv4 y no resuelve fallos de la capa de aplicación.

Happy Eyeballs nació porque una preferencia correcta podía producir una experiencia incorrecta. Un host de doble pila recibía destinos IPv6 e IPv4, elegía IPv6 y quedaba esperando si ese camino estaba roto. El usuario observaba el retraso, aunque la misma aplicación habría funcionado por la otra familia. RFC 6555, publicado como Proposed Standard en abril de 2012, trasladó esa espera desde la persona hacia una decisión automática del cliente.

El ejemplo era deliberadamente pequeño. Se respetaba el orden de preferencia del host, se iniciaba la primera conexión y, después de un intervalo breve, se lanzaba la primera dirección de la otra familia. Firefox y Chrome utilizaban 300 ms. La primera conexión establecida ganaba; la restante se descartaba. Cuando no había historial, IPv6 seguía teniendo preferencia. La especificación también advertía contra generar carga IPv4 sin necesidad durante una transición prolongada.

El temporizador asignaba recursos. Si era demasiado largo, el fallo preferido seguía imponiendo una penalización visible. Si era demasiado corto, conexiones que habrían funcionado por sí solas provocaban carreras repetidas, con más paquetes, estados y trabajo en los servidores. La velocidad no era gratuita: el cliente compraba una reducción de latencia con capacidad redundante.

La experiencia posterior mostró que la realidad no era una pareja de direcciones inmóviles. RFC 8305, Proposed Standard de diciembre de 2017, dejó obsoleto RFC 6555 y definió cuatro fases. Primero se realizan consultas DNS asíncronas. Después se ordenan todos los destinos resueltos. A continuación se lanzan intentos asíncronos de forma escalonada. Por último se conserva una conexión exitosa y se cancelan las demás.

El orden temporal del DNS forma parte de la política. RFC 8305 recomienda enviar AAAA primero y A inmediatamente después, sin bloquear una consulta detrás de la otra. Si la respuesta A llega antes, un Resolution Delay recomendado de 50 ms permite que AAAA llegue y compita. Las respuestas que aparecen mientras la conexión está en curso pueden incorporarse, de modo que la primera contestación no congela necesariamente el conjunto de candidatos.

La lista se ordena con las reglas de selección de direcciones de destino. El cliente puede emplear el RTT histórico o la evidencia de uso previo dentro de la misma red. También intercala familias. Así evita que una sucesión de direcciones inútiles de una sola familia consuma toda la oportunidad antes de probar una alternativa viable. El contexto importa: el resultado observado en una red no debe convertirse sin más en verdad universal para otra.

El Connection Attempt Delay recomendado por defecto es de 250 ms. RFC 8305 recomienda un mínimo de 100 ms, prohíbe bajar de 10 ms y recomienda un máximo de dos segundos. El First Address Family Count recomendado es uno. Son valores empíricos, no constantes eternas. La especificación permite ajustarlos porque cambian las redes, los dispositivos y el precio relativo de la latencia y la carga.

Este diseño se ocupa de varias direcciones, respuestas DNS que cambian durante el proceso, información histórica y redes solo IPv6 que emplean NAT64/DNS64. Sin embargo, su alcance termina en el establecimiento inicial de TCP/IP. Una conexión ganadora puede conducir a una aplicación averiada. El algoritmo tampoco repara la ruta que perdió; simplemente evita que el usuario dependa de ella.

Esa separación crea un problema de observabilidad. RFC 6555 ya admitía que la carrera podía dificultar el diagnóstico por familia. RFC 8305 señala que fallos operativos, incluidos problemas asociados al MTU del camino, pueden quedar ocultos. Para el usuario, el servicio llegó. Para el operador, quizá desapareció la queja que habría obligado a investigar.

La virtud de Happy Eyeballs es que hace soportable una transición heterogénea. Su riesgo es convertir el replegado en institución. Mientras IPv4 gane con rapidez, habrá menos presión inmediata para reparar IPv6 y más razones para mantener direcciones IPv4 escasas. El algoritmo no decide cuándo termina esa dependencia. Solo administra, en cada conexión, el conflicto entre preferencia, tiempo y capacidad.