Résumé

  • RFC 9685 étend Neighbor Discovery pour qu’un nœud 6LoWPAN s’abonne à une adresse multicast ou anycast, avec un service de joignabilité demandé séparément.
  • Le routeur conserve une inscription par origine, mais fusionne plusieurs abonnements à la même adresse en une seule annonce et retient la durée de vie active la plus longue.
  • La présence de cette route ne dit donc pas quel auditeur reste inscrit, quelle branche RPL est installée, quel destinataire anycast a été choisi ni quel paquet a été reçu.

Le tableau de bord montrait une seule route multicast. Derrière elle, trois capteurs avaient demandé la même adresse. Le premier venait de renouveler son abonnement pour une heure, le deuxième expirait dans cinq minutes et le troisième avait déjà disparu après une panne d’alimentation. L’annonce amont restait parfaitement légitime grâce à la durée de vie la plus longue. Elle ne disait plus rien de certain sur le troisième capteur.

C’est l’une des propriétés les plus importantes de RFC 9685. Le texte ne se contente pas d’ajouter un indicateur multicast ou anycast à une option. Il organise la transformation d’états individuels en un état de routage agrégé. Cette transformation réduit la signalisation dans un réseau à faible puissance. Elle change aussi le sujet de la preuve.

S’abonner n’est pas posséder l’adresse

RFC 8505 encadre l’enregistrement d’adresses unicast qu’un nœud utilise. RFC 9685 parle d’« abonnement » lorsqu’un nœud écoute une adresse multicast ou accepte une adresse anycast. Plusieurs participants peuvent donc présenter la même adresse sans déclencher la logique d’unicité propre à l’unicast.

Le champ P qualifie cette demande : 1 pour le multicast, 2 pour l’anycast. Le drapeau R répond à une autre question : le nœud demande-t-il au routeur un service de joignabilité, par exemple l’injection de l’adresse dans RPL ? Un champ P valide ne prouve pas que R a été demandé. Une réponse positive à l’abonnement ne prouve pas que le routeur a déjà installé ou diffusé une route.

Si le routeur vérifie le droit du nœud à écouter, l’échange EDAR/EDAC avec le 6LoWPAN Border Router reste nécessaire. La protection ROVR héritée de RFC 8928 lie l’opération à une origine d’enregistrement. Elle ne remplace ni une autorisation métier, ni une politique applicative de groupe, ni une preuve de livraison.

Le reçu minimal doit ainsi conserver l’identité du nœud, l’adresse, P, R, le Transaction ID, le ROVR, la durée demandée, le résultat EDAR/EDAC et le statut retourné par NA(EARO). Le mot « actif » ne peut pas tenir lieu de tous ces champs.

La fusion préserve l’efficacité, pas la visibilité complète

Pour une même adresse, le routeur maintient un état par partie ou par origine. Il peut ensuite fusionner ces abonnements en une seule annonce DAO. Le nombre de routes n’est donc pas le nombre d’auditeurs. Une route peut représenter un nœud ou cinquante ; elle ne fournit pas cette cardinalité.

La durée de vie renforce cette asymétrie. Quand au moins un abonnement demande la joignabilité, le routeur injecte l’adresse selon la durée la plus longue parmi les abonnements actifs. L’expiration d’un auditeur court ne retire pas la route tant qu’un autre auditeur la maintient. À l’inverse, une nouvelle inscription acceptée peut précéder l’injection, car RFC 9685 précise que celle-ci est asynchrone.

Un opérateur doit donc garder deux journaux reliés mais non confondus : le registre par origine et l’historique de l’annonce fusionnée. Le premier répond à « qui était inscrit à cet instant ? ». Le second répond à « quelle adresse le routeur annonçait-il ? ». Aucun ne prouve à lui seul qu’un paquet a parcouru le chemin.

Cette séparation évite une erreur d’audit fréquente. Une route encore présente après la disparition d’un capteur n’est pas forcément un état périmé : elle peut être soutenue par un autre abonnement. Mais elle ne permet pas non plus d’affirmer que le capteur disparu recevait encore le service. Le même symbole vert serait trompeur dans les deux directions.

Deux modes RPL, deux chaînes de transfert

Dans le mode Storing de RPL, les DAO pour l’adresse multicast remontent le long des parents préférés et dessinent un arbre. Les routeurs transmettent ensuite le paquet sous forme de trames MAC unicast individuelles vers les pairs concernés.

Le nouveau mode multicast Non-Storing procède autrement. La racine conserve la connaissance des cibles et effectue une réplication à l’entrée. Elle encapsule des copies vers les 6LR de transit au moyen du routage par source utilisé avec RFC 9008. Un état valide à la racine et un état valide dans chaque routeur intermédiaire ne sont pas le même reçu.

Pour l’anycast, la pluralité des abonnements ne devient pas une réplication. Plusieurs enfants peuvent annoncer la même adresse, mais un paquet donné est transmis vers un seul d’entre eux. Une politique de sélection, un chemin choisi et le résultat obtenu doivent rester observables séparément. Compter les abonnés ne permet pas de déduire le nombre de livraisons.

RFC 6553 et RFC 9008 encadrent des éléments du plan de données RPL. RFC 3810 traite MLDv2, tandis que RFC 7731 décrit MPL pour les réseaux à faible puissance. Ces mécanismes voisins ne rendent pas leurs états interchangeables. Un rapport doit nommer le protocole et le point d’observation réellement utilisés.

La dernière liaison peut encore perdre le paquet

RFC 9685 rappelle que le Direct MAC Broadcast peut être peu fiable et que la diffusion asynchrone oblige un auditeur endormi à rester éveillé. Le texte privilégie donc, lorsque c’est possible, des trames MAC unicast individuelles depuis le 6LR vers chaque 6LN abonné.

Cette préférence améliore la méthode de livraison ; elle ne fabrique pas un accusé de réception applicatif. Le 6LR peut perdre son état après un redémarrage. Il peut transmettre pendant que le nœud dort. Le nœud peut recevoir la trame et rejeter le datagramme. L’application peut recevoir le datagramme sans effectuer l’action attendue.

Le protocole prévoit lui-même la récupération d’état. Un routeur qui pense avoir manqué ou perdu des inscriptions devrait envoyer une demande asynchrone de rafraîchissement. S’il ne le fait pas, le réseau peut attendre le prochain renouvellement périodique, avec des pertes de paquets entre-temps. L’ancien reçu d’abonnement reste authentique, mais il ne décrit plus le présent.

Le choix de portée ajoute une limite différente. RFC 7346 fournit les portées multicast ; RFC 9685 associe notamment Realm-Local au DODAG et Admin-Local à une instance RPL fédérée. Une portée correcte borne l’adresse. Elle ne mesure ni la densité des routeurs compatibles ni la continuité du chemin.

Une migration MOP est une décision d’exploitation

Le nouveau MOP 5 ne s’active pas comme une option sur une instance vivante. RFC 9685 exige de créer une nouvelle instance et d’y migrer les nœuds. Dans un environnement brownfield, l’unicast des équipements anciens peut rester dans une instance tandis que multicast et anycast utilisent une autre.

Cette architecture consomme de la signalisation et de l’état sur des appareils précisément choisis pour leurs contraintes. Elle exige aussi une densité suffisante de 6LR compatibles pour couvrir chaque auditeur. En mode Storing, cette densité doit encore permettre de former un DODAG jusqu’à la racine. Une déclaration de capacité ou une configuration centrale ne prouve pas que cette géométrie existe maintenant.

Le principe de spécification initiale minimale aide à placer la frontière : normaliser l’échange nécessaire, laisser l’adoption et la topologie aux décisions locales. Les couches de réalité empêchent l’annonce fusionnée d’absorber les états individuels. La priorité au code réellement exécuté impose enfin de regarder le transfert et la réception effectifs.

RFC 9685 permet à une feuille qui ne parle pas RPL d’obtenir un service sans recevoir l’autorité d’injecter des messages RPL. La gouvernance devrait imiter cette retenue. L’abonnement atteste une admission bornée. La route atteste une redistribution. Seule l’observation du chemin et du destinataire peut attester la livraison.

Sources