Résumé

  • Le RFC 4620 offrait aux outils de diagnostic IPv6 une interrogation directe du nom ou des adresses déclarés par un nœud, notamment sur un lien sans DNS ni routage global.
  • Le répondant gardait le droit de refuser ; son message restait une déclaration locale, pas une identité authentifiée ni une fiche faisant autorité.

Analyse

Une adresse IPv6 configurée automatiquement peut fonctionner sans être facile à reconnaître. Lorsqu’un technicien met un lien en service ou cherche l’origine d’un problème, le DNS n’est pas toujours présent sur le segment et une adresse locale au lien n’a pas nécessairement de fiche publique. Il peut néanmoins être utile de demander à l’extrémité active quel nom ou quelles adresses elle associe à elle-même.

En août 2006, Michael Crawford et Brian Haberman ont décrit cette possibilité dans le RFC 4620, classé expérimental. Le texte en limitait l’usage au diagnostic, au débogage et à l’administration de réseau. Il précisait que le DNS demeurait la source faisant autorité pour les noms et adresses de l’Internet global. La requête de nœud n’était donc pas un nouvel annuaire mondial, mais un outil de proximité pour des réseaux où la résolution ordinaire pouvait manquer.

L’échange passait par ICMPv6 : type 139 pour la requête et type 140 pour la réponse. La requête désignait un répondant et un sujet, qui pouvaient être différents. Les types d’information définis couvraient une opération sans données, le nom d’un nœud, ses adresses IPv6 et ses adresses IPv4 ; les indicateurs de la demande d’adresses permettaient de préciser les portées recherchées. La réponse pouvait ainsi aider à comprendre ce qu’un équipement déclarait sur le lien, sans prétendre décrire toutes ses interfaces de façon exhaustive.

Le refus faisait partie du protocole. Le code de réponse distinguait la réussite, le refus et un type de requête inconnu. Même une réponse réussie pouvait ne contenir aucune donnée. Silence, refus, type non pris en charge et résultat vide ne prouvent donc pas la même chose : aucun ne démontre à lui seul que l’équipement est absent. Le répondant devait aussi vérifier que le paquet visait une adresse qui lui appartenait ou un groupe multicast local auquel il avait adhéré ; une politique locale pouvait écarter la demande.

Un nonce de 64 bits, recopié dans la réponse, aidait à rattacher celle-ci à la requête et à compliquer une falsification aveugle. Les auteurs avertissaient toutefois qu’un observateur capable d’écouter l’échange pouvait contourner cette protection. Ils recommandaient IPsec si une vraie sécurité de communication était nécessaire et déconseillaient d’utiliser les renseignements obtenus pour une décision de sécurité sans authentification supplémentaire.

La divulgation était également bornée : par défaut, une implémentation devait refuser les requêtes provenant d’adresses de portée globale. Le texte recommandait de limiter le débit des réponses et de contrôler l’exposition des adresses temporaires de confidentialité. Les types ICMPv6 139 et 140 figurent toujours au registre IANA, ce qui atteste l’existence de numéros attribués, pas la réponse effective de chaque hôte. Le RFC citait ping6 dans KAME et USAGI ; la documentation actuelle de Nmap décrit aussi un outil de découverte. Ces exemples prouvent un usage par des outils, pas son ampleur sur les réseaux.

L’apport historique du RFC 4620 tient à cette distinction : un nœud pouvait aider au dépannage en livrant une auto-déclaration, tout en conservant le droit de ne pas la fournir. Une réponse ne désignait pas une organisation, ne prouvait pas qui contrôlait la machine et ne transformait pas une observation en fiche d’inventaire faisant foi.

Sources