Résumé

  • Un PDR-ACK positif signifie que la racine déclare avoir construit la Track demandée et s’engage sur sa durée négociée. Il ne constate ni passage d’un paquet ni respect d’un objectif applicatif.
  • La preuve exploitable doit relier requête et séquence, installation propre au mode RPL, horloges des segments et de la Track, identité portée par les paquets, observations du chemin et résultat à l’arrivée.

Le journal de contrôle avait tout pour rassurer : une requête corrélée, une réponse positive, un TrackID connu. Mais le compteur de l’entrée n’avait pas bougé et le récepteur n’avait rien enregistré. Dire « Track construite » décrivait fidèlement le protocole. Dire « flux déterministe opérationnel » ajoutait une expérience qui n’avait pas eu lieu.

Publiée en avril 2026 comme Proposed Standard, la RFC 9914 définit le Root-Initiated Routing State pour RPL. Sa fiche RFC Editor indique qu’elle met à jour les RFC 6550, RFC 6553 et RFC 8138. Elle normalise un mécanisme de projection de Track dans un réseau à faible puissance et à pertes ; elle ne documente aucune exploitation nommée ni performance mesurée.

L’entrée peut envoyer un P-DAO-REQ à la racine avec TrackID, extrémités, durée demandée et PDRSequence. La racine reprend cette séquence dans le PDR-ACK. Une réponse positive dit que la Track a été bâtie et promet son maintien pendant la durée convenue. Une réponse négative refuse la demande. Dans les deux cas, le message décrit une décision de contrôle, pas une observation du trafic.

L’emplacement de l’état dépend du mode. En Non-Storing Mode, la racine et les mécanismes de route source ou de tunnel conservent l’information nécessaire. En Storing Mode, la racine adresse un Projected DAO, ou P-DAO, à la sortie ; il remonte vers l’entrée et chaque routeur installe son segment. Le P-DAO-ACK positif revient alors de l’entrée. S’il manque, la racine peut réessayer avec le même TrackID ou détruire la Track. Un voyant unique efface donc la différence entre état central et état distribué.

Les refus sont bornés. L’option Vector Information peut porter une erreur telle que Out of Resources, Predecessor Unreachable ou Unreachable Target. Ce vocabulaire indique pourquoi un nœud n’a pas accepté un segment. Il ne mesure pas la cause radio et n’établit pas, à lui seul, une panne applicative.

La durée elle-même est plurielle. Segment Sequence ordonne les mises à jour et Segment Lifetime fixe la vie d’un segment. Une ancienne séquence est ignorée ; répéter le même tuple ne doit pas changer l’état ; une durée nulle supprime le segment. Les segments se renouvellent de manière asynchrone, indépendamment de la durée globale promise au demandeur. Une Track encore « valide » peut donc être entretenue par des changements internes invisibles.

Cette invisibilité est voulue. Les modifications plus profondes peuvent rester transparentes pour l’entrée. Si la racine ne parvient plus à maintenir le service, elle détruit toute la Track et peut envoyer un PDR-ACK négatif asynchrone avec durée nulle. L’absence de ce message ne prouve pas l’immobilité de chaque saut ; elle borne seulement ce que le protocole a signalé.

Sur le plan de données, la route de Track a priorité sur le DODAG principal. Un paquet déjà engagé ne doit pas revenir à la route ordinaire ; si le prochain voisin de Track est inaccessible, il est abandonné. Le maintien d’une connectivité RPL générale ne démontre donc pas que la Track a livré le paquet.

TrackID et DODAGID peuvent accompagner le paquet via RPL Packet Information, routage source ou encapsulation, selon la RFC 9008 et la RFC 6553. Une capture prouve l’association à un point précis, pas les sauts non observés ni l’acceptation finale. Une reprojection peut aussi faire emprunter des chemins différents aux paquets en vol et aux suivants, produisant gigue ou réordonnancement.

La RFC 8655 fournit l’architecture DetNet des objectifs bornés ; la RFC 9912 expose le cadre RAW, ses chemins de protection, sa réplication et son adaptation. Elles éclairent la finalité des Tracks sans constituer une mesure d’une Track donnée.

Le risque de sécurité vise notamment l’état distribué : un nœud malveillant capable de forger des P-DAO peut provoquer du churn ou épuiser la mémoire des routeurs. La RFC 9914 exige une protection de liaison et s’appuie sur l’analyse de menaces RPL de la RFC 7416. Le registre RPL de l’IANA coordonne codes et statuts ; l’enregistrement ne prouve pas le déploiement sécurisé.

Un dossier défendable réunit P-DAO-REQ et PDRSequence, décision de la racine, durée de Track, mode retenu, P-DAO/P-DAO-ACK le cas échéant, refus par nœud, séquence et durée de segment, TrackID/DODAGID vus dans les paquets, télémétrie des extrémités et sauts, pertes ou réordonnements, puis résultat applicatif. Cette chaîne est une synthèse éditoriale, pas un schéma imposé par la RFC.

Le Minimum Initial Specification de Heng Lu invite à limiter le socle commun et à rendre les choix ultérieurs localement responsables. Running-Code Primacy privilégie l’état exécuté et observé. Reality Layers empêche de confondre requête, acquittement, route, paquet et service. Ce sont des principes éditoriaux déclarés, non des obligations IETF supplémentaires.

La RFC 9914 n’affaiblit pas l’ACK en limitant sa portée. Elle lui donne une signification vérifiable. La confiance apparaît quand l’exploitation laisse ensuite le paquet et le récepteur apporter leurs propres preuves.

Sources