Résumé

  • draft-ietf-v6ops-ipv6-app-testing-03 distingue IPv4 seul, double pile, IPv6 avec NAT64 et IPv6 strict sans chemin IPv4 pertinent. Une réussite en double pile peut n’être que la réussite du repli ; elle ne certifie pas le comportement strict.
  • Installation, interface, gestion et mise à jour sont des surfaces différentes. Une déclaration crédible doit nommer chaque flux important, le scénario applicable, la preuve que le banc a créé cette condition et les résultats de transport et d’application.

Le badge avait absorbé des chemins jamais exercés

Un test utilisateur traverse rarement tout le produit. Il peut solliciter le frontal, l’identité et l’API principale sans appeler l’activation, le dépôt de paquets, la télémétrie, l’assistance distante, la sauvegarde ou la restauration. Résumer ce seul trajet par « IPv6 prêt » donne aux chemins observés autorité sur les chemins absents.

Les quatre conditions de la révision 03 ne sont donc pas quatre étiquettes de produit. Elles s’appliquent à un flux orienté, pour une version, une fonction du cycle de vie, des rôles d’extrémité et un intermédiaire donnés. Le reçu utile associe ces éléments à un résultat attendu et à un résultat constaté.

Dans une application distribuée, un essai de bout en bout est un itinéraire à travers un graphe. Équilibreur, passerelle, authentification, autorisation, stockage et journalisation créent leurs propres flux. Un composant sert de client ici et de serveur ailleurs. Le succès final ne prouve ni que toutes les arêtes ont utilisé IPv6 ni que les arêtes non empruntées fonctionneront.

Il n’est pas nécessaire d’exécuter aveuglément tout produit cartésien. Une architecture contrôlée permet d’exclure des combinaisons, mais l’exclusion doit avoir une version, un propriétaire et une justification vérifiable. Une ligne omise est inconnue ; elle n’est pas réussie.

La double pile peut masquer l’échec qu’elle répare

Happy Eyeballs protège l’expérience de l’utilisateur, mais modifie la portée du test. Une tentative IPv6 peut échouer après TCP et avant TLS, puis IPv4 peut achever l’opération. Une mauvaise adresse AAAA peut être contournée. RFC 8305 organise la course entre candidats ; elle ne prouve pas que le candidat perdant fonctionne.

DNS64 selon RFC 6147, les adresses de RFC 6052 et 464XLAT selon RFC 6877 peuvent rendre joignable une dépendance IPv4. C’est une observation valable si le scénario vise la transition. C’est une contamination si le rapport affirme « IPv6-only-strict ». CLAT, DNS64, préfixe NAT64, VPN, tunnel et relais doivent alors être exclus par une preuve du banc.

Le reçu doit conserver réponses DNS, candidats, famille choisie, tentatives, chronologie du repli, proxy ou traducteur, résultat du transport et résultat fonctionnel. Garder seulement la réussite finale efface précisément l’échec recherché.

Le banc peut lui aussi tomber en panne. Désactiver IPv4 peut couper l’administration d’une machine virtuelle ou l’authentification d’entreprise. Il faut distinguer la santé du banc de celle de l’application et observer le premier sans réintroduire le chemin interdit.

Le cycle de vie ne se réduit pas à l’écran principal

Le projet isole installation, interface utilisateur, gestion et mise à jour. L’installateur dépend parfois d’une activation ou de dépôts tiers. La gestion comprend API, SNMP, syslog, surveillance et support. Le programme de mise à jour peut utiliser d’autres processus, certificats, miroirs et mécanismes de retour arrière.

Une interface réussie ne teste pas l’installation. Un appel de gestion réussi ne garantit pas que les journaux représentent correctement une source IPv6. Une mise à jour manuelle ne teste pas nécessairement l’automate nocturne. La couverture doit donc être organisée par flux orientés et propriétaires, non par captures d’écran.

Un proxy ajoute une troisième branche. IPv6 entre client et proxy ne dit rien du lien proxy-origine. Le proxy peut résoudre autrement, traduire les familles ou garder un amont IPv4. TURN ajoute encore des candidats ; RFC 8656 décrit le relais, pas l’exhaustivité de la campagne d’un produit.

La réutilisation rend l’inventaire récursif. Ajouter un AAAA à un service partagé peut faire arriver d’autres produits en IPv6 avant que leurs listes d’accès, journaux ou limites ne soient prêts. Un changement localement correct modifie le contrat opérationnel de ses consommateurs. Le manifeste doit être lié aux versions et aux dépendances.

L’adresse est aussi une donnée de contrôle

L’application ne fait pas que transporter une adresse : elle la valide, l’affiche, la stocke, la compare et l’utilise pour autoriser. RFC 4291 définit l’architecture et RFC 5952 recommande une représentation, mais le code métier peut n’accepter que le décimal pointé, tronquer une chaîne ou séparer deux formes équivalentes.

Les listes d’accès rendent le défaut immédiat. Dès qu’un serveur publie AAAA, des clients capables peuvent arriver en IPv6. Si l’autorisation ne contient que leurs adresses IPv4, la connexion aboutit puis l’application refuse. Happy Eyeballs ne répare pas une politique évaluée après le transport.

De même, recevoir IPv6 sans pouvoir rechercher correctement la source dans l’audit ou la réponse aux abus n’est pas une préparation opérationnelle complète. Le taux agrégé de trafic IPv6 peut rester élevé tout en cachant une fonction de gestion ou de reprise encore liée à IPv4.

Une trace prouve ce qu’elle a observé

Quand l’isolement strict est impossible, journaux client, journaux serveur et captures réduisent l’incertitude. Mais l’absence d’IPv4 dans une capture ne vaut que pour son interface, ses filtres, sa fenêtre et l’inventaire de flux connu. Un travail différé, une branche conditionnelle ou une dépendance d’une autre version peut ne pas apparaître.

Le projet qualifie l’observation réseau d’alternative la plus sujette à erreur, car l’analyste doit déjà connaître le schéma de communication. La formulation défendable est : « tous les flux du manifeste X ont été observés en IPv6 pendant l’exécution Y ». Elle n’est pas : « aucune dépendance IPv4 cachée n’existe ».

Un Last Call n’est pas un reçu de production

La source figée est la révision 03 du 29 septembre 2026, expirant le 2 avril 2027. Datatracker la classe document V6OPS actif, I-D Exists, en Last Call du groupe. L’en-tête vise Best Current Practice, tandis que le champ intended-status de Datatracker est vide. Ce n’est aujourd’hui ni un RFC ni un BCP.

Le document peut normaliser les questions, pas exécuter les essais. RFC 8504 énonce des exigences de nœud IPv6 sans remplacer la couverture fonctionnelle d’une application. RFC 8585 décrit des scénarios d’entreprise sans certifier une dépendance particulière.

La primauté du code en fonctionnement impose l’ordre : le guide définit la question ; le manifeste déclare le dénominateur ; le banc crée la condition ; l’instrumentation observe le chemin ; l’application produit le résultat ; la production montre si ce résultat survit aux changements. Aucune couche ne crée la suivante par proclamation.

Sources