Résumé

  • La RFC 3919 donne aux agents RMON-2 un vocabulaire commun pour des chemins de décodage IPv6 et MPLS, sans prétendre nommer chaque service transporté.
  • Sa limite la plus nette figure dans les entrées MPLS : l’unicast et le multicast sont distingués à l’entrée, mais leurs protocoles fils ne sont « pas identifiables systématiquement ».

La surveillance à distance commence par une question modeste : quels types de paquets une sonde peut-elle reconnaître ? Le répertoire de protocoles RMON-2 répondait par un inventaire des capacités de l’agent. Les compteurs et les tableaux d’hôtes ou de conversations pouvaient ainsi se rattacher à un chemin d’encapsulation nommé. Ce répertoire n’était ni un recensement universel des paquets ni une machine capable d’apprendre un nouveau décodeur parce qu’un gestionnaire ajoutait une ligne.

La RFC 2021 parle d’extensibilité limitée : le logiciel doit déjà connaître la logique de démultiplexage pertinente avant que la configuration puisse prolonger le décodage d’un niveau.

Publiée en octobre 2004 comme RFC informative, la RFC 3919 ajoute des macros d’identification pour IPv6 et MPLS. Son objectif reste circonscrit : améliorer l’interopérabilité des agents RMON-2. Si deux sondes décrivent le même chemin de paquet avec des noms incompatibles, les outils de gestion ne peuvent pas comparer proprement leurs vues par protocole. Le texte précise qu’une implémentation conforme à RMON-2 n’a pas besoin de ces identifiants. C’est un vocabulaire partagé, pas un nouveau test de conformité ni la preuve que toutes les sondes les prennent en charge. (RFC 3919 ; fiche RFC Editor)

Le contraste interne au document est instructif. Pour IPv6, le protocole fils est choisi à partir du champ Protocol sur un octet. Un identifiant peut suivre cette valeur de démultiplexage connue : la RFC nomme ICMPv6 avec le numéro 58 et distingue l’UDP atteint via IPv6 natif de l’UDP encapsulé dans un tunnel IPv6-sur-IPv4. ether2.ip6.udp et ether2.ip.ipip6.udp ne sont pas deux façons d’écrire la même chose. Le chemin garde la trace de l’encapsulation traversée, pas seulement du dernier nom — UDP.

Pour MPLS, la branche s’arrête plus tôt. La RFC nomme mplsu et mplsm, puis les distingue avec les valeurs de couche liaison correspondantes : EtherType 0x8847 pour l’unicast et 0x8848 pour le multicast. Elle donne aussi des encodages pour d’autres liaisons. Ensuite, les deux entrées s’arrêtent : les protocoles fils de MPLS ne sont pas identifiables systématiquement. Cela ne signifie pas que MPLS ne transporte jamais IP ni qu’aucun paquet derrière les labels ne peut être décodé. La limite est plus étroite : ce jeu d’identifiants ne définit pas d’arbre générique et partagé sous les entrées MPLS. (RFC 3032)

Cette limite empêche une étiquette de répertoire de promettre davantage que ce qu’elle décrit. Une sonde peut connaître un cadrage externe ou une entrée MPLS sans fournir un nom stable et commun pour chaque charge utile ou service derrière la pile de labels. Un label de routage ne déclare pas à lui seul une famille de protocoles ; son interprétation dépend d’autres mécanismes et du contexte. La RFC 3919 ne tente pas de déduire ce contexte du label et ne promet pas que deux agents attribueront le même numéro local à une ligne.

La différence entre nom de protocole et index compte autant. La RFC 2895 définit l’encodage de protocolDirID et de ses paramètres. Les tables de comptage utilisent, elles, protocolDirLocalIndex. La RFC 2021 dit que cet entier n’a de sens qu’au sein d’une entité SNMP donnée. C’est une référence locale vers le répertoire de cette sonde, pas un identifiant global que l’on pourrait recopier dans les données d’une autre sonde en supposant qu’il désigne la même chose. L’interopérabilité repose sur les règles descriptives partagées et leur interprétation, non sur une numérotation locale uniforme.

La RFC 3919 révèle donc une frontière importante. Quand IPv6 expose une valeur normalisée pour le protocole suivant, le vocabulaire des identifiants peut décrire un chemin de décodage plus profond. Quand le cadre ne dispose pas d’une correspondance systématique comparable pour les protocoles fils de MPLS, il s’arrête à l’entrée externe. Un inventaire de capacités aide le gestionnaire à poser de meilleures questions ; il ne prouve pas qu’une sonde a vu un paquet, l’a correctement décodé, l’a compté pendant un intervalle donné ou a reconnu le service commercial transporté.

Ces conclusions exigent des observations et des preuves supplémentaires, pas un nom plus long dans une table.

Sources