Zusammenfassung

  • RFC 1452 verband SNMPv2-Anwendungen über einen Proxy oder zweisprachigen Manager mit SNMPv1-Agenten; eine lokale Datenbank wählte die Zielversion.
  • GetBulk wurde zu GetNext mit genullten Wiederholungsfeldern, während bestimmte alte Fehlerwerte bewusst erhalten blieben.
  • Eine übersetzte Antwort belegte einen abgebildeten Austausch, nicht dieselbe Operation, Informationsmenge, Sicherheit oder Betriebswirkung.

Die Version kam aus einer örtlichen Tabelle

RFC 1452 verlagerte die Übergangslogik aus der Anwendung. Ein SNMPv2-Proxy konnte für einen SNMPv1-Agenten handeln; ein Manager konnte beide Versionen beherrschen.

Vor der Verbindung fragte dieser Manager eine lokale Datenbank ab. Der Anwendungswunsch war noch nicht die ausgeführte Anfrage. Zielzeile, Versionswahl, Abbildungsregel und Downstream-PDU bildeten eine eigene Kette.

Eine veraltete Tabelle musste die einheitliche Oberfläche nicht abschalten. Sie konnte im laufenden Betrieb falsch wählen. Zweisprachigkeit sagte nichts über die Aktualität jeder Zielzuordnung.

Aus vielen Schritten wurde einer

GetRequest, GetNextRequest und SetRequest durften unverändert zu SNMPv1 gelangen. Für GetBulk lautete die Regel anders: non-repeaters und max-repetitions auf null setzen und den Tag in GetNextRequest ändern.

Der alte Agent führte damit nur einen Nachfolgeschritt je Binding aus. Die Anwendung konnte weiterarbeiten, doch ihr gebündelter Umfang war nicht unten ausgeführt worden. RFC 1448 definiert die native SNMPv2-Operation; RFC 1452 dokumentiert ihre bewusste Verengung an der Grenze.

Eine request-id belegt diese Kette nicht. Dafür braucht es Quell-PDU, gewählte Version, Regel, gesendeten PDU und Antwort.

Der Fehler behielt seine Herkunft

noSuchName, badValue und readOnly aus einer SNMPv1-GetResponse sollten nicht verändert werden, obwohl ein nativer SNMPv2-Agent sie nicht erzeugte. Eine präzisere Ausnahme hätte Information erfunden, die der alte Agent nie geliefert hatte.

Die Erhaltung schützte Provenienz, machte die Antwort aber nicht nativ. Bei tooBig entfernte der Proxy die Variable Bindings vor der Weitergabe. So konnte oberhalb einer GetBulk-Anfrage ein Fehlerbild aus der herabgestuften GetNext-Welt erscheinen.

Der Trap wurde neu zusammengesetzt

Beim alten Trap-PDU fügte der Proxy sysUpTime.0 hinzu, berechnete snmpTrapOID.0 aus Generic- oder Enterprise-Feldern und ergänzte ein Enterprise-Binding. Der neue Trap war eine spezifizierte Ableitung.

Auch die Ziele wurden im Mittler bestimmt, mit einer ausdrücklichen Ausnahme bei einer View-Prüfung. Kodierung und Weiterleitung waren nicht getrennt. Kopierte, berechnete und ausgewählte Werte brauchen verschiedene Herkunftsangaben.

Gleicher OID, andere Deklarationsgrammatik

SNMPv1-MIBs durften weiterverwendet werden; ohne echte Bedeutungsänderung sollte ein Objekt nicht veraltet erklärt werden. Dennoch änderte die Konvertierung Imports, Typen, Zugriff, Status, Beschreibungen und Indizes. ACCESS wurde MAX-ACCESS, mandatory wurde current, optional wurde obsolete, Counter und Gauge erhielten eine ausdrückliche Breite.

OID-Kontinuität bewies weder Berechtigung noch identisches Leseverhalten. RFC 1908 zeigte später die Mehrdeutigkeit, wenn Revisionen unter demselben Teilbaum verschiedene verpflichtende Blätter enthielten.

Spätere Regeln legten die Kosten offen

RFC 2576 und BCP RFC 3584 nahmen SNMPv3 hinzu. Mehrere Binding-Ausnahmen konnten in ein noSuchName fallen; Counter64 konnte eine Benachrichtigung unübersetzbar machen; wiederholtes GetNext zum Überspringen solcher Werte konnte teuer werden.

Das sind spätere Grenzen, keine Aussagen über ein konkretes System von 1993. Sie zeigen aber, dass Transparenz Zustand, Ressourcen und Entscheidungen im Mittler benötigt.

RFC 1452 behandelte keine Sicherheitsfragen. Ein durchgelassener PDU bewies weder Identität, Autorisierung und Vertraulichkeit noch die Wirkung einer Änderung.

Quellen