Résumé

  • La révision 05 de draft-ietf-intarea-extended-icmp-nodeid a été annoncée le 7 septembre 2026 après l’examen du directeur de zone responsable. Le Datatracker indique Last Call Requested, et non une RFC achevée.
  • Le texte impose désormais l’objet d’identification lorsque l’adresse de réponse risque de ne pas suffire, sauf primauté de la politique locale ou de la sécurité. La section sécurité recommande toujours une désactivation par défaut, hors traducteurs IP/ICMP.
  • Il s’agit de deux étages de décision : ouvrir ou non la capacité de divulgation, puis traiter un message qui entre dans le périmètre autorisé. Le nom transmis ne devient pas pour autant authentifié.
  • Daniel Kade propose une table de décision versionnée reliant configuration, critère d’applicabilité, exception, destinataire, contrainte de MTU, octets émis et octets observés. Ce n’est pas une exigence de l’IETF.

Le mot normatif a changé

L’annonce du 7 septembre présente la version 05 comme un document de travail du groupe INTAREA. Sa fiche Datatracker la classe parmi les Internet-Drafts actifs, transmis à l’IESG pour publication avec le statut visé Proposed Standard. L’état IESG est Last Call Requested et aucune date de téléconférence n’est affichée. Parler déjà de « nouvelle norme » effacerait donc une étape décisive.

L’évolution mérite néanmoins l’attention. Dans son examen d’octobre 2025, Éric Vyncke demandait notamment quand le SHOULD de la section 3 pouvait être écarté. Il contestait aussi l’imprécision du mot domain, réclamait une règle plus claire pour les bits futurs, un traitement élémentaire de la MTU et de la fragmentation, ainsi qu’une demande explicite de registre des sous-types auprès de l’IANA.

Le différentiel officiel permet de voir la réponse. La version 04 recommandait d’ajouter l’extension lorsqu’elle était nécessaire à l’identification. La version 05 dit qu’elle doit être ajoutée lorsque l’adresse IP de réponse peut ne pas suffire, sauf si la politique locale ou des considérations de sécurité l’emportent. Une permission d’inclusion inconditionnelle est ajoutée et la notion vague de domaine devient une question de portée pertinente.

Ce passage de SHOULD à MUST n’abolit donc pas le jugement. Il déplace le jugement vers un prédicat — l’adresse est-elle suffisante ? — et vers deux exceptions nommées. Pour vérifier une implémentation, il faut savoir comment ces trois éléments ont été décidés.

Deux champs utiles, aucune preuve d’identité

Le projet s’appuie sur la structure ICMP multipartie de la RFC 4884. Dans cinq catégories d’erreurs ICMPv4 ou ICMPv6, l’objet de classe 5 peut contenir une adresse IP, un nom, ou les deux. Les bits utilisés reprennent ceux de la RFC 5837, consacrée aux interfaces et aux prochains sauts, afin de faciliter la réutilisation du code de sérialisation et d’analyse.

L’adresse doit être pertinente dans la portée où elle sera interprétée. Une adresse locale unique IPv6 peut convenir même si elle n’a pas de sens mondial : l’opérateur du domaine concerné peut posséder la correspondance qui manque à un observateur extérieur.

Le nom occupe au plus 63 octets utiles dans un sous-objet rembourré à une longueur maximale de 64 octets. Le projet recommande le sys:hostname du modèle système YANG de la RFC 7317, lorsqu’il convient, ou un autre nom intelligible. La nouvelle version précise qu’une coupure à la limite doit respecter le début et la fin des caractères UTF-8.

Ce mécanisme répond à un cas concret. Dans certains montages IPv4 sur infrastructure IPv6, le routeur intermédiaire ne possède pas d’adresse IPv4 distinctive pour répondre au traceroute. Un traducteur IP/ICMP peut joindre l’adresse source antérieure à la traduction et rendre le retour plus exploitable par l’opérateur.

Mais exploitable ne veut pas dire authentifié. Le projet le dit sans détour : il ne définit aucun mécanisme d’authentification, et le message ICMP comme son contenu se falsifient facilement. Un nom ressemblant à une entrée d’inventaire reste une déclaration transportée par un message non authentifié. Ni la classe d’objet ni la syntaxe ne prouvent le propriétaire du châssis, l’opérateur, l’autorité sur une route ou la responsabilité d’un incident.

Une posture de configuration, puis une règle par paquet

La section 5 recommande que l’ajout soit configurable et désactivé par défaut, sauf pour les traducteurs IP/ICMP qui devraient joindre l’adresse. Elle autorise en outre une sélection selon l’adresse de destination et des listes de contrôle d’accès. Cette couche répond à la question : à quelles catégories de destinataires ce réseau consent-il à livrer ces détails ?

La section 3 intervient ensuite. Pour un message placé dans le périmètre autorisé, si l’adresse de réponse risque de ne pas identifier le nœud, l’objet devient obligatoire, à moins que la politique ou la sécurité ne prévale. C’est la décision d’exécution, et non la politique générale d’exposition.

Cette lecture à deux étages est une analyse, pas une décision formelle de conformité de l’IETF. Le projet ne définit pas algorithmiquement une adresse « suffisante », ne désigne pas le rôle interne habilité à activer l’exception et ne transporte pas de code expliquant une omission. Le texte commun existe ; la preuve du chemin suivi reste locale.

L’absence ne désigne pas sa cause

Devant un ICMP Time Exceeded sans objet Node-ID, un collecteur ne sait pas si l’adresse ordinaire a été jugée suffisante, si le réglage par défaut a été conservé, si une règle de sécurité a bloqué le champ ou si une ACL l’a réservé à d’autres destinataires. Il ne sait pas non plus si le logiciel implémente la version, ni si le retour a été filtré ou mal interprété en chemin.

Le traducteur ajoute encore une branche vérifiable. Si l’objet ferait dépasser la MTU sous-jacente, la révision 05 recommande de réduire la partie contenant le datagramme d’origine, dans les limites posées par la RFC 4884. Si l’opération est impossible, l’objet ne doit pas être ajouté. Le destinataire observe alors le même vide qu’après un choix de confidentialité, mais l’obligation technique n’est pas la même.

Inversement, la présence d’un nom ne permet pas de conclure qu’il provient bien de sys:hostname, qu’il est à jour, qu’il correspond de façon univoque à un inventaire ou qu’il a été émis par l’équipement désigné. Une adresse locale ne devient pas attribuable à l’échelle mondiale parce qu’elle a été correctement encodée.

Le registre IANA actuel affiche déjà la classe 5 Node Identification Object, encore reliée à une ancienne version individuelle du projet. La révision 05 demande un registre de sous-types et réserve les futurs bits à Standards Action, procédure définie par la RFC 8126. Cette discipline peut stabiliser le vocabulaire des champs ; elle n’établit pas la provenance de leurs valeurs.

Une table de décision sans publier les noms

Une bonne preuve d’implémentation commencerait par une table versionnée. Pour chaque test : rôle de l’émetteur — nœud d’origine ou traducteur —, famille d’adresses, type ICMP, règle utilisée pour juger l’adresse ordinaire, état de configuration, éventuelle exception de politique ou de sécurité et propriétaire de cette décision.

Il faut ensuite indiquer la classe de destinataire ou d’ACL, les sous-objets admissibles, le résultat du calcul de MTU, la réduction éventuelle du datagramme cité, les octets effectivement émis, puis ceux reçus depuis une position et à une heure nommées. La dernière colonne doit rester indépendante : aucune authentification dans ce projet, sauf mécanisme extérieur réellement démontré.

Cette table ne doit pas devenir un nouveau champ sur le fil. Des noms synthétiques, des configurations de test hachées et des catégories grossières de destinataires suffisent pour une version publique. L’opérateur conserve ses secrets ; le constructeur montre son arborescence de décision ; le chercheur sait enfin quelle conclusion l’observation n’autorise pas.

Sources