Summary

  • Dans les mesures présentées par Patrick Sattler à RIPE 92, les versions testées de Chrome et Firefox attendaient les réponses DNS A et AAAA. Une réponse A tardive pouvait retarder la page alors même que l'adresse IPv6 était disponible; Firefox échouait dans certains cas.
  • Safari était le seul navigateur de ce groupe à appliquer le mécanisme complet de Happy Eyeballs v2, avec un délai de résolution. Pour les autres clients testés, les délais d'attente du résolveur pouvaient dicter le temps ressenti par l'utilisateur.

Le navigateur possède déjà l'adresse qu'il lui faut. Son accès IPv6 marche. Il attend quand même qu'une recherche IPv4 se termine. Patrick Sattler a exposé cette scène à RIPE 92 en comparant des navigateurs réels sous des retards DNS contrôlés.

Happy Eyeballs doit favoriser IPv6 sans laisser l'utilisateur bloqué lorsqu'un chemin échoue. On connaît la course entre tentatives de connexion; Sattler a examiné ce qui se passe avant le départ. Le client demande les enregistrements AAAA et A. Si son code exige les deux réponses avant de choisir, une réponse A lente peut prendre en otage une adresse IPv6 immédiatement utilisable. Son équipe a construit un serveur DNS et un test web configurables pour traiter chaque navigateur comme une boîte noire. La fiche officielle du talk résume les différences observées.

Dans les configurations de mai 2026, Chrome et Firefox envoyaient les deux demandes et attendaient leur retour. Les versions étudiées n'utilisaient pas le délai de résolution de Happy Eyeballs v2. Lorsque A tardait, le temps de chargement suivait l'attente du résolveur; Firefox pouvait même échouer alors qu'AAAA avait répondu. Safari, lui, poursuivait sur IPv6 si AAAA arrivait vite et A traînait. Lorsqu'AAAA tardait, il laissait environ 50 millisecondes dans le test montré avant de choisir IPv4.

Sattler a également isolé le départ des connexions. Chrome passait à l'autre famille après environ 300 millisecondes dans son essai, Firefox après environ 250; Safari utilisait une temporisation dynamique. Le navigateur, le système, le proxy et l'état du réseau modifient le résultat. Le test public n'était alors hébergé qu'à Munich, raison pour laquelle il demandait d'autres points de mesure.

Le résolveur entre ainsi dans une panne perçue comme « le site IPv6 est lent ». Son délai de répétition et son expiration deviennent décisifs si le navigateur attend la réponse A manquante. Sattler conseille aux opérateurs DNS d'examiner ces paramètres. Le fournisseur du navigateur décide de l'autre côté s'il laisse une réponse AAAA valable poursuivre sa route avant que A ne revienne.

La preuve qui manque dans un ticket de support ordinaire est précise : version du navigateur, système, résolveur, temps respectifs de A et AAAA et première connexion effectivement tentée. Un test de connectivité IPv6 vert ne suffit pas à expliquer l'onglet immobile. L'expérience de Sattler montre où le temps peut disparaître.

Sources : transcription primaire de RIPE 92 · présentation officielle · profil RACI.