Résumé

  • Happy Eyeballs protège l’utilisateur en essayant rapidement d’autres adresses lorsqu’une famille est lente ou défaillante. Ce mécanisme peut maintenir le taux de succès global au vert pendant qu’IPv6 échoue.
  • Il faut une preuve par famille : réponses DNS, candidats, tentatives réelles, famille gagnante, erreurs perdantes et contrôles forcés sur des cohortes d’accès représentatives.

Prenons un scénario explicitement hypothétique. La sonde principale est verte, les transactions aboutissent et le support ne constate aucune panne. Une seconde sonde, limitée à IPv6 depuis un réseau d’accès précis, ne se connecte pas. Les deux constats peuvent être exacts. Le client ordinaire reçoit A et AAAA, tente IPv6, puis établit IPv4 assez vite pour que l’utilisateur ne voie qu’un faible retard.

Ce n’est pas l’allégation d’un incident chez un opérateur nommé. C’est une limite de mesure. Le succès d’une transaction prouve qu’un chemin a fonctionné, pas que toutes les familles annoncées étaient saines.

Le RFC 8305 définit Happy Eyeballs v2 afin de réduire le délai visible lorsque des adresses, voire une famille entière, sont bloquées, défaillantes ou sous-optimales. Le client lance les requêtes A et AAAA de manière asynchrone, classe les destinations, espace les tentatives et conserve la connexion qui réussit. Les autres sont annulées. IPv6 est normalement favorisé, mais la continuité immédiate reste l’objectif.

Les temporisations recommandées expliquent pourquoi le défaut peut disparaître du tableau. Le RFC propose 50 ms pour attendre la résolution et 250 ms entre tentatives sans historique RTT. Une implémentation peut modifier ces valeurs ou utiliser ses mesures antérieures. Elles ne décrivent pas tous les clients. Le fait durable est la course : sans télémétrie sur les essais perdants, la connexion gagnante dit peu sur leur échec.

Le RFC 6724 ajoute la sélection des adresses source et destination entre IPv6 et IPv4, avec une politique que l’administrateur peut modifier. Deux terminaux interrogeant le même nom peuvent donc ordonner différemment leurs candidats selon les adresses disponibles, la portée, la configuration ou l’état connu.

Un compteur HTTP global écrase ces décisions en un seul bit. Il ne dit pas si AAAA est arrivé, quelle adresse IPv6 a été essayée, combien de temps elle a attendu, ni si la panne venait du DNS, de la découverte de voisins, du routage, d’un filtre, du MTU de chemin ou du service. Il ne distingue pas non plus un choix IPv4 voulu d’un sauvetage.

Le relevé minimal doit conserver les réponses A/AAAA et leurs horaires, l’ordre des candidats, la famille source et destination, le début et la fin de chaque tentative, l’erreur ou l’expiration perdante, la famille gagnante, le résolveur, le réseau d’accès ou ASN, l’edge, le résultat applicatif, l’implémentation et l’heure d’observation. Le repli seul ne suffit pas à diagnostiquer la cause.

Associez les contrôles double pile à des sondes forcées IPv6 et IPv4. Le contrôle ordinaire protège le parcours client ; les contrôles forcés vérifient chaque surface. Un succès double pile accompagné d’un échec IPv6 signifie « disponible mais dégradé », pas « entièrement sain ».

Sources