Resumen

  • Happy Eyeballs reduce la demora visible solapando candidatos; el ganador solo demuestra su propia conectividad.
  • Deben conservarse por familia los tiempos DNS, el orden, el inicio, el error y la cancelación.
  • El éxito de la aplicación y el buen funcionamiento de IPv4 e IPv6 son conclusiones operativas distintas.

Pensemos en un caso ilustrativo: la página carga con normalidad tras llegar respuestas AAAA y A; IPv6 arranca primero, IPv4 lo sigue y termina antes. El usuario no ve una caída, y un panel basado solo en sesiones completadas tampoco. Sin embargo, IPv6 pudo sufrir un problema de trayecto o de servicio, o quedar cancelado antes de responder. La conexión ganadora no distingue esos casos.

El RFC 8305 especifica el comportamiento de carrera del que puede surgir esta ambigüedad: consulta A y AAAA casi a la vez, ordena destinos mediante el RFC 6724, intercala familias y escalona los intentos. Cuando uno funciona, cancela los demás. Según el análisis editorial de este artículo, el mecanismo puede proteger la disponibilidad porque una opción defectuosa no impone al usuario todo su tiempo de espera.

Pero «cancelado» después de una victoria IPv4 no equivale a éxito IPv6 ni necesariamente a fallo IPv6. Es evidencia truncada. Tampoco una victoria IPv4 demuestra preferencia por IPv4: influyen la llegada de DNS, el orden RFC 6724 y los tiempos históricos.

Los 250 milisegundos citados con frecuencia son una recomendación de valor predeterminado para el intervalo entre intentos, no un objetivo universal. El estándar permite adaptación, fija límites de seguridad y separa ese intervalo de la espera de resolución cuando A llega antes que AAAA. Un recibo útil conserva valores y marcas de tiempo reales, no solo «Happy Eyeballs activado».

El propio RFC 8305 advierte que el mecanismo puede ocultar problemas operativos. La respuesta no es desactivar la carrera, sino medir los caminos perdedores sin hacer esperar al usuario. Por episodio deben guardarse contexto de red, ruta del resolvedor, llegada de A/AAAA, candidatos ordenados, familia, Resolution Delay configurado, Connection Attempt Delay configurado o adaptado, desfase real de inicio, hito del protocolo, resultado de cada intento, resultado de la aplicación, motivo de cancelación, ganador y el ámbito de red y vigencia de cualquier historial de conexión en caché.

Como recomendación operativa editorial, conviene agregar esos datos durante un periodo limitado para reducir la exposición de privacidad.

El RFC 6555 nació para reducir la demora causada por IPv6 averiado. RFC 8305 refina el remedio; ninguno certifica la familia perdedora. RFC 6724 define política de selección, no una prueba de alcanzabilidad.