Résumé

  • La RFC 1089 plaçait un message SNMP normal dans les données d’une trame Ethernet portant le type décimal 33100, soit 0x814C. Un répéteur ou concentrateur pouvait être administré sans implémenter IP ni UDP.
  • La RFC 4789 a conservé ce principe en précisant sa géographie : un seul LAN IEEE 802 logique, éventuellement ponté ou constitué en VLAN, et un seul moteur SNMP adressable sur chaque interface.
  • La livraison à une adresse MAC ne désigne pas un principal autorisé. Authentification SNMPv3, contrôle de la vue MIB et vérification de l’effet restent trois opérations différentes après l’arrivée de la trame.

Le point aveugle se trouvait tout près

Les premiers équipements de réseau programmables n’étaient pas forcément des hôtes Internet. Un répéteur pouvait modifier la disponibilité de tout un segment et un concentrateur devenir le passage obligé de dizaines de machines, tout en ne disposant que d’une adresse MAC et d’un peu de logique embarquée. Les mécanismes propriétaires donnaient parfois accès à ces boîtiers ; le gestionnaire IP ordinaire, lui, ne les voyait pas.

La RFC 1089 partit de ce paradoxe. SNMP avait besoin d’adressage et d’un échange bidirectionnel, mais son message ne dépendait pas intrinsèquement d’un en-tête IP ou d’un port UDP. Sur un même Ethernet, la trame pouvait porter le message jusqu’à l’agent sans reconstituer toute la pile Internet dans le boîtier.

Le statut expérimental du texte compte. Il ne proclamait ni une nouvelle architecture mondiale de gestion, ni l’abandon d’UDP/IP. Il testait une couture précise entre la couche MAC et le message SNMP existant. L’information de gestion et les opérations restaient les mêmes ; seul changeait le moyen d’atteindre l’agent.

Cette retenue rend le compromis lisible. Le constructeur économisait une pile. L’exploitant devait connaître la topologie locale qui donnait un sens à l’adresse.

Une valeur de type ouvrait la bonne porte

Xerox attribua le type Ethernet 33100, en hexadécimal 814C, à SNMP. Après l’en-tête de trame venait directement le message SNMP standard. Aucun datagramme IP ne l’enveloppait et aucun port UDP ne séparait le répondant des autres services.

Le type ne décrivait pas un appareil. Il indiquait au récepteur quelle grammaire devait analyser les octets suivants. Le MAC de destination conduisait la trame vers l’interface ; 0x814C conduisait sa charge vers le traitement SNMP. C’était un démultiplexage de protocole, pas une déclaration d’identité.

La philosophie exposée plus tard dans la RFC 1157 explique pourquoi ce raccourci restait cohérent. SNMP cherchait à réduire le nombre et la complexité des fonctions réalisées par l’agent. Chaque message formait un échange indépendant. UDP était le transport spécifié, mais le mécanisme se prêtait à d’autres services.

L’économie de code ne supprimait donc pas les connaissances nécessaires. Quel MAC correspondait au boîtier ? Sur quel VLAN ? Avec quelle version de SNMP, quel moteur, quelle sécurité et quelle vue ? Ce qui disparaissait de l’équipement revenait sous forme d’inventaire et de discipline chez l’opérateur.

Le code 0x814C n’était pas un laissez-passer

Une trame correctement typée prouve seulement qu’elle se présente comme une charge SNMP dans cette encapsulation. Elle ne prouve pas qui l’a émise, qui contrôle son interface source ni si l’auteur a le droit de lire ou de modifier l’objet désigné.

La proximité physique ou logique ne suffit pas davantage. Restreindre le chemin à un LAN réduit le domaine d’exposition selon la topologie en place. Cela ne transforme pas les membres du LAN en mandataires. Une frontière de diffusion et une politique d’accès peuvent coïncider par choix d’exploitation ; elles ne sont pas la même chose dans le protocole.

L’adresse MAC de destination doit elle aussi rester dans son rôle. Elle localise l’interface de transport. Elle ne nomme pas nécessairement un propriétaire, un utilisateur ou une fonction autorisée. La confondre avec un identifiant de principal reviendrait à faire de la possibilité de livrer une lettre le droit de donner un ordre.

La normalisation de 2006 a dessiné une île

La RFC 4789 remplaça la proposition expérimentale par un transport optionnel sur les réseaux IEEE 802. Elle conserva le message sérialisé dans les données de la trame et le même EtherType 0x814C.

Elle étendit aussi la description au-delà d’Ethernet au sens étroit. Quand l’identification du protocole se faisait par LLC, notamment dans le cas IEEE 802.11 cité par le texte, l’encapsulation SNAP devait transporter la valeur de type. Le support changeait, mais la séparation entre charge SNMP et enveloppe de liaison demeurait.

Surtout, la RFC écrivit la limite de portée : un seul LAN IEEE 802 logique, un LAN ponté ou un VLAN. Un pont peut prolonger cette île ; un routeur ne relaie pas la trame comme un datagramme IP. Déplacer un port d’un VLAN à l’autre peut ainsi couper la gestion alors que le boîtier conserve exactement le même MAC.

Le transport répondait donc à un besoin d’équipement simple sur un voisinage contrôlé. Il n’offrait pas la mobilité ni l’accès distant d’une adresse IP routable. Le canal est utile parce qu’il est local ; il devient trompeur dès que cette localité est prise pour une garantie de présence ou de confiance.

Sans port, les rôles partageaient l’interface

La RFC 4789 impose un autre bornage : une interface IEEE 802 ne permet d’adresser qu’un seul moteur SNMP. Générateurs de commandes, récepteurs de notifications, répondants et émetteurs de notifications partagent le même point de transport.

Sur UDP, le couple adresse-port aide à distinguer des services et les ports 161 et 162 structurent les usages courants. Ici, l’enveloppe ne possède que le MAC et le type de protocole. Elle ne fournit pas un second sélecteur standardisé pour plusieurs moteurs derrière la même interface.

Le traitement interne peut toujours distinguer requêtes, réponses et notifications. Ce que la liaison ne peut pas faire, c’est choisir un autre moteur à partir d’un port absent. L’occupation du point de réception devient donc une décision d’architecture du boîtier.

La taille minimale appartient au même contrat. L’entité doit accepter les messages jusqu’à 484 octets et devrait en accepter jusqu’à 1472, les tailles supérieures restant encouragées. La RFC 3417 fixe ces seuils pour les transports SNMP et maintient UDP sur IPv4 comme choix préféré et obligatoire pour les systèmes qui implémentent IPv4. Le chemin IEEE 802 est un complément optionnel, non un successeur universel.

Le domaine de transport empêchait les faux équivalents

Pour que les MIB génériques puissent désigner cet endpoint, la RFC 4789 enregistra snmpIeee802Domain. L’adresse associée est de type MacAddress. Le domaine et l’adresse doivent voyager ensemble : les mêmes octets ne se lisent pas de la même façon dans un domaine UDP, OSI, DDP, IPX ou IEEE 802.

Cette paire évite de fabriquer une fausse universalité. Le MAC ne devient ni une adresse IP sans port, ni un nom d’utilisateur, ni un identifiant mondial du boîtier. Sa portée dépend du LAN logique qui permet de le joindre.

Un journal digne de ce nom conserve donc le VLAN, le chemin de pont, l’interface, le domaine SNMP et le moteur observé. S’il ne garde que le MAC, il perd la frontière qui rendait la livraison possible. S’il ne garde que le principal SNMP, il perd le trajet sur lequel le message a été reçu.

L’autorité commençait après la livraison

La sécurité de la RFC 4789 refuse explicitement l’idée que la liaison suffise. SNMPv1 et SNMPv2c n’y sont pas considérés comme sûrs ; le texte recommande le modèle utilisateur de SNMPv3 et le contrôle d’accès par vues.

La RFC 3414 traite l’authentification, la fraîcheur des messages et, lorsqu’elle est choisie, la confidentialité. La RFC 3415 décide ensuite si un nom de sécurité peut exécuter une opération donnée sur une vue MIB dans un contexte donné.

La chaîne contient donc plusieurs verdicts. La couche MAC livre. Le moteur valide la sécurité. VACM autorise ou refuse l’objet et l’opération. L’instrumentation applique éventuellement la modification. Aucun de ces verdicts ne peut être déduit du seul précédent.

Même une réponse positive a une portée limitée. Elle montre qu’un moteur a traité une requête et formulé un résultat dans son modèle. Pour affirmer qu’un relais a changé, qu’un trafic a emprunté un nouveau chemin ou que l’état a survécu au redémarrage, il faut relire l’objet, observer un compteur indépendant ou obtenir une preuve adaptée à l’effet.

En plaçant SNMP sous IP, la RFC 1089 agrandit l’ensemble des machines administrables et rétrécit le canal qui y mène. Son héritage le plus solide n’est pas le numéro de type. C’est la nécessité de ne jamais confondre transport, principal, permission et résultat.

Sources