Résumé

  • Dans RFC 9866, GLOBALLY DOWN est une conclusion de sécurité opérationnelle attachée à la version courante du DODAG, et non un rapport d’autopsie du routeur frontière.
  • Les Sentinelles alimentent des compteurs répliqués probabilistes ; le seuil par défaut de 0,51 porte sur une estimation distribuée, pas sur un scrutin nominatif infaillible.
  • Un reçu de décision doit relier version, observateurs, signaux, sondes, compteurs, paramètres, sécurité, action et reprise, tout en laissant la cause finale explicitement inconnue tant qu’elle n’est pas démontrée.

Le piège commence souvent par une phrase trop courte. Une console affiche GLOBALLY DOWN, puis le compte rendu devient : « la racine a crashé ». Entre les deux, un mot d’état conçu pour protéger le routage a acquis une cause qu’il ne contient pas.

RFC 9866 répond à une difficulté concrète des réseaux de faible puissance et à pertes. Attendre les mécanismes ordinaires de RPL peut prolonger l’utilisation d’une racine devenue inaccessible. RNFD répartit donc l’observation entre des voisins de la racine, les Sentinelles, puis fait circuler et fusionner leurs informations par des Accepteurs. Le réseau peut ainsi décider plus vite que la version courante du graphe ne doit plus porter de trafic montant.

Cette décision reste utile si le routeur est encore alimenté. Des liaisons radio instables, une partition, une asymétrie ou une perturbation locale peuvent rendre la racine inutilisable depuis le graphe sans détruire la machine. Le protocole doit choisir s’il continue à router ; l’enquête doit choisir ce qu’elle peut affirmer sur la cause. Confondre ces deux responsabilités fragilise les deux.

Les états décrivent une base d’action

Le Local Observation of Root State, LORS, passe par UP, SUSPECTED DOWN, LOCALLY DOWN et GLOBALLY DOWN. Une Sentinelle peut soupçonner la racine après des acquittements de couche liaison manquants ou après son retrait de l’ensemble des parents. Elle peut envoyer un DIS ou une requête ICMPv6 Echo. Pour certaines observations directes, la vérification peut être omise.

Il ne suffit donc pas de conserver le dernier état. Il faut savoir comment le nœud y est arrivé. Une suspicion issue d’un échec d’acquittement, une suspicion reçue par le plan de contrôle et une conclusion prise sans sonde supplémentaire n’ont pas la même valeur diagnostique, même si elles conduisent à la même mesure de protection.

Une fois GLOBALLY DOWN atteint, le nœud annonce un Rank infini, n’a plus de parent préféré et cesse le routage vers le haut dans cette version du DODAG. L’état est terminal pour cette version. La reprise passe par une nouvelle version créée par la racine. Ce verrou empêche l’ancien graphe de revenir en service au gré d’un paquet tardif.

Il révèle aussi le périmètre exact de la conclusion : l’objet condamné est une version de graphe. Si la racine vivante observe le consensus, puis lance la version suivante, le mécanisme n’a pas « changé d’avis » sur un crash. Il a fermé un contexte de routage et en a ouvert un autre.

Un compteur probabiliste n’est pas une liste de votants

Les observations positives et négatives sont représentées par des Conflict-Free Replicated Counters fondés sur des tableaux de bits de comptage linéaire. Leur fusion est idempotente, commutative et associative. Ces propriétés permettent à l’information de converger malgré les répétitions et l’ordre variable des messages.

Mais la valeur obtenue demeure une estimation. Elle n’énumère pas une majorité identifiée et authentifiée. Le seuil de consensus vaut 0,51 par défaut ; la croissance de suspicion vaut 0,12 et le seuil de saturation 0,63. Un seuil plus élevé peut diminuer le risque de faux positif, au prix d’une détection plus lente.

La formule exacte dans un rapport devrait donc être sobre : « avec la population de Sentinelles et les paramètres effectifs, l’estimation a franchi le seuil prévu pour cette version ». Écrire « la majorité a prouvé le crash » transforme une règle probabiliste en preuve nominative.

RFC 9866 ne cache pas cette limite. Il admet des faux négatifs et des faux positifs, notamment lorsque les liaisons sont instables. RNFD peut être désactivé sans arrêter RPL. Cette réversibilité n’est cependant pas une autorisation à effacer l’histoire : une désactivation doit garder son auteur, son motif, sa durée, la configuration remplacée et le moyen de détection de substitution.

La sécurité modifie le poids des observations

Une option RNFD falsifiée ou modifiée peut provoquer un faux positif, masquer une défaillance ou accroître le trafic DIO. Lorsque ce risque est pertinent, le RFC recommande les mécanismes de sécurité de RPL. Le mode de sécurité doit donc voyager avec la décision.

Un seuil franchi sous protection cryptographique, le même seuil franchi sans protection et un seuil franchi pendant une anomalie de clés ne sont pas trois occurrences équivalentes. Une racine vivante peut parfois repérer un faux positif grâce à ses propres compteurs si tous ses voisins ne sont pas compromis. « Peut détecter » n’est pas « détectera toujours » ; l’observation locale de la racine doit figurer dans le dossier.

L’allocation IANA du type d’option RPL 0x0E fournit un identifiant commun. Elle ne certifie ni le déploiement, ni le choix des Sentinelles, ni l’exposition des compteurs, ni la bonne exécution de la reprise.

Le reçu qui manque au mot d’état

Un reçu de décision sur la défaillance de la racine peut rester compact, à condition de ne pas mélanger ses champs :

  1. l’instance RPL, l’identité du DODAG, sa version et la période concernée ;
  2. la population de Sentinelles attendue et observée, ainsi que sa règle de sélection ;
  3. les signaux directs et indirects, les sondes effectuées ou omises et leur résultat ;
  4. les compteurs positifs et négatifs, leurs estimations, leur taille, leur saturation et les nœuds de capture ;
  5. le seuil de consensus, la croissance de suspicion, le seuil de saturation, les temporisations et la révision de configuration ;
  6. le mode de sécurité, les anomalies de voisins ou de clés et la vue propre de la racine ;
  7. l’instant de la décision, l’arrêt du routage montant, le comportement de secours, la création de la nouvelle version et le retour du trafic utile ;
  8. enfin, la cause confirmée, les hypothèses concurrentes ou la valeur explicite « inconnue ».

Ce reçu n’est pas une extension de RFC 9866. Il n’oblige pas le réseau à attendre l’enquête avant de se protéger. Il permet au contraire d’agir vite tout en refusant que la vitesse de l’action devienne une certitude rétrospective.

Une réussite limitée vaut mieux qu’une vérité gonflée

RNFD réussit lorsqu’il fournit un minimum commun : observer près de la racine, fusionner sans compter deux fois les mêmes informations, atteindre une règle partagée, fermer la version inutilisable et permettre une reprise par nouvelle version. Les moyens de configuration restent hors du RFC. L’alimentation de secours, les racines virtuelles et l’architecture de continuité restent des choix distincts.

La doctrine opérationnelle est simple : le standard fixe la langue commune ; le code exécuté, la configuration et les observations locales décrivent le résultat réel. Un bon rapport peut donc conclure à la fois que RNFD a correctement retiré l’ancien DODAG et que la cause physique n’est pas établie. La prudence ne diminue pas la décision. Elle empêche seulement la décision de falsifier l’histoire.

Sources