Résumé

  • La révision 05 impose l’objet Node Identification pour certains messages d’erreur ICMP lorsque l’adresse source risque de ne pas identifier suffisamment le nœud émetteur, sauf priorité donnée à la politique locale ou à la sécurité.
  • L’adresse ou le nom fourni peut être précieux dans sa portée d’exploitation, notamment après une traduction d’adresses, mais l’objet n’est pas authentifié et peut être usurpé.
  • Pour respecter la MTU du prochain saut, l’ajout de l’objet peut réduire la citation du datagramme d’origine. Il faut donc noter séparément la confiance dans le contexte du nœud et la qualité de corrélation du paquet.

Le nom qui remplit trop bien la case

Imaginons une console qui reçoit une erreur ICMP et affiche aussitôt un nom de nœud. Le diagnostic paraît avancer d’un cran : l’adresse externe, parfois peu parlante, vient d’être remplacée par une étiquette locale compréhensible. Le risque commence lorsque l’interface transforme ce gain de contexte en verdict d’identité.

Le projet draft-ietf-intarea-extended-icmp-nodeid cherche à résoudre un problème réel. L’adresse source choisie pour un message ICMP ne suffit pas toujours à reconnaître l’équipement qui l’a produit. C’est particulièrement visible lorsqu’un traducteur IPv6/IPv4 crée l’erreur depuis un point de vue qui ne subsiste plus tel quel dans le paquet remis au destinataire.

La révision 05, datée du 7 septembre 2026, définit un objet d’identification du nœud pour une liste précise d’erreurs ICMPv4 et ICMPv6. Le Datatracker la classe comme Internet-Draft actif du groupe INTAREA, destiné à la voie normative et au stade de suivi après évaluation de l’Area Director. Ce statut n’est ni une RFC, ni une approbation de l’IESG, ni une preuve de déploiement.

La différence centrale avec la révision 04 tient à un verbe normatif. Lorsque l’adresse de réponse risque de ne pas identifier suffisamment le nœud d’origine, l’objet n’est plus seulement recommandé : il doit être ajouté, à moins qu’une politique locale ou des considérations de sécurité ne priment. Le texte rend également obligatoires le traitement d’un masque de bits courant vide et l’ordre d’attribution de futurs bits, précise la troncature UTF-8 et décrit le comportement sous contrainte de MTU.

Cette obligation augmente la probabilité de recevoir un indice. Elle n’augmente pas, à elle seule, la force probante de cet indice.

Une adresse utile n’est pas forcément publique

L’objet peut contenir une adresse, un nom de nœud, ou les deux. Les bits du C-Type indiquent les sous-objets présents et leur ordre. Si un futur sous-objet inconnu précède un type connu, un ancien récepteur ne peut pas deviner où commence le second : la longueur du premier lui échappe. La révision demande donc d’ignorer les données supplémentaires. Réserver des bits prépare une extension ; cela ne crée pas magiquement une grammaire que les anciens parseurs savent sauter.

L’adresse doit être lue dans sa portée. Une adresse locale peut n’être routable qu’au sein d’un domaine et rester le meilleur indice pour l’équipe qui administre ce domaine. La RFC 4193 illustre bien ce point avec les adresses locales uniques IPv6 : leur construction vise l’unicité, alors que leur usage demeure local. Sortie de ce contexte, la même valeur peut perdre l’essentiel de son sens.

Le nom est limité à 63 octets. Si une chaîne UTF-8 doit être raccourcie, la révision 05 exige de couper entre deux caractères avant le remplissage par des octets NUL. Cela protège la validité du codage, pas l’unicité du nom et encore moins son authenticité.

La fonction reste désactivée par défaut, sauf pour les traducteurs, et l’émetteur peut appliquer une règle selon la destination. Cette réserve n’est pas décorative. Révéler un nom interne ou une adresse de portée locale peut exposer une topologie, une convention d’exploitation ou un élément d’inventaire. La portée du MUST s’arrête donc là où une décision locale de sécurité s’applique.

La revue de l’Area Director a précisément interrogé le passage de la recommandation à l’obligation, l’ambiguïté de la portée, la longueur UTF-8 et l’effet sur la taille du paquet. La réponse des auteurs éclaire les modifications et le maintien de l’exception de politique. Cet échange documente un travail normatif en cours, pas son aboutissement.

Ce que voit le traducteur

Un traducteur peut connaître l’adresse du nœud avant conversion alors que l’adresse source de l’erreur livrée de l’autre côté ne la restitue pas. L’objet lui permet de conserver ce contexte. La RFC 7915 décrit le cadre de la traduction IP/ICMP sans état et la conversion des paquets cités. Un projet v6ops complémentaire traite le cas où une adresse source IPv6 ne se traduit pas en IPv4 : l’adresse IPv4 réservée 192.0.0.8 sert alors de valeur de substitution, tandis qu’une extension conserve l’adresse IPv6 originale.

La combinaison est instructive. Le champ extérieur permet d’acheminer et de reconnaître la catégorie de réponse ; l’extension restitue un contexte qui aurait disparu. Aucun des deux ne doit être interprété au-delà de son contrat.

Le projet le dit sans détour : l’objet Node Identification n’apporte pas d’authentification et peut être usurpé. Il vise le dépannage administratif. Le bon enregistrement n’est donc pas « nœud vérifié », mais « nœud déclaré par l’émetteur, valeur utile dans telle portée ». Une politique de confiance indépendante peut renforcer ce constat ; elle ne se déduit pas de la présence de l’objet.

L’octet consacré au nom ne cite plus le paquet

Les extensions ICMP s’inscrivent dans le format de la RFC 4884, qui conserve au moins 128 octets du datagramme d’origine avant les objets d’extension. La RFC 5837 utilise déjà ce mécanisme pour décrire des interfaces et leur rôle sur le chemin. Chaque information additionnelle doit néanmoins tenir sous la MTU.

La révision 05 rend le compromis explicite. Si l’objet ferait dépasser la MTU du prochain saut, l’émetteur peut retirer assez d’octets de la citation d’origine, par multiples de quatre octets en ICMPv4 et de huit en ICMPv6. Si la citation a déjà atteint le minimum, l’objet ne doit pas être ajouté.

Le coût touche directement la corrélation. Les en-têtes ou données retranchés peuvent être ceux dont un collecteur avait besoin pour relier l’erreur à un flux précis. À l’inverse, ne pas ajouter l’objet protège la citation mais laisse le nœud moins identifiable. La spécification ne choisit pas une preuve parfaite : elle ordonne un compromis borné.

L’absence possède alors plusieurs explications plausibles : adresse source jugée suffisante, type ICMP non concerné, fonction non activée, politique de destination, secret opérationnel, implémentation sans support, ou citation déjà au minimum sous pression de MTU. Elle ne signifie pas « aucun nœud identifié ». La présence n’est pas davantage une signature.

Deux colonnes, pas une note magique

Une plateforme de diagnostic devrait conserver deux axes. Le premier décrit le contexte du nœud : objet présent ou absent, type de valeur, portée, lieu possible d’insertion et niveau de confiance accordé au domaine émetteur. Le second décrit la corrélation : longueur de la citation, champs survivants, ambiguïtés entre flux candidats et réduction éventuelle pour respecter la MTU.

Une note globale ferait disparaître les cas les plus intéressants. On peut disposer d’une excellente citation avec une origine peu claire, ou d’un nom local très utile avec trop peu d’octets pour retrouver la transaction. Les deux sont des observations valables, à condition de ne pas les confondre.

Les sources ne fournissent encore ni test d’implémentation ni mesure de fréquence. Elles ne disent pas combien de produits adopteront la révision, combien d’opérateurs l’activeront ou combien de citations seront raccourcies. La norme proposée améliore le langage de l’erreur ; elle ne fournit pas encore la statistique du terrain.