Résumé
- La détection d’inaccessibilité des voisins d’IPv6 conserve une affirmation étroite et datée : une preuve récente a montré que le chemin aller atteignait la couche IP du voisin. L’expiration de cette preuve fait passer
REACHABLEàSTALE, pas le voisin à la panne. - Le RFC 7048 autorise une sonde plus patiente et la conservation de l’adresse de liaison lorsqu’il n’existe aucun voisin de rechange. Cette continuité ne prouve ni identité, ni propriété d’adresse, ni autorisation, ni succès de l’application.
Dans un compte rendu d’incident, une ligne paraît innocente : « le voisin est devenu STALE à 09 h 42 ». Elle raconte pourtant davantage que le protocole. Elle prête à la machine distante un changement d’état que l’observateur n’a pas vu. Peut-être le routeur fonctionne-t-il normalement. Peut-être aucun paquet n’a-t-il été envoyé depuis plusieurs minutes. La seule chose certaine est plus modeste : la dernière confirmation positive n’est plus assez récente.
Neighbor Unreachability Detection, ou NUD, organise cette modestie. Son cache ne tient pas un registre permanent des machines présentes sur le lien. Il conserve une adresse de couche liaison, la fraîcheur de la preuve de joignabilité, l’usage en cours et, si nécessaire, la tentative d’obtenir une preuve nouvelle. Ce sont quatre réalités différentes.
Erik Nordmark apparaît à plusieurs endroits décisifs de cette architecture. Il est l’un des quatre auteurs du RFC 4861, le document Standards Track qui définit Neighbor Discovery pour IPv6. Son nom arrive en premier parmi les deux auteurs du RFC 7048, qui corrige l’impatience de NUD dans certaines situations. Il a également participé au RFC 3756, analyse Informational des modèles de confiance et des menaces. Ces références établissent une contribution documentée à des travaux collectifs de l’IETF. Elles ne lui attribuent ni invention solitaire, ni contrôle des implémentations, ni responsabilité sur le réseau d’un opérateur.
Une preuve à sens unique
Le RFC 4861 donne à la joignabilité un périmètre précis. Un voisin est considéré comme accessible lorsqu’il existe une preuve positive que le chemin aller fonctionne : les paquets envoyés atteignent sa couche IP et y sont correctement traités. S’il s’agit d’un routeur voisin, l’observation doit aussi indiquer qu’il assure son rôle de transfert.
Cette définition ne signifie pas « le service est sain ». Elle ne certifie pas la symétrie du chemin retour, la disponibilité de tous les éléments intermédiaires, l’acceptation d’une requête par l’application ou l’exécution d’une action physique. Elle porte sur un prochain saut observé depuis un nœud donné, pendant une fenêtre de fraîcheur déterminée.
NUD admet deux familles principales de confirmation. La première est une Neighbor Advertisement sollicitée, reçue en réponse à une Neighbor Solicitation. La seconde vient d’un protocole supérieur capable de signaler un progrès réel.
Un nouvel acquittement TCP peut, par exemple, montrer que des données récentes sont parvenues au correspondant. Si le premier saut vers ce correspondant utilise le voisin du cache, l’acquittement soutient l’inférence que ce premier saut a fonctionné. La réception de données nouvelles et non dupliquées peut, elle aussi, indiquer que les acquittements précédents ont progressé dans l’autre sens.
L’inférence s’arrête là. Un ACK TCP ne signe pas l’identité du voisin de couche liaison. Il ne prouve pas que le chemin de retour est identique, que l’utilisateur était autorisé ou que la transaction commerciale a abouti. L’indice d’une couche peut rafraîchir une question étroite de la couche inférieure ; il ne devient pas une attestation universelle.
Cinq états, et non cinq jugements
Les états du RFC 4861 ressemblent à des verdicts lorsqu’ils sont affichés sans contexte. Ils forment en réalité une suite de questions.
INCOMPLETE signifie que la résolution d’adresse n’a pas encore fourni l’adresse de liaison nécessaire. REACHABLE indique qu’une confirmation positive récente existe. Lorsque le temporisateur expire, l’entrée passe à STALE. L’adresse mémorisée demeure disponible ; seule la force de l’affirmation diminue.
Une entrée STALE et inutilisée ne provoque pas de trafic de contrôle. C’est le prochain paquet qui la fait passer à DELAY. Le paquet part encore vers l’adresse de liaison connue. Pendant ce court délai, la pile laisse aux couches supérieures la possibilité de fournir une confirmation. Si elle arrive, le cache revient à REACHABLE sans sollicitation supplémentaire.
Sans preuve nouvelle, l’entrée passe à PROBE. Le nœud envoie des Neighbor Solicitations unicast vers l’adresse mémorisée. Une Neighbor Advertisement sollicitée et valide peut rétablir REACHABLE. Dans l’algorithme de base, l’épuisement du nombre de sondes entraîne la suppression de l’entrée et relance le choix du prochain saut ou la résolution d’adresse.
La chronologie révèle pourquoi un champ unique last_seen est insuffisant. Il faut distinguer la date de la confirmation, sa source, la dernière utilisation, le début du délai, chaque sonde et l’existence d’une solution de rechange. Une pastille verte peut cacher une preuve trop ancienne ; une pastille orange peut cacher un chemin qui transporte encore correctement les paquets.
Entendre une annonce ne prouve pas être entendu
Une annonce non sollicitée peut contenir une information utile. Elle peut avertir d’un changement d’adresse de liaison. Une Router Advertisement montre qu’un message est allé du voisin vers le récepteur. Mais ces événements n’établissent pas que le chemin dans le sens opposé fonctionne.
Le RFC 4861 exige donc que les Router Advertisements et les Neighbor Advertisements dont le drapeau Solicited est à zéro ne servent pas de confirmation de joignabilité. La règle protège une asymétrie essentielle : entendre quelqu’un parler ne montre pas qu’il vous entend. Connaître son emplacement ne montre pas que votre courrier lui parvient.
Une plateforme de supervision qui rafraîchit last_reachable_at à chaque annonce efface cette distinction. Une annonce spontanée peut alors maintenir l’état « sain » sans répondre à la question du chemin aller. Le reçu utile conserve le sens du message, le drapeau Solicited, la cible, l’interface, l’adresse de liaison avant et après, ainsi que la transition effectivement autorisée.
« Information reçue sur le voisin » et « accessibilité aller confirmée » doivent rester deux événements. Leur proximité temporelle ne permet pas de les fusionner.
Quand l’échec rapide ne trouve aucune sortie
Le RFC 7048 part d’un problème concret. Le comportement par défaut envoie trois sondes espacées d’environ une seconde. Avec un autre routeur par défaut réellement disponible, cette rapidité est raisonnable : abandonner le prochain saut silencieux permet de choisir un chemin qui a une chance de réussir.
Sans alternative, le même rythme peut aggraver une perturbation transitoire. Un lien radio momentanément faible, un équipement en veille ou une reprise lente peut dépasser les trois secondes. Supprimer l’entrée provoque alors une nouvelle résolution, souvent en multicast, tout en jetant la seule adresse de liaison plausible. Le système ne bascule vers rien ; il perd simplement de l’information et ajoute du trafic.
Pour ce cas, le RFC 7048 décrit un état conceptuel UNREACHABLE. L’entrée et son adresse de liaison peuvent être conservées. Les paquets peuvent continuer à être envoyés. Les sollicitations se poursuivent avec un recul exponentiel et doivent finir par passer de l’unicast au multicast, faute de quoi un changement d’adresse de liaison resterait invisible.
Le terme UNREACHABLE ne signifie donc pas « plus aucun paquet n’est transmis » ni « le service est définitivement hors ligne ». Il signifie que le mécanisme de sonde n’a pas obtenu la confirmation attendue. Si une véritable alternative apparaît, l’entrée non confirmée ne doit pas empêcher sa sélection. Une entrée créée par Redirect peut même être supprimée plutôt que maintenue.
La patience n’est pas toujours plus sûre. Elle protège la continuité lorsqu’il n’existe aucun autre chemin. Elle peut retarder une bonne bascule lorsqu’un autre voisin fonctionne. La politique correcte dépend de l’ensemble des alternatives au moment de la décision, non du nom imprimé sur l’état.
La sécurité ne tient pas dans le mot REACHABLE
Le RFC 3756 montre les limites du modèle de confiance. Sur un lien où les messages Neighbor Discovery peuvent être forgés, une fausse Neighbor Advertisement sollicitée peut fournir une confirmation trompeuse. Les paquets peuvent être dirigés vers une adresse de liaison malveillante ou inexistante. L’automate peut appliquer correctement ses règles à une entrée fabriquée par l’adversaire.
La conclusion n’est pas que le cache ne vaut rien. Elle est que sa valeur doit être nommée correctement. REACHABLE n’est pas synonyme d’authentifié. L’adresse IPv6 n’identifie pas le propriétaire du matériel, l’organisation responsable, le logiciel actif ou le droit d’exécuter une opération. Les contrôles cryptographiques, l’admission sur le lien, l’inventaire et l’autorisation applicative produisent d’autres preuves, avec d’autres auteurs et d’autres délais d’expiration.
Un journal d’incident robuste rapproche ces preuves sans les confondre. Il conserve l’interface, le prochain saut, l’adresse de liaison, la source de confirmation, les sondes, les alternatives connues, le contexte de sécurité et la version logicielle. Il ajoute ensuite, séparément, la décision d’autorisation et le reçu de résultat fourni par l’application ou l’équipement.
Attribuer la norme sans lui prêter un opérateur
Le profil IETF consulté le 30 août 2026 recense 25 RFC pour Erik Nordmark et le présente comme relecteur actif de l’Internet of Things Directorate. Ces données peuvent évoluer. Les pages de titre des RFC offrent une attribution plus stable : Thomas Narten, Nordmark, William Simpson et Hesham Soliman pour le RFC 4861 ; Nordmark et Igor Gashinsky pour le RFC 7048 ; Pekka Nikander, éditeur, James Kempf et Nordmark pour le RFC 3756.
Le statut des documents compte également. Les RFC 4861 et 7048 relèvent du Standards Track. Le RFC 3756 est Informational. Aucun de ces faits ne prouve que tous les systèmes respectent la norme, que les temporisateurs d’un produit sont correctement configurés ou que Nordmark décide de la politique d’un réseau particulier.
Le code en fonctionnement fournit la preuve locale : transitions réellement mises en œuvre, indices des couches supérieures acceptés, logique de sélection des alternatives, stratégie de recul et qualité du journal. La norme offre un point public de coordination et une base de comparaison. Elle ne remplace pas l’observation.
La leçon institutionnelle tient dans la retenue de l’automate. Il conserve une adresse utile tout en abaissant la confiance. Il attend que le trafic rende la question pertinente avant de sonder. Il adapte la défaillance à l’existence d’une alternative. Surtout, il ne transforme pas une indication de transfert en identité ou en pouvoir.
Ce n’est pas le voisin qui a vieilli. C’est la preuve. Un réseau responsable commence par garder cette phrase exacte.
Sources
- https://www.rfc-editor.org/rfc/rfc4861.html
- https://www.rfc-editor.org/rfc/rfc7048.html
- https://www.rfc-editor.org/rfc/rfc3756.html
- https://datatracker.ietf.org/person/Erik%20Nordmark
- https://www.ietf.org/lib/dt/media/photo/erik-nordmark-PAKeJ.jpg
- 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/
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
