Résumé

  • La RFC 1452 plaçait un proxy ou un gestionnaire bilingue entre une application SNMPv2 et des agents SNMPv1, avec une base locale pour choisir la version cible.
  • GetBulk perdait sa portée groupée : ses paramètres étaient annulés et l’agent ancien recevait un GetNext, tandis que certaines erreurs anciennes restaient intactes.
  • Une réponse traduite attestait un échange mappé, non l’identité de l’opération, des informations, de la sécurité ou du résultat opérationnel.

La décision cachée avant le premier paquet

En 1993, la coexistence n’était pas un état abstrait. Les gestionnaires SNMPv2 devaient encore atteindre des agents SNMPv1. La RFC 1452 proposait soit un proxy, soit une entité de gestion capable de parler les deux versions.

Ce gestionnaire consultait une base locale avant de contacter la cible. L’application exprimait une opération, mais la base décidait quel protocole allait réellement la porter. L’identité de l’agent, la ligne du catalogue, la version choisie et la transformation du PDU devenaient des preuves différentes.

Une base périmée ne faisait pas nécessairement tomber l’interface. Elle pouvait sélectionner la mauvaise langue tout en donnant l’apparence d’un service disponible. La RFC ne transformait pas ce registre local en vérité auto-vérifiée.

La requête groupée fut réduite à un pas

GetRequest, GetNextRequest et SetRequest pouvaient traverser le proxy sans modification. GetBulk n’existait pas en SNMPv1. Pour descendre vers l’ancien agent, le proxy fixait non-repeaters et max-repetitions à zéro, puis remplaçait le type par GetNextRequest.

L’agent accomplissait donc une progression, pas l’ensemble groupé demandé par l’application. Le mécanisme protégeait la continuité du parcours, mais abandonnait la quantité de successeurs que la requête voulait obtenir en un seul échange.

La RFC 1448 définit l’opération SNMPv2 d’origine. Il ne faut pas relire cette histoire comme si le proxy avait ajouté GetBulk à SNMPv1. Il choisissait une opération plus pauvre que l’ancien système savait exécuter.

Un même identifiant de requête ne suffit alors plus à prouver le chemin. Un audit doit garder le PDU initial, la version cible, la règle appliquée, le PDU descendant et sa réponse.

La vieille erreur gardait son accent

Une réponse SNMPv1 pouvait contenir noSuchName, badValue ou readOnly. La RFC 1452 imposait de ne pas les changer, même si une entité SNMPv2 native ne les aurait pas produits. L’application récente recevait une erreur dont la forme signalait l’origine ancienne.

Cette fidélité évitait d’inventer une précision absente. Transformer noSuchName en exception fine par variable aurait attribué à l’agent une distinction qu’il n’avait jamais donnée. La conservation de l’erreur protégeait la provenance, tout en interdisant de qualifier la réponse de sémantiquement native.

Avec tooBig, le proxy retirait les liaisons de variables avant de faire remonter l’échec. Une réponse impossible dans le chemin GetBulk natif pouvait ainsi apparaître après la réduction vers GetNext. Le message amont portait l’histoire du protocole aval.

Le trap fut recomposé

Le Trap-PDU de SNMPv1 ne changeait pas seulement d’enveloppe. Le proxy ajoutait sysUpTime.0, calculait snmpTrapOID.0 à partir du type générique ou de l’entreprise et annexait une liaison d’entreprise. Le nouveau trap contenait des champs dérivés par règle.

La reconstruction était interopérable, mais elle n’était pas originale. Le temps copié, l’OID calculé et la destination choisie demandaient une lignée. La RFC prévoyait même une exception à un contrôle de présence dans la vue lors du choix des destinataires : le traducteur prenait part à la politique d’acheminement.

Le même objet entra dans une autre grammaire

La coexistence traitait également des MIB. Les modules SNMPv1 pouvaient rester utilisables avec SNMPv2, et la conversion ne devait pas déprécier un objet sans véritable changement sémantique. Pourtant, la déclaration changeait sur de nombreux points.

Les imports, types, clauses d’accès, statuts, descriptions et index devaient être ajustés. Counter et Gauge devenaient explicitement 32 bits. ACCESS cédait la place à MAX-ACCESS. mandatory devenait current, optional devenait obsolete. Un objet write-only était déclaré read-write, avec un résultat de lecture dépendant de l’implémentation.

La stabilité de l’OID ne prouvait donc que la continuité du nom. Elle ne prouvait ni une autorisation, ni un résultat de lecture, ni l’identité de toutes les révisions. La RFC 1908 nota plus tard qu’un groupe déduit d’un sous-arbre ancien devenait ambigu si ses révisions n’avaient pas les mêmes feuilles obligatoires. Une réécriture SMIv2 était alors nécessaire.

Les successeurs ont rendu le coût visible

La RFC 2576, puis la BCP RFC 3584, étendirent la coexistence à SNMPv3. Elles montrent ce que l’abstraction pouvait cacher : plusieurs exceptions par liaison se réduisaient à un seul noSuchName, Counter64 pouvait rendre une notification intraduisible, et le proxy répétait parfois GetNext pour sauter des valeurs inexpressibles en SNMPv1. La BCP avertissait que ce travail pouvait coûter cher.

Ces textes ultérieurs bornent l’analyse ; ils ne décrivent pas un appareil réel de 1993. Ils confirment qu’une couche de compatibilité détient de l’état, dépense des ressources et choisit quelles distinctions survivent.

La RFC 1452 déclarait ne pas traiter les questions de sécurité. Traverser le proxy ne prouvait ni authentification, ni autorisation, ni confidentialité. Une réponse de protocole ne démontrait pas davantage qu’un changement demandé avait produit son effet sur le réseau.

Sources