Résumé

  • La version 05 du projet PROBE ajoute un retour d’expérience : la comparaison avec ping semble avoir orienté des développeurs vers une mauvaise hypothèse de format, puis des utilisateurs vers une lecture trop optimiste de l’écran.
  • Le texte améliore les explications, mais un contrôle durable doit encore relier le code de réponse brut, le libellé affiché et le test d’acceptation qui prouve leur fidélité.

La ligne rassure avant même d’être lue :

64 bytes from 192.0.2.2: icmp_seq=1 ttl=63 active=1 ipv4=0 ipv6=0

Une adresse a répondu, un numéro de séquence progresse, un TTL apparaît. Pour qui a déjà utilisé ping pendant un incident, la forme annonce presque automatiquement un succès. Or les deux zéros placés à la fin peuvent indiquer que l’état protocolaire recherché n’est pas présent.

C’est le retour d’expérience ajouté à la version 05 du projet PROBE. L’annexe explique que les lecteurs, très efficaces pour reconnaître des motifs, risquent de classer cette sortie comme positive sans examiner chaque champ. Ce n’est pas un simple problème de cosmétique. Le paquet observé et la décision prise à partir de l’écran sont deux objets distincts. La mise en forme peut leur imposer, sans mandat explicite, une signification commune.

Une requête différente de ping

Ping vérifie un aller-retour entre l’interface qui sonde et celle qui reçoit. PROBE interroge une interface par l’intermédiaire d’une autre, dite proxy. L’interface examinée peut se trouver sur le même équipement ou sur un voisin directement connecté. La connectivité bidirectionnelle nécessaire relie le demandeur au proxy, pas forcément le demandeur à l’interface examinée.

La réponse n’est donc pas un simple « joignable ». Pour une interface locale, le bit A exprime son activité, tandis que deux autres bits signalent séparément IPv4 et IPv6. Le tableau du projet prévoit notamment 1/0/0 : interface active, sans IPv4 ni IPv6 actifs. D’autres codes distinguent une requête mal formée, une interface inexistante, l’absence d’entrée dans la table consultée ou plusieurs interfaces correspondant à la demande.

Recevoir une réponse prouve que le proxy a traité la question. Cela ne prouve pas que l’état souhaité existe. Confondre réussite de l’échange et réussite du service transforme une mesure en verdict.

Quand le raccourci atteint le format

La même annexe remonte du regard vers le code. Le RFC 8335, publié en 2018, présentait PROBE comme semblable à ping. Selon la nouvelle version, cette formule semble avoir conduit des développeurs à supposer que le format des paquets lui ressemblait aussi. Les premières implémentations ont alors, d’après le texte, enfreint l’organisation habituelle des extensions définie par le RFC 4884.

Le projet bis documente désormais la compatibilité avec ce comportement : la structure d’extension contient exactement un objet d’identification d’interface, puis des données facultatives peuvent suivre hors de cette structure. Il déconseille de reproduire cette disposition pour d’autres usages. Il affirme aussi que les implémentations connues du RFC 8335 restent compatibles et que les précisions n’imposent ni changement sur le fil ni migration.

Il ne faut pas élargir ce constat. Le document ne dit pas que tous les développeurs ont commis la même erreur ni que quelques mots expliquent à eux seuls toute l’histoire. Il reconnaît quelque chose de plus circonscrit : une analogie familière paraît avoir favorisé un raccourci, et le coût de compatibilité de ce raccourci s’inscrit encore dans le texte de remplacement.

Un retour d’expérience, pas un recensement

L’historique Datatracker date le dépôt de la version 05 du 6 septembre 2026 en UTC ; le document porte la date du 7 septembre. Son sous-état passe de « Revised I-D Needed » à AD Followup. Il reste un Internet-Draft visant le statut Proposed Standard : ce n’est ni un RFC ni une approbation de l’IESG.

La comparaison officielle avec la version 04 isole l’ajout de l’annexe. En mai, l’Area Director responsable avait demandé un bref bilan du déploiement, notamment sur le passage par l’Internet public et par les équipements intermédiaires. Le nouveau texte répond qu’Extended Echo est désactivé par défaut, doit être étroitement contrôlé et sera le plus souvent utilisé dans un domaine où la même organisation maîtrise le chemin. Des essais individuels ont traversé certaines parties de l’Internet public, mais il n’existe pas de résultat expérimental large.

La nuance protège l’information. L’expérience n’est pas une mesure d’adoption. La version précise aussi que l’adresse doit être unicast, que l’AFI 1 conduit à la table ARP, l’AFI 2 au cache de voisins IPv6 et les autres valeurs à « No Such Table Entry ». Elle ne spécifie pas le Flow Label. Ces corrections resserrent le modèle sans certifier le comportement de tous les réseaux.

Autoriser la question ne garantit pas la lecture

Le projet impose une frontière d’accès utile. La fonction est coupée par défaut. L’opérateur ne devrait l’activer que sur les nœuds qui exigent ce diagnostic, limiter les préfixes sources aux réseaux de gestion autorisés et appliquer un débit maximal. Le texte interdit aussi les fuites entre instances réseau.

Ces mécanismes règlent l’identité du demandeur, le volume et la portée de la divulgation. Ils ne prouvent pas qu’un client restitue correctement le résultat. Une requête parfaitement autorisée peut toujours produire un écran trompeur pour une personne pressée.

L’annexe A.1 propose déjà d’afficher en toutes lettres les erreurs non nulles et donne des formulations explicites pour les combinaisons A/IPv4/IPv6. Il reste à rendre vérifiable la transformation complète. Un dossier local d’acceptation devrait relier : l’identifiant interrogé ; le caractère local ou adjacent de la requête ; le code et les bits bruts ; le libellé et la gravité affichés ; les versions du client et du serveur ; un vecteur de test pour chaque état négatif ou ambigu ; enfin le nom du réviseur et la date d’approbation.

Ce reçu résultat-affichage est une proposition éditoriale de Daniel Kade, pas une exigence de l’IETF. Il permettrait de démontrer qu’un échange de paquets réussi n’a pas été converti en affirmation erronée sur le service.

Une analogie reste utile tant que sa limite est explicite. Si un texte dit « comme ping », ses tests doivent montrer chaque endroit où PROBE ne l’est pas. Si un client reprend la silhouette de ping, l’état négatif doit dominer la ligne, pas se cacher dans ses derniers caractères.

Sources

  1. Projets Internet récents de l’IETF
  2. Fiche Datatracker de PROBE
  3. Historique des versions
  4. Version 05
  5. Version 04
  6. Comparaison officielle 04–05
  7. RFC 8335
  8. RFC 4884
  9. RFC 5706
  10. RFC 2151
  11. RFC 8343
  12. Dépôt source de PROBE
  13. Revue de l’Area Director sur la version 04
  14. Lu Heng — Minimum Initial Specification, Localized Future Decision
  15. Lu Heng — Running Code Primary