Résumé

  • Happy Eyeballs réduit l’attente visible en faisant se chevaucher les tentatives; le gagnant ne prouve que sa propre joignabilité.
  • Il faut conserver, pour chaque famille, l’arrivée DNS, l’ordre, le démarrage, l’échec et l’annulation.
  • La réussite de l’application et le bon fonctionnement d’IPv4 et d’IPv6 sont deux constats différents.

Prenons un cas illustratif: une page se charge sans histoire après l’arrivée des réponses AAAA et A; IPv6 part d’abord, IPv4 suit et termine le premier. L’utilisateur ne voit aucune panne. Un tableau de bord limité aux sessions établies n’en voit aucune non plus. Pourtant IPv6 peut rencontrer un problème de chemin ou de service, ou simplement être annulé avant d’avoir pu répondre. La connexion gagnante ne permet pas de trancher.

Le RFC 8305 définit le comportement de course dont cette ambiguïté peut découler: les résolutions A et AAAA sont lancées presque simultanément, les destinations sont triées selon le RFC 6724, les familles sont entrelacées, puis les tentatives sont décalées. Dès qu’une connexion réussit, les autres sont annulées. Selon l’analyse éditoriale de cet article, ce mécanisme peut protéger la disponibilité puisqu’une option défaillante n’impose pas tout son délai à l’utilisateur.

Mais une annulation n’est ni un succès IPv6 ni forcément un échec IPv6. C’est une observation censurée par la victoire d’un autre candidat. De même, une victoire IPv4 ne prouve pas une préférence IPv4: l’ordre des réponses DNS, la politique RFC 6724 et l’historique des temps aller-retour peuvent modifier la course.

Les 250 millisecondes souvent citées ne constituent pas un objectif universel. Le RFC 8305 les propose comme valeur par défaut possible pour le délai entre tentatives, avec adaptation et bornes. Il distingue aussi ce délai du délai de résolution lorsque A arrive avant AAAA. Le reçu utile contient donc les valeurs réellement appliquées et leurs horodatages, pas seulement une case « activé ».

Le RFC 8305 signale explicitement que le mécanisme peut masquer des problèmes opérationnels. Il ne faut pas désactiver la course, mais mesurer les chemins perdants sans imposer leur attente à l’utilisateur. Pour chaque épisode, conserver le contexte réseau, le résolveur, les arrivées A/AAAA, la liste ordonnée, la famille, le Resolution Delay configuré, le Connection Attempt Delay configuré ou adapté, le décalage réel de départ, l’étape de négociation, le résultat de chaque tentative, le résultat côté application, la cause d’annulation, le gagnant, ainsi que le périmètre réseau et la durée de tout historique de connexion mis en cache.

À titre de recommandation opérationnelle éditoriale, agréger ces données pendant une durée limitée afin de réduire l’exposition liée à la vie privée.

Le RFC 6555 partait du retard provoqué par un IPv6 défectueux. Son remplaçant affine le remède; aucun des deux ne transforme une session récupérée en certificat de la famille perdante. Le RFC 6724 définit un ordre de sélection, pas un résultat de sonde.