Résumé
- La RFC 9898 ramène quinze difficultés de Neighbor Discovery à trois causes : le multicast, la confiance accordée à tous les nœuds du lien et la création de NCE à la demande par le routeur.
- L’état REACHABLE atteste une utilisabilité récente du voisin selon ND. Il ne désigne pas l’abonné, ne prouve pas son droit sur l’adresse et ne reconstitue pas l’identité passée.
Le rapport d’incident semblait disposer d’une pièce décisive : à 14 h 07, le routeur affichait l’adresse IPv6, une adresse de couche liaison et l’état REACHABLE. La connectivité n’était donc pas en cause. Mais la question adressée à l’équipe était différente : quel abonné utilisait cette adresse pendant la fenêtre litigieuse ?
La table ne mentait pas. Elle répondait simplement à une autre question. Son rôle était de rendre le prochain envoi possible, non de conserver la chaîne contractuelle d’attribution. L’erreur d’enquête commence quand une preuve exacte dans son domaine est promue au rang d’autorité hors de ce domaine.
La RFC 9898, publiée à titre informatif, rassemble les problèmes de Neighbor Discovery dispersés dans plus de vingt RFC. Elle identifie quinze difficultés potentielles, qui ne se matérialisent pas nécessairement partout. Leur origine commune tient à trois choix : plusieurs opérations reposent sur le multicast, les nœuds présents sur un lien sont historiquement supposés fiables et le routeur fabrique une entrée de voisin lorsqu’un paquet lui demande soudain d’atteindre une adresse locale inconnue.
La RFC 4861 sépare quatre objets conceptuels. Le Neighbor Cache associe une adresse unicast sur le lien à des informations de couche liaison et d’accessibilité. Le Destination Cache mémorise le prochain saut vers une destination. La Prefix List définit ce que le nœud considère sur le lien. La Default Router List rassemble les routeurs utilisables. Une implémentation peut fusionner ces structures, mais l’analyste ne doit pas fusionner leurs affirmations.
Une NCE contient notamment l’adresse de couche liaison, le statut routeur ou hôte, d’éventuels paquets en attente et l’état de Neighbor Unreachability Detection. En l’absence de résolution, le nœud crée une entrée INCOMPLETE, envoie un Neighbor Solicitation multicast et garde quelques paquets. Une Neighbor Advertisement sollicitée et valide peut installer l’adresse de liaison, passer l’entrée à REACHABLE et libérer la file.
REACHABLE ne signifie pas « propriétaire vérifié ». Il signifie que le chemin vers la couche IP voisine a été confirmé récemment selon les règles de ND. STALE signifie que l’adresse de liaison est connue sans confirmation récente. DELAY et PROBE organisent la vérification ultérieure. Ces états sont faits pour décider d’émettre, pas pour documenter un bail, une délégation, une authentification d’abonné ou une continuité juridique.
La création à la demande rend cette limite particulièrement visible. Un paquet venu de l’extérieur peut viser une adresse inexistante dans un préfixe sur le lien. Le routeur crée tout de même une entrée INCOMPLETE et lance la résolution. En répétant l’opération sur de nombreuses adresses, un attaquant distant peut consommer mémoire et travail processeur sans jamais être présent sur le lien.
Le cache est donc aussi une capacité de travail bornée. Une ligne INCOMPLETE peut représenter une question sans réponse, non un équipement réel. L’absence d’une ligne peut venir d’une expiration, d’une éviction, d’un redémarrage, d’une limite ou simplement de l’absence de trafic récent. Une photographie de la table ne constitue ni recensement positif, ni preuve d’absence.
La RFC 9898 distingue trois conséquences de ce mécanisme. L’épuisement des NCE menace les ressources du routeur. La résolution du premier paquet introduit délai et perte possible. Enfin, l’imputabilité de l’adresse reste lacunaire : avec SLAAC, l’hôte fabrique ses adresses, et le routeur peut ne les apprendre qu’au moment où il doit acheminer. DHCPv6, sans observation ou enregistrement supplémentaire, ne garantit pas davantage une vue complète au routeur.
Les contre-mesures doivent conserver leur étiquette. La RFC 6583 recommande de filtrer l’espace inutilisé, de limiter le débit de traitement ND et de servir les NCE existantes avant de créer de nouvelles entrées. Ces mesures défendent une ressource. Un plafond de table évite l’effondrement, mais peut aussi empêcher une adresse légitime d’obtenir une entrée. Il ne crée aucun lien d’identité.
La RFC 9131 réduit une autre douleur : l’hôte peut provoquer avant le trafic retour la création d’une entrée STALE sur les routeurs de premier saut. Le premier paquet n’attend plus forcément la résolution. L’amélioration porte sur le temps et la perte ; STALE reste une information de liaison dont l’accessibilité récente n’est pas confirmée.
SAVI et RA-Guard n’ont pas non plus la même juridiction. SAVI lie une adresse à un port de commutateur afin de rejeter une revendication concurrente. RA-Guard limite les ports autorisés à émettre des Router Advertisements. L’enregistrement d’adresses via DHCPv6 ajoute une trace de gestion pour les adresses formées par l’hôte. La RFC 9099 aide à situer ces contrôles. Aucun voyant unique « ND sécurisé » ne devrait dissimuler lequel a réellement observé le fait.
L’analyse la plus structurante de la RFC 9898 porte sur l’isolation. Séparer chaque hôte aux niveaux L3 et L2 réduit à la fois le domaine multicast, le groupe auquel on fait confiance et le besoin de créer une NCE à la demande pour acheminer vers l’hôte. L’isolation L3 attribue un préfixe unique tout en pouvant conserver un support partagé. L’isolation L2 partielle découpe les domaines multicast par des mécanismes de proxy. Les solutions non isolantes traitent un symptôme précis.
Cette échelle n’est pas gratuite. Une isolation forte exige des capacités de commutation et de routage, peut multiplier les interfaces logiques, concentrer le trafic sur le routeur et casser des services multicast entre hôtes. La RFC 8273 note aussi qu’un préfixe stable réattribué au même équipement peut faciliter son suivi. La RFC 9663 montre qu’une délégation DHCPv6 par client peut passer à l’échelle, sans décider à la place de l’opérateur la politique de confidentialité.
Pour attribuer un événement, il faut donc joindre des registres autonomes. D’abord la délégation de préfixe, son autorité et sa période de validité. Ensuite la session d’accès, l’authentification et le circuit ou port. Puis la liaison SAVI ou l’enregistrement DHCPv6. Enfin l’évolution de la NCE, avec interface, état, adresse de liaison, motif et qualité d’horloge. Les observations de paquets et le journal applicatif répondent aux étapes suivantes.
La date fait partie de la preuve. Une table interrogée après coup ne remplace pas la table pendant l’incident. Les adresses temporaires, la randomisation MAC, une reconnexion, un basculement ou une purge peuvent modifier la relation. L’enquête doit exposer les lacunes de conservation plutôt que d’inventer une continuité.
La primauté du code en fonctionnement défendue par Heng Lu ne donne pas tout pouvoir au routeur. Elle lui donne une autorité précise sur l’état qu’il a effectivement exécuté. Le système d’accès répond de la session authentifiée ; le service de délégation, du préfixe attribué ; l’application, de l’opération validée. Une table commode ne devient pas le souverain de ces autres réalités.
Les couches de réalité empêchent qu’un symbole local remplace l’objet entier. La distinction entre contrôle technique et souveraineté pratique empêche qu’une capacité d’acheminement se transforme en titre. Enfin, la spécification initiale minimale permet de garder ND mince et interopérable, tout en laissant aux exploitants le choix de l’isolation, des budgets, de la rétention et du retour arrière.
La bonne question de direction n’est pas « l’adresse figurait-elle dans le cache ? ». C’est : quel système a observé quelle relation, pendant quel intervalle, et quel lien indépendant rattache cet état de transfert à la personne ou à l’organisation tenue pour responsable ?
Sources
- https://www.rfc-editor.org/rfc/rfc9898.html
- https://www.rfc-editor.org/rfc/rfc4861.html
- https://www.rfc-editor.org/rfc/rfc6583.html
- https://www.rfc-editor.org/rfc/rfc9099.html
- https://www.rfc-editor.org/rfc/rfc9131.html
- https://www.rfc-editor.org/rfc/rfc8273.html
- https://www.rfc-editor.org/rfc/rfc9663.html
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/on-data-sovereignty-technical-vs-practical-realities/
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance

