Résumé

  • La révision 05 propose un objet ICMP contenant une adresse IP, un nom de nœud ou les deux lorsque l’adresse source de la réponse ne suffit pas à identifier l’équipement.
  • La Last Call s’est terminée le 22 septembre 2026 ; le texte reste néanmoins un Internet-Draft en évaluation par l’IESG, et non une norme publiée ni une preuve de déploiement.
  • L’émission est recommandée désactivée par défaut, car le nom peut révéler la topologie ; le projet ne définit en outre aucun mécanisme d’authentification.

Le saut visible et le nœud réel

Dans un traceroute, chaque ligne invite à associer une adresse à un routeur. Cette lecture devient fragile lorsque plusieurs nœuds utilisent la même adresse de réponse, ou lorsque l’intérieur du réseau a des interfaces et des prochains sauts uniquement IPv6 alors que le diagnostic est lancé en IPv4.

Le projet d’identification du nœud répond à cette lacune par une information supplémentaire. Son objet peut transporter une adresse ayant une portée utile dans le contexte, un nom lisible, ou les deux. Une adresse locale est explicitement admise si l’opérateur du domaine peut l’interpréter. Le nom peut reprendre sys:hostname ou une autre désignation significative, dans une limite de 63 octets utiles.

Cette information ne remplace pas l’adresse source de l’erreur. Elle forme une seconde assertion : le paquet revient d’une adresse donnée et affirme en plus avoir été produit par tel nœud. Conserver cette séparation évite de transformer un indice en identité certaine.

Une procédure achevée n’est pas un RFC

L’IESG a lancé la Last Call le 8 septembre, avec une échéance au 22 septembre. La capture Datatracker du 24 septembre indique que la révision 05 est active, soumise à l’IESG, en attente du feu vert de l’Area Director et associée à des actions IANA. La page publique l’inscrit aussi à la téléconférence IESG du 8 octobre.

Ces étapes décrivent le traitement institutionnel du document. Elles ne constituent pas son approbation. Le texte porte toujours le statut d’Internet-Draft et une expiration au 11 mars 2027. Une décision future peut encore imposer une révision. Même un RFC Proposed Standard ne prouverait ni la présence du code dans un produit, ni son activation, ni l’utilité observée sur un réseau.

Le registre IANA des paramètres ICMP contient déjà la classe 5 « Node Identification Object », avec une référence à un ancien projet individuel. Cette inscription coordonne une valeur de classe. Elle ne certifie pas la sémantique finale de la révision 05 et ne témoigne d’aucun paquet en production.

Une extension encadrée

Le mécanisme s’insère dans la structure définie par le RFC 4884. Il est limité à certaines erreurs : Time Exceeded, Destination Unreachable et Parameter Problem en ICMPv4 ; Time Exceeded et Destination Unreachable en ICMPv6. Le format ordonne l’adresse avant le nom et fixe les règles de longueur afin que le récepteur puisse analyser l’objet.

Le RFC 5837 répond à une question voisine en identifiant une interface ou un prochain saut. La nouvelle proposition vise le système qui a émis l’erreur. Une interface, un prochain saut et un nœud sont trois objets d’observation distincts ; les confondre recréerait précisément l’ambiguïté que l’extension cherche à réduire.

Les scénarios motivants sont documentés. Le projet sur les routes IPv4 avec prochain saut IPv6 décrit un cœur où chaque équipement ne possède pas nécessairement une adresse IPv4 unique. Le projet XLAT et adresse IPv4 factice envisage qu’un traducteur ajoute son adresse antérieure à la traduction. Les RFC 7915 et RFC 6877 établissent le cadre de traduction, sans établir que l’objet proposé est implémenté.

Divulguer juste assez

Un nom tel que edge-paris-3 peut résoudre instantanément une incertitude pour l’équipe qui connaît le plan de nommage. Il peut aussi révéler emplacement, rôle et structure interne à un tiers. La révision 05 recommande donc de désactiver cette information par défaut, sauf dans le cas de traduction qu’elle précise. Elle permet une sélection selon la destination de la réponse ICMP et évoque les ACL pour limiter les destinataires.

La politique doit être plus précise qu’un interrupteur global. Il faut décider quels types de messages peuvent contenir une adresse, lesquels peuvent contenir un nom, et pour quels préfixes destinataires. Une adresse ULA peut être utile à l’exploitation interne et inutile à l’extérieur. Un nom tronqué peut perdre le suffixe qui le rend unique. Une adresse de gestion peut identifier un équipement sans prouver quelle instance de transfert a traité le paquet.

Une syntaxe valide n’authentifie pas l’émetteur

Le texte est explicite : aucun mécanisme d’authentification n’est défini et les messages ICMP sont faciles à usurper. La somme de contrôle de la structure du RFC 4884 aide à détecter certaines corruptions ; elle ne prouve pas l’origine d’un nom.

Un outil de diagnostic sérieux doit donc conserver le paquet brut, l’heure, le point d’observation, la sonde initiale, l’adresse source extérieure, les sous-objets et la politique attendue. Une analyse réussie signifie seulement que les octets respectent le format. L’identité demande d’autres éléments : répétition contrôlée, télémétrie de gestion authentifiée, configuration ou capture réalisée dans un environnement maîtrisé.

Cette discipline rejoint la primauté du code en fonctionnement, la spécification commune minimale et la décision future localisée et la séparation des couches de réalité. Le registre coordonne une valeur, le projet décrit un contrat, l’opérateur décide de la divulgation et l’observation mesure un résultat. Aucun niveau ne peut témoigner à la place du suivant.

Sources