Résumé

  • RFC 3019 décrivait deux tables SNMP pour MLD, mais plusieurs objets étaient aussi des commandes : activer ou désactiver MLD, créer ou détruire une entrée, déclarer l’hôte membre, régler les délais ou choisir une interface proxy.
  • La ligne retournée constatait donc l’état représenté par l’agent. Elle n’attestait pas à elle seule qu’un auditeur distant était encore présent, que le trafic était relayé ou qu’une application l’avait reçu.

Imaginons un opérateur qui interroge un routeur au milieu d’un incident multicast. La table contient le groupe attendu. Une adresse IPv6 apparaît dans la colonne du dernier rapporteur. Le délai d’expiration n’est pas nul.

La tentation est immédiate : l’auditeur existe, il a parlé, le réseau devrait livrer.

RFC 3019 ne permettait aucune de ces trois conclusions sous cette forme. Son MIB avait une ambition différente : rendre observable et administrable l’état MLD d’un hôte ou d’un routeur. Or un objet administrable peut être à la fois la trace d’un événement et le résultat d’une décision locale.

Le document, publié en janvier 2001, mérite d’être lu comme une leçon de provenance. Il donnait des noms précis aux lignes, compteurs et délais. Il donnait aussi au gestionnaire le pouvoir de fabriquer, modifier ou supprimer une partie de ce qu’il relirait ensuite.

Une vue simple sur un état qui ne l’était pas

Le module définissait deux tables. La première alignait les interfaces sur lesquelles MLD était activé. La seconde alignait les couples groupe multicast IPv6–interface pour lesquels l’agent conservait une appartenance.

Dans la table d’interface, on trouvait la fréquence des Queries, le délai maximal de réponse annoncé, la version de MLD, l’adresse du Querier, le nombre cumulé d’ajouts, le nombre actuel de groupes, la variable de robustesse, le délai de dernière écoute, l’interface proxy et deux temporisateurs liés au Querier.

Ces objets ne racontaient pas tous le même temps. mldInterfaceJoins comptait les insertions passées. mldInterfaceGroups mesurait le nombre actuel d’entrées. Le temps restant avant disparition d’un autre Querier décrivait une hypothèse future fondée sur l’état présent. L’adresse du Querier désignait le gagnant actuel d’une élection souple.

Dans la table de cache, mldCacheSelf indiquait l’appartenance du système local. mldCacheLastReporter donnait la source du dernier Membership Report reçu. Les temps de création et d’expiration renseignaient le cycle de vie. mldCacheStatus ouvrait le contrôle de la ligne.

Une console pouvait juxtaposer ces valeurs. Elle ne devait pas les fondre en une phrase plus forte que chacune d’elles.

Le dernier rapporteur n’était pas un registre de présence

La définition de mldCacheLastReporter était délibérément étroite : l’adresse source du dernier rapport reçu pour le groupe sur l’interface. Si aucun rapport n’avait été reçu, la valeur était 0::0.

Le mot « dernier » décrit un ordre d’observation. Il ne signifie ni « seul », ni « toujours présent », ni « bénéficiaire actuel du trafic ».

MLD, défini par RFC 2710, cherchait à savoir si au moins un auditeur existait sur le lien. Les hôtes pouvaient supprimer leurs rapports redondants après avoir entendu la réponse d’un autre. Une même ligne pouvait donc représenter plusieurs auditeurs sans les nommer. Le rapporteur le plus récent pouvait partir pendant que l’état survivait grâce à un autre. Le système local pouvait lui-même maintenir l’entrée.

mldCacheExpiryTime n’apportait pas une preuve d’activité. Il indiquait le minimum de temps restant avant vieillissement. Zéro pouvait signifier que la ligne ne subsistait que parce que mldCacheSelf était vrai et disparaîtrait dès que le routeur quitterait le groupe. Le RFC précisait même qu’une implémentation pouvait traiter ses propres rapports comme ceux des autres hôtes, de sorte que zéro n’était pas obligatoire.

Pour établir une présence distante, il fallait donc retrouver le rapport, sa date, l’état local, l’époque des temporisateurs et les éventuels changements d’agent. Pour établir la réception, il fallait encore observer le chemin de données et le récepteur.

Le gestionnaire pouvait écrire l’entrée qu’il allait consulter

mldCacheStatus était read-create. Le gestionnaire pouvait créer une nouvelle ligne ou détruire une ligne existante. Le groupe de conformité de base disait explicitement que cette collection d’objets devait permettre la création et la suppression d’entrées de cache par le manager.

mldCacheSelf, lui aussi read-create, déclarait si le système local était membre et prenait par défaut la valeur vraie.

La provenance d’une ligne devenait alors une question de premier ordre. Elle pouvait résulter d’un Membership Report reçu sur le lien. Elle pouvait représenter l’adhésion locale. Elle pouvait être créée par une opération de gestion. Elle pouvait persister à travers un temporisateur sans nouveau rapport.

Le contenu courant n’indiquait pas nécessairement la branche causale.

Supposons qu’un outil crée une ligne afin qu’un routeur participe à un groupe de mesure, puis relise le MIB. La réponse peut confirmer que l’agent a accepté et représente l’état demandé. Elle ne constitue pas une observation indépendante d’un hôte distant. L’écriture et la vérification traversent la même surface.

Ce n’est pas une faiblesse propre à SNMP. Toute base de contrôle relue comme télémétrie rencontre le même risque. Plus elle est commode, plus son utilisateur doit conserver l’origine de chaque fait.

Une ligne d’interface pouvait arrêter MLD

mldInterfaceStatus ne se contentait pas de décrire l’existence d’une ligne. L’activer mettait MLD en service sur l’interface ; la détruire le désactivait.

Le gestionnaire pouvait aussi régler l’intervalle général des Queries, le délai maximal de réponse, la robustesse attendue face aux pertes et l’intervalle employé pour vérifier la disparition du dernier membre. Réduire ce dernier paramètre diminuait la latence de départ, mais changeait aussi la fenêtre de preuve disponible après un message de départ.

Avec mldInterfaceProxyIfIndex, l’agent pouvait transformer une appartenance apprise sur une interface en un Report émis sur une autre. La valeur zéro signifiait qu’aucun proxy n’était utilisé. Une valeur non nulle étendait la conséquence d’une ligne au-delà de son interface d’origine.

Ainsi, un SET accepté pouvait modifier le comportement de découverte et la représentation amont. Il ne prouvait pas que la prochaine Query était partie, que le voisin l’avait reçue, que le routage multicast avait installé la bonne réplication ou que l’application avait consommé un paquet.

La réponse SNMP était un reçu d’agent, pas un reçu de bout en bout.

La permission du schéma n’imposait pas l’écriture partout

Un autre piège consistait à prendre read-create pour un inventaire des capacités déployées.

Les déclarations de conformité autorisaient un accès minimal en lecture seule à mldInterfaceStatus pour les hôtes et les routeurs. L’écriture n’était pas exigée. Le module décrivait donc un plafond de capacité et des groupes de conformité ; il ne certifiait pas que chaque agent exposait chaque SET.

Il fallait séparer la définition de l’objet, la capacité de l’implémentation, la vue VACM du principal et le résultat de l’opération. Un seul de ces niveaux pouvait être lu directement dans la ligne MAX-ACCESS.

RFC 2579 précisait le cycle générique de RowStatus, mais ne transformait pas une action demandée en effet de données. Une ligne active restait un état de gestion. La persistance après redémarrage, la synchronisation avec MLD et l’effet multicast demandaient d’autres observations.

Lire exposait ; écrire pouvait interrompre

La section sécurité de RFC 3019 distinguait clairement lecture et écriture.

Les objets lisibles pouvaient révéler des informations sur des sessions multicast. mldCacheSelf et mldCacheLastReporter pouvaient aider à identifier des machines associées à une adresse de groupe. Le texte qualifiait l’accès non autorisé en lecture de relativement anodin ; cette appréciation historique ne doit pas devenir une règle générale de confidentialité.

Les objets modifiables étaient plus dangereux. Un accès non autorisé pouvait produire un déni de service. Activer les opérations SET dans un environnement non sécurisé risquait d’altérer les opérations réseau.

Le document disait que SNMPv1, à lui seul, constituait un tel environnement. Même si le réseau était protégé par IPsec, cette protection ne décidait pas qui avait le droit de lire ou modifier les objets. RFC 3019 recommandait le modèle utilisateur de RFC 2574 et le contrôle par vues de RFC 2575.

On retrouve une chaîne de reçus distincts : canal protégé, principal authentifié, vue autorisée, SET accepté, état protocolaire obtenu, effet de forwarding observé, réception applicative. Sauter un maillon revient à attribuer à la couche précédente une autorité qu’elle ne possède pas.

Le successeur élargit la carte, pas les preuves passées

RFC 5519 a rendu RFC 3019 obsolète en 2009. Il a réuni les MIB d’IGMP et de MLD, séparé plus nettement les tables d’hôtes et de routeurs et ajouté l’état de filtrage par source pour IGMPv3 et MLDv2.

Cette évolution montre ce que le premier modèle ne pouvait pas exprimer. Elle ne permet pas de relire les anciennes lignes comme si elles avaient toujours porté la liste des sources et la séparation ultérieure.

Elle ne prouve pas davantage qu’un équipement particulier ait implémenté l’un ou l’autre module. Les RFC établissent la conception et la filiation. Ils n’établissent ni déploiement, ni incident, ni conformité de produit.

La doctrine de Lu Heng sert ici de grille déclarée. Running-Code Primacy sépare le module publié de l’agent réellement exécuté. Reality Layers empêche la ligne, le rapport, le forwarding et la réception de se prêter mutuellement leur force. Minimum Initial Specification rappelle qu’un premier module peut être utile sans anticiper toutes les distinctions de son successeur.

Lu Heng n’a ni rédigé ni approuvé RFC 3019.

Le MIB n’était pas un mensonge. Il répondait exactement à une question plus petite : quel état cet agent représente-t-il et permet-il de gérer maintenant ?

Sources