Résumé

  • Le RFC 6555 proposait en 2012 une brève compétition entre familles d’adresses ; le RFC 8305 en a fait en 2017 un ordonnanceur complet, depuis le DNS jusqu’à l’annulation des tentatives perdantes.
  • Le délai recommandé de 250 ms arbitre entre attente perçue et charge spéculative : le raccourcir améliore la latence de repli mais déclenche davantage de connexions simultanées.
  • L’expérience utilisateur s’améliore alors même que la panne peut devenir moins visible pour l’exploitant, ce qui affaiblit l’incitation à réparer le chemin qui perd régulièrement.

Le point de départ de Happy Eyeballs est un conflit entre préférence et résultat. Une machine double pile reçoit des destinations IPv6 et IPv4. L’ordre architectural favorise IPv6, mais un chemin IPv6 lent ou rompu peut transformer cette préférence en attente. Publié comme Proposed Standard en avril 2012, le RFC 6555 a proposé de ne plus faire de l’utilisateur le chronomètre de cette défaillance.

Son exemple conservait l’ordre de préférence des adresses de l’hôte. Le client lançait la première connexion, attendait un court délai — Firefox et Chrome utilisaient alors 300 ms — puis lançait la première adresse de l’autre famille. La première connexion établie était utilisée et l’autre abandonnée. Le mécanisme ne déclarait pas IPv4 supérieur ; en l’absence d’historique, IPv6 restait préféré. Il fallait aussi éviter de créer une charge IPv4 inutile pendant une transition annoncée comme longue.

Ce détail est économique autant que technique. Un délai élevé économise des tentatives, mais facture à l’utilisateur la mauvaise qualité du chemin préféré. Un délai faible achète une meilleure latence avec des paquets, des sockets et du travail serveur supplémentaires. La valeur choisie constitue donc un prix implicite de l’incertitude. Elle détermine combien de temps le client accorde au premier candidat avant de mobiliser une ressource de secours.

Cinq ans d’exploitation ont montré que deux adresses et un seul temporisateur ne suffisaient pas à décrire le problème réel. Publié en décembre 2017, également comme Proposed Standard, le RFC 8305 a rendu le RFC 6555 obsolète. Il organise la connexion en quatre temps liés : requêtes DNS asynchrones, tri de toutes les destinations, tentatives de connexion asynchrones et décalées, puis conservation d’une réussite et annulation du reste.

La concurrence commence au DNS. Le RFC 8305 recommande d’envoyer AAAA d’abord, puis A immédiatement, sans attendre la réponse à la première requête. Si A arrive le premier, un Resolution Delay recommandé de 50 ms laisse une courte chance à AAAA. Ce n’est ni une attente systématique des deux réponses, ni une victoire automatique de la réponse la plus rapide. De nouvelles réponses peuvent encore rejoindre la liste pendant l’établissement de la connexion.

Le tri ajoute une mémoire au dispositif. Les règles de sélection de destination donnent l’ordre de base. Un client peut ensuite tenir compte d’un temps aller-retour historique ou d’une utilisation antérieure sur le même réseau. Les familles sont entrelacées : plusieurs adresses défaillantes d’une famille ne doivent pas monopoliser toute la file avant que l’autre soit essayée. L’historique est local au contexte réseau, car une adresse efficace au bureau ne prouve rien sur le réseau mobile suivant.

Le RFC 8305 recommande 250 ms comme Connection Attempt Delay par défaut. Il recommande un minimum de 100 ms, interdit de descendre sous 10 ms et recommande un maximum de deux secondes. Le First Address Family Count conseillé est un. Ces valeurs viennent de mesures empiriques et peuvent évoluer. Elles ne sont pas des lois du transport : elles équilibrent le temps humain et la charge réseau.

La généralisation couvre plusieurs adresses, des réponses DNS évolutives, l’historique et les réseaux IPv6-only utilisant NAT64/DNS64. Elle ne change pourtant pas la frontière de responsabilité. Happy Eyeballs traite l’échec initial de connexion TCP/IP. Une connexion transport établie ne garantit ni réponse correcte de l’application ni réussite d’un protocole supérieur.

La réussite masque parfois ce qu’elle compense. Dès 2012, le RFC 6555 signalait qu’une course rendait les pannes par famille plus difficiles à diagnostiquer. Le RFC 8305 conserve cette préoccupation, notamment lorsque des problèmes comme la découverte de MTU de chemin disparaissent derrière une autre route fonctionnelle. L’utilisateur obtient le service ; l’exploitant peut ne recevoir aucun signal assez fort pour réparer le perdant.

Happy Eyeballs est donc un contrat de compatibilité. Le logiciel assume une petite dépense spéculative pour que la transition IPv6 ne se traduise pas par une punition visible. En retour, IPv4 reste une assurance, avec sa consommation d’adresses rares et ses coûts d’exploitation. Le contrat est raisonnable seulement si la victoire du repli demeure observable. Sinon, la performance apparente devient une subvention silencieuse à l’infrastructure défectueuse.