Zusammenfassung

  • RFC 2011 verlangte für eine konforme SNMPv2-IP-Implementierung ipGroup und icmpGroup; die IESG-Notiz stellte zugleich klar, dass der vier Oktett lange Typ IpAddress nur IPv4 unterstützte.
  • Eine vollständige Tabelle oder ein steigender Zähler belegte Vorgänge innerhalb dieser definierten Objektmenge. Sie belegte weder IPv6-Adressen, -Präfixe, -Routen und -Nachbarn noch die Wirkung einer Konfigurationsänderung.
  • RFC 2465 ergänzte zunächst eine separate IPv6-MIB, RFC 4001 machte Adressfamilie und Adresswert zu einem Paar, und RFC 4293 führte beide Linien in einer versionsunabhängigen IP-MIB zusammen.

Das Messgerät bestand seinen eigenen Test

Die entscheidende Einschränkung steht nicht zwischen den Zeilen. Laut IESG-Notiz zu RFC 2011 unterstützten die damaligen IP-, UDP- und TCP-MIB-Module ausschließlich IPv4, weil IpAddress eine 32-Bit-Adresse als OCTET STRING der Länge vier darstellte. Für eine 128-Bit-IPv6-Adresse gab es in diesem Typ keinen zulässigen Wert.

Das war mehr als ein Darstellungsproblem. In ipAddrTable benannte ipAdEntAddr eine Adresse und war zugleich Tabellenindex; auch die Netzmaske verwendete IpAddress. ipNetToMediaTable identifizierte eine Zuordnung von Netz- zu Medienadresse ebenfalls mit diesem Typ. Die Syntax legte damit fest, welche Zeilen überhaupt existieren und von einem Manager adressiert werden konnten. Eine fehlende IPv6-Zeile war im Modell nicht zwingend ein gemeldeter Fehler. Sie war nicht ausdrückbar.

Ein Agent konnte folglich sämtliche Pflichtobjekte anbieten, autorisierte Lesezugriffe beantworten und eine grüne Konformitätsprüfung bestehen. Falsch wurde erst die Folgerung, diese lokale Aussage bedeute vollständige Sicht auf das IP-Verhalten des Knotens.

Präzise Gruppen, begrenzte Nenner

RFC 2011 hatte einen klar abgegrenzten historischen Auftrag. MIB-II hatte IP- und ICMP-Objekte im SNMPv1-Rahmen definiert; die Verwaltung von IP-Routen war bereits separat aktualisiert worden. Das neue Modul übernahm die verbleibenden Objekte in SNMPv2 und schloss Routenverwaltung ausdrücklich aus.

Die Konformitätserklärung verlangte ipGroup und icmpGroup. Darin lagen Weiterleitungsstatus, Standard-TTL, Eingangs- und Ausgangsstatistiken, Fragmentierung und Wiederzusammensetzung, Adresstabellen, Netz-zu-Medien-Zuordnungen sowie ICMP-Nachrichten und -Fehler. Das ist ein substanzieller Beobachtungsbereich, aber kein Synonym für „das gesamte Netz“.

Auch die Zähler haben verschiedene Grundgesamtheiten. ipInReceives schließt fehlerhaft empfangene Datagramme ein. ipInDiscards zählt verworfene Datagramme ohne Verarbeitungsfehler, jedoch nicht die beim Warten auf Wiederzusammensetzung verworfenen. ipOutNoRoutes betrifft nur Datagramme ohne auffindbare Route. ipReasmFails ist nicht notwendigerweise die Zahl verlorener Fragmente. Ein steigender Wert beweist die Veränderung einer definierten Population; er nennt nicht von selbst Familie, Paket, Pfad, Dienst oder Ursache.

Ähnlich begrenzt ist die Aussage eines Schreibvorgangs. ipForwarding und ipDefaultTTL waren schreibbar, und Netz-zu-Medien-Zeilen konnten erzeugt oder ungültig gemacht werden. Eine erfolgreiche Antwort belegt Annahme im Protokoll. Sie belegt noch nicht Autorisierung, Persistenz, die tatsächlich verwendete IP-Implementierung oder erreichbare Ziele.

IPv6 entstand zunächst neben dem alten Modell

RFC 2465 verlängerte 1998 nicht einfach das Vier-Oktett-Feld. Das Dokument definierte eine eigene IPv6-General-MIB mit sechs Tabellen für Schnittstellen, Schnittstellenstatistiken, Präfixe, Adressen, Routen und Netz-zu-Medien-Zuordnungen. IPv6-Adressen erschienen als Zeichenfolge aus 16 Oktetten. Dafür sollten weder SMIv2 noch konforme SNMP-Implementierungen geändert werden müssen.

Die Repräsentation war gelöst, doch für Dual-Stack-Betrieb entstand eine Verknüpfungsaufgabe: Welche MIB-Familien implementiert ein Agent? Welche Tabellen fragt der Collector tatsächlich ab? Wie werden Schnittstellenidentitäten zusammengeführt? Vermischt eine Anzeige beide Familien oder bevorzugt sie unbemerkt eine? RFC-2011-Konformität blieb wahr, bezeichnete aber nur die IPv4-Seite der Anlage.

RFC 4001 machte die Modellierungsregel wiederverwendbar. InetAddress enthält einen generischen Adresswert nur im Kontext von InetAddressType; in einem Index stehen Typ und Länge vor dem Wert. Neue Objekte sollten nicht unnötig an ein einziges Format gebunden werden. Eine Konformitätserklärung durfte dennoch nur bestimmte Adresstypen verlangen. Die Struktur konnte also mehrere Familien benennen, ohne deren Implementierung automatisch zu garantieren.

Vereinheitlichung bedeutete neue Instrumentierung

RFC 4293 löste 2006 RFC 2011, RFC 2465 und die separate ICMPv6-MIB ab. Die neue MIB sollte unabhängig von der IP-Version sein. System- und Schnittstellenstatistiken erhielten eine Typdimension; Adressobjekte wurden nach Adressart unterschieden; Präfix-, Standardrouter- und Nachbarinformationen bekamen gemeinsame Strukturen.

Der Änderungshinweis beschreibt den Preis offen. ipAddrTable ließ sich nur lose in ipAddressTable überführen; die neue Tabelle war so verschieden, dass neuer Code unter Umständen einfacher war als eine Anpassung. SNMP-Routinen mussten neue Indizes verarbeiten, zusätzliche Zähler brauchten Instrumentierung. Die Norm definierte das Zielmodell. Sie migrierte bei Veröffentlichung weder Agent noch Collector, Archiv, Alarmregel oder Betriebsentscheidung.

In einer Übergangsphase muss der Nachweis deshalb Modulrevision, unterstützte Adresstypen, SNMP-Kontext, Objektinstanzen, Abfrage, Erfassungszeit und die nachgelagerte Entscheidung zusammenhalten. Ohne diese Verknüpfung kann ein grünes Feld eine unsichtbare Adressfamilie verdecken.

Quellen

Grenzen der Evidenz

Die Quellen belegen Dokumentstatus, Objektsyntax, Konformitätsgruppen und die spätere Modelländerung. Sie belegen keine Herstellerfehler, Verbreitungsquote, aktuelle Störung, Überwachungsabdeckung eines benannten Netzes, SLA-Wirkung oder tatsächliches Migrationsdatum.