Resumen

  • Happy Eyeballs protege al usuario intentando alternativas sin esperar demasiado a una familia lenta o averiada. Ese diseño puede mantener verde el éxito agregado mientras IPv6 falla.
  • La prueba debe separarse por familia: respuestas DNS, candidatos, intentos reales, familia ganadora, errores perdedores y controles forzados en cohortes de acceso representativas.

Imaginemos un caso expresamente hipotético. El monitor principal está verde, las compras terminan y soporte no recibe avisos. Una segunda sonda, obligada a usar IPv6 desde una red de acceso concreta, no conecta. Ambas observaciones pueden ser ciertas. El cliente normal recibió A y AAAA, inició IPv6 y después estableció IPv4 con suficiente rapidez para que el usuario apenas notara demora.

No es una afirmación sobre una avería de un operador identificado. Es un límite de medición. El éxito de una transacción demuestra que funcionó al menos un camino; no demuestra que todas las familias anunciadas estuvieran sanas.

RFC 8305 define Happy Eyeballs v2 para reducir la espera visible cuando direcciones o familias completas están bloqueadas, rotas o rinden mal. El cliente consulta A y AAAA de forma asíncrona, ordena destinos, escalona intentos y conserva la conexión que termina primero. Después cancela las demás. Suele preferir IPv6, pero la continuidad inmediata es el objetivo.

Los tiempos recomendados muestran por qué el defecto puede quedar oculto. RFC 8305 propone 50 ms para la espera de resolución y 250 ms entre intentos sin historial de RTT. Las implementaciones pueden adaptar esos valores y usar experiencia previa. No son una garantía universal. Lo constante es la carrera: sin telemetría del intento que pierde, la conexión ganadora revela poco sobre lo ocurrido.

RFC 6724 añade selección de direcciones de origen y destino entre IPv6 e IPv4 y permite que la política administrativa cambie el orden. Dos equipos que consultan el mismo nombre pueden formar listas distintas por alcance, origen disponible, configuración o conocimiento de conectividad.

Un contador HTTP agregado aplasta todas esas decisiones en un bit. No indica si llegó AAAA, qué dirección IPv6 se probó, cuánto esperó ni si el problema estaba en DNS, descubrimiento de vecinos, rutas, filtros, MTU de camino o el servicio. Tampoco distingue una preferencia intencionada por IPv4 de un rescate.

El registro mínimo conserva respuestas A/AAAA y sus tiempos, candidatos ordenados, familia de origen y destino, inicio y fin de cada intento, error o expiración perdedora, familia ganadora, ruta del resolvedor, ASN o cohorte de acceso, edge de destino, resultado de aplicación, implementación y hora. El respaldo por sí solo no autoriza a inferir la causa.

Combine la prueba normal de doble pila con sondas obligadas a IPv6 y a IPv4. La primera protege el viaje del cliente; las otras prueban cada superficie. Doble pila correcta más IPv6 forzado fallido significa «disponible pero degradado», no «todo sano».

Fuentes