Resumen

  • Una respuesta A o AAAA aporta una dirección candidata, pero no demuestra que el trayecto y el servicio funcionen para ese cliente en ese momento.
  • RFC 6555 convirtió la preferencia por IPv6 en una ventaja inicial limitada; RFC 8305 añadió resolución asíncrona, orden RFC 6724, alternancia de familias e intentos que se solapan sin arrancar todos a la vez.
  • Gana la primera conexión establecida, no el protocolo más verdadero. El recurso evita dolor al usuario y, al mismo tiempo, puede ocultar una avería persistente al operador.

La transición podía parecer peor que el pasado

En 1994, RFC 1671 ya planteaba la pregunta incómoda de la doble pila. DNS podía devolver dos clases de dirección sin saber que un router intermedio descartaba IPv6, que un túnel estaba roto o que el servicio anunciado por AAAA no respondía. La publicación era válida; la inferencia de conectividad no lo era.

El cliente tradicional recorría una lista en serie. Si IPv6 ocupaba el primer lugar, esperaba retransmisiones antes de probar IPv4. El usuario con doble pila sufría una pausa que el usuario con sólo IPv4 no veía. Desactivar IPv6 resolvía el síntoma, de modo que la propia mala experiencia de transición alimentaba la decisión de abandonar la transición.

Separar los nombres —uno para IPv4 y otro para IPv6— habría roto la unidad del identificador que las personas compartían. Mantener listas blancas no podía seguir cada interrupción intermitente ni cada ruta de acceso. Hacía falta medir en el borde, al comenzar la conexión.

IPv6 salía primero, no salía solo

RFC 6555 dio forma normativa a Happy Eyeballs en 2012. La idea no consistía en lanzar dos conexiones idénticas y elegir siempre la más rápida. La política del sistema seguía ordenando las direcciones y normalmente favorecía IPv6. La diferencia era que, si el primer intento no avanzaba pronto, el cliente abría otro por la familia alternativa.

La preferencia pasó a ser una salida adelantada, no un veto. El primer candidato conserva una oportunidad real de ganar; el segundo impide que un agujero negro transforme esa oportunidad en segundos de inmovilidad.

El solapamiento consume recursos. Cada intento adicional puede crear estado en servidores, cortafuegos, traductores y equipos de inspección. Por eso la especificación exige prudencia: espaciar, cancelar al perdedor y no sostener una duplicación mecánica. También protege la transición económica. Si se eligiera sin ninguna ventaja la familia apenas más rápida, se mantendría carga innecesaria sobre IPv4 compartido y sobre sus traductores.

La memoria de fallos tiene fecha de caducidad. RFC 6555 permite recordar qué familia funcionó, pero obliga a volver a probar periódicamente la preferida y recomienda un orden de unos diez minutos. Al cambiar de red, el aprendizaje debe reiniciarse. Una ruta rota pertenece a un contexto de conexión, no a la esencia de IPv6.

La segunda versión ordenó el experimento completo

RFC 8305 sustituyó la descripción original en 2017. La nueva versión divide el proceso en cuatro momentos: iniciar consultas DNS asíncronas, ordenar destinos, iniciar conexiones asíncronas y conservar una sola conexión.

AAAA y A se consultan casi al mismo tiempo, con AAAA primero. Si A responde antes, el cliente espera de forma recomendada 50 milisegundos por AAAA. Esa pequeña demora mantiene la inclinación hacia IPv6 sin exigir que una respuesta DNS tardía bloquee una dirección IPv4 ya disponible.

Los candidatos conocidos se ordenan con RFC 6724, que relaciona destino, fuente disponible, alcance, etiquetas y política local. Después se intercalan las familias: cuando IPv6 está primero, el mejor IPv4 suele pasar al segundo lugar. Así se evita agotar una larga lista de direcciones de una familia averiada antes de probar la otra.

Los intentos no salen simultáneamente. El siguiente comienza después de una demora mientras el anterior sigue vivo. RFC 8305 recomienda 250 milisegundos por defecto, fija una prohibición por debajo de 10 milisegundos, recomienda un mínimo de 100 y un máximo de dos segundos. Son valores configurables derivados de observación, y el propio texto espera que cambien con las redes.

Un cliente puede usar tiempos de ida y vuelta históricos o preferir direcciones usadas anteriormente. Esa memoria no debe cruzar interfaces y debe borrarse al cambiar de red. Cuando una conexión completa su establecimiento, los demás intentos se cancelan. La selección termina sin convertir el resultado en una regla universal para el siguiente entorno.

El primer apretón no demuestra el resto

Happy Eyeballs observa el establecimiento inicial. No asegura que TLS valide, que HTTP sea coherente entre servidores o que el trayecto admita paquetes grandes. RFC 8305 advierte que un problema de MTU posterior al apretón puede quedar fuera de su vista.

Tampoco autentica una dirección. Los resultados DNS pueden cambiar y dos conexiones al mismo nombre pueden usar destinos diferentes. La identidad requiere pruebas de la capa que conoce al servicio.

La paradoja final es operativa. Un IPv6 averiado de forma constante puede quedar detrás de un IPv4 que gana enseguida. El lector ve una página rápida; el administrador pierde la queja que habría revelado el daño. La norma recomienda supervisión externa de cada familia porque la recuperación del cliente no repara la red.

Fuentes y límites

El conjunto cerrado comprende RFC 1671, RFC 6555, RFC 6724 y RFC 8305. Establece el diseño y sus límites; no aporta cuotas actuales de implantación, una demora universalmente óptima ni una clasificación mundial de IPv4 frente a IPv6.