Résumé

  • DNS indique des adresses candidates ; il ne certifie pas que chaque chemin IPv4 ou IPv6 fonctionne depuis ce client, à cet instant.
  • RFC 6555 a transformé la préférence IPv6 en avance limitée. RFC 8305 a ensuite ordonné le mécanisme autour de requêtes DNS asynchrones, du tri RFC 6724, de l'entrelacement des familles et de tentatives décalées.
  • La première connexion établie gagne une seule course. Ce secours protège l'utilisateur, mais il peut rendre une panne persistante presque invisible à l'opérateur.

Deux réponses exactes, une seule route vivante

Le problème est formulé dès RFC 1671, en 1994. Pendant une longue transition, un nom peut fournir des adresses des deux familles alors qu'un routeur, un tunnel, un accord d'interconnexion ou le serveur lui-même ne transporte momentanément que l'une d'elles. Le DNS n'est pas faux : il décrit des candidats. C'est l'idée selon laquelle le premier candidat est joignable qui l'est.

Une application séquentielle amplifie cette erreur. Elle essaie IPv6, attend plusieurs retransmissions, puis se rabat sur IPv4. Le poste à double pile devient sensiblement plus lent que le poste IPv4 qu'il devait dépasser. Le remède le plus immédiat consiste alors à désactiver IPv6, ce qui transforme un défaut de transition en incitation contre la transition.

Un nom distinct réservé à IPv6 aurait fragmenté l'espace de noms. Une liste blanche maintenue par un fournisseur n'aurait pas suivi les défaillances intermittentes de chaque chemin. L'information manquante ne pouvait être obtenue qu'au moment où ce client précis tentait cette connexion précise.

Une priorité n'est plus un droit de veto

RFC 6555 normalise Happy Eyeballs en 2012. Le mécanisme ne supprime pas la politique de sélection. IPv6 reste généralement placé en tête. Mais si sa tentative ne progresse pas assez vite, une tentative IPv4 démarre sans nécessairement tuer la première.

La nuance est fondamentale. La politique décide qui part devant ; l'expérience décide qui livre la connexion. L'ordre exprime une orientation de long terme, tandis que le résultat absorbe une panne locale et réversible.

Cette expérience a un coût. Deux SYN consomment davantage de trafic, de descripteurs, d'états de pare-feu et parfois de ports derrière une traduction d'adresses. Les tentatives doivent donc être espacées et la perdante abandonnée dès qu'un vainqueur apparaît. Une compétition purement simultanée et indifférente chargerait inutilement l'infrastructure IPv4 partagée ; une attente IPv6 sans borne ferait payer à l'utilisateur une préférence administrative.

La première version permet aussi de mémoriser un échec. Cette mémoire ne doit pourtant pas devenir une condamnation. La famille préférée doit être réessayée périodiquement, environ toutes les dix minutes dans l'indication de RFC 6555, et l'état doit être remis à zéro lorsque l'appareil rejoint un nouveau réseau. Une panne vue dans un train ne constitue aucune preuve sur le réseau du bureau.

La deuxième version commence avant la connexion

RFC 8305, publié en 2017, remplace le premier texte après plusieurs années d'usage et de mesure. La course commence désormais dans la résolution. Les requêtes AAAA et A partent presque ensemble, AAAA en premier, sans exiger que les deux réponses soient revenues avant d'agir.

Si A arrive avant AAAA, le client peut attendre brièvement la réponse IPv6. La valeur recommandée est de 50 millisecondes. Ce délai de résolution conserve un léger avantage à IPv6 sans immobiliser une adresse IPv4 déjà connue. Il s'agit d'un réglage empirique, pas d'une constante du protocole.

Les adresses disponibles sont ensuite triées selon RFC 6724. Ce tri met en relation destination, source utilisable, portée et politique locale. Il fournit un ordre raisonné, jamais une garantie de passage.

La liste est alors entrelacée. Si elle commence par IPv6, la meilleure adresse IPv4 prend normalement la deuxième place. Ainsi, cinq AAAA injoignables ne monopolisent pas cinq délais avant le premier essai A. Happy Eyeballs v2 ne choisit pas un ambassadeur par famille : il organise l'ensemble des candidats.

Une tentative démarre, puis une autre après un délai tandis que la précédente reste active. RFC 8305 recommande 250 millisecondes par défaut. Elle interdit moins de 10 millisecondes, conseille 100 millisecondes comme minimum et deux secondes comme maximum. Une connaissance locale des temps aller-retour peut ajuster le rythme, mais cette mémoire doit rester attachée à l'interface et disparaître au changement de réseau.

Au premier établissement, les autres tentatives sont annulées. Les réponses DNS peuvent encore être traitées brièvement pour alimenter le cache, mais elles ne changent plus le vainqueur de cette connexion. La décision est finie et son domaine est étroit.

Une victoire qui ne vaut pas certificat

La réussite signifie généralement que la poignée de main du transport s'est achevée. Elle ne promet ni validation TLS, ni service HTTP cohérent, ni bon fonctionnement des gros paquets. RFC 8305 précise qu'une difficulté de MTU peut apparaître après cette phase et rester masquée pendant la course.

L'adresse gagnante n'est pas non plus une identité. Les réponses DNS évoluent et deux connexions vers le même nom peuvent choisir des adresses différentes. La sécurité doit venir de la couche qui connaît réellement l'identité attendue.

Enfin, le confort du client retire un signal à l'exploitation. Si IPv6 échoue toujours et qu'IPv4 prend le relais en un quart de seconde, le public ne voit presque rien. La panne existe pourtant. Le texte demande donc une surveillance indépendante des deux familles. La résilience n'abolit pas le devoir de diagnostic.

Sources et limites

Le corpus fermé réunit RFC 1671, RFC 6555, RFC 6724 et RFC 8305. Il établit les mécanismes et leurs bornes, mais ne mesure ni les logiciels actuels, ni la santé mondiale d'IPv6, ni un délai optimal pour tous les réseaux.