Zusammenfassung

  • RFC 1089 transportierte eine standardmäßige SNMP-Nachricht direkt im Datenfeld eines Ethernet-Frames mit Typ 33100, hexadezimal 0x814C. Repeater und Wiring Concentrators brauchten dafür weder IP noch UDP.
  • RFC 4789 behielt die Kennung bei und zog die Betriebsgrenze nach: Das optionale Mapping reicht nur über ein logisches IEEE-802-LAN, ein gebridgtes LAN oder ein VLAN; pro Interface lässt sich genau eine SNMP-Engine adressieren.
  • MAC-Adresse und EtherType bestimmen Zustellung und Parser. Authentisierter Principal, erlaubte MIB-View und nachweisbare Gerätewirkung bleiben getrennte Entscheidungen nach dem Eintreffen des Frames.

Das wichtigste Gerät war kein Internet-Host

Ein Repeater musste keine Datagramme routen, um ein Netzsegment lahmzulegen. Ein Wiring Concentrator konnte zum gemeinsamen physischen Abhängigkeitspunkt vieler Hosts werden. Gegen Ende der 1980er Jahre besaßen solche Geräte zunehmend programmierbare Logik und eine MAC-Adresse, aber nicht zwingend Protokolle oberhalb der MAC-Teilschicht.

Für eine IP-basierte Managementstation entstand damit eine Lücke. Das Gerät befand sich am selben Medium und war dennoch nur über proprietäre Verfahren sichtbar. Ihm allein für wenige Managementnachrichten Adressierung, Routing, Fragmentierung und UDP mitzugeben, widersprach dem Wunsch nach einem kleinen Agenten.

RFC 1089 behandelte die fehlende IP-Schicht als Transportentscheidung. SNMP brauchte bidirektionalen Fluss und Adressierbarkeit, aber nicht notwendig einen IP-Header. Innerhalb desselben Ethernet konnte der MAC-Layer beides liefern.

Das Memo war experimentell. Es definierte weder eine neue MIB noch besondere Befehle für diese Geräte. Die SNMP-Nachricht blieb unverändert; nur ihr unterer Umschlag wechselte. Gerade diese enge Änderung macht sichtbar, welche Aufgaben sie löste und welche nicht.

Hinter dem Ethernet-Header folgte bereits SNMP

Für SNMP wurde Ethernet Type 33100 beziehungsweise 814C reserviert. Das Datenfeld enthielt unmittelbar die standardisierte SNMP-Nachricht. Dazwischen lagen kein IPv4-Paket und kein UDP-Port.

Die Ziel-MAC wählte das Interface. Der EtherType wählte den Protokollhandler, der die folgenden Bytes verstehen sollte. Das Gerät musste ASN.1/BER und die SNMP-Operationen verarbeiten, für diesen Pfad aber keine IP-Routen oder UDP-Endpunkte führen.

RFC 1157 beschreibt die passende Entwurfsphilosophie. SNMP sollte Zahl und Komplexität der Funktionen im Agenten minimieren. Jede Nachricht war eine eigenständig dargestellte Einheit; UDP war spezifiziert, doch die Mechanismen galten als für unterschiedliche Transportdienste geeignet.

Die eingesparte Komplexität verschwand nicht vollständig. Der Betreiber musste das logische LAN, die MAC, den Bridge-Pfad, die SNMP-Engine und deren Sicherheit kennen. Was im Gerät nicht als Netzstack vorhanden war, musste im Inventar als präziser Kontext vorhanden sein.

0x814C war ein Format, keine Vollmacht

Der Typwert beantwortete eine Parsing-Frage: Welches Protokoll soll die Nutzdaten erhalten? Er verhinderte, dass eine SNMP-Nachricht als IP-Datagramm oder anderes Link-Protokoll gelesen wurde.

Er sagte nichts darüber, wer den Frame gesendet hatte. Auch eine Quell-MAC ist kein Personen-, Unternehmens- oder Berechtigungsnachweis. Die erfolgreiche Zustellung zeigt, dass die aktuelle logische Topologie einen Weg zum Interface bot. Sie zeigt nicht, dass der Absender ein Objekt lesen oder mit SET verändern durfte.

Die lokale Reichweite verführt zu einer Abkürzung. Wer im selben VLAN ist, wirkt vertraut. Doch Topologie und Autorisierung haben verschiedene Gegenstände. VLAN und Bridge bestimmen, wohin der Frame gelangen kann. Das Sicherheitsmodell bestimmt, als welcher Principal die Nachricht gilt. Die Zugriffskontrolle bestimmt, welche MIB-Objekte dieser Principal benutzen darf.

Eine Organisation kann Layer-2-Grenzen als zusätzliche Schranke einsetzen. Der Standard macht aus Nähe jedoch keine Identität. Eine Transportkoordinate darf nicht nachträglich zur Mandatskette erklärt werden.

Der Nachfolger zeichnete die Reichweiteninsel

2006 löste RFC 4789 RFC 1089 ab und standardisierte ein optionales Mapping für IEEE-802-Netze. Die serialisierte SNMP-Nachricht im MAC-Frame und EtherType 0x814C blieben erhalten.

Für LANs, die Protokolle mit LLC kennzeichnen, schreibt das Dokument SNAP-Kapselung vor. So ließ sich dieselbe Typkennung auch auf anderen 802-Medien, einschließlich des erwähnten 802.11-Falls, übertragen.

Entscheidend war die explizite Begrenzung. Direktes SNMP über IEEE 802 bleibt in einem logischen IEEE-802-LAN, einem gebridgten LAN oder einem VLAN. Eine Bridge kann dieselbe Link-Insel verlängern. Ein Router trägt den Frame nicht wie ein IP-Datagramm durch beliebige Netze.

Wechselt ein Switch-Port das VLAN, kann die Managementverbindung verschwinden, obwohl die MAC unverändert bleibt. Umgekehrt erweitert eine neue Bridge-Mitgliedschaft den möglichen Zugang. Die Erreichbarkeit ist deshalb Zustand der Topologie, nicht bloß Merkmal des Geräts.

Die Grenze ist Preis und Voraussetzung der Vereinfachung. Ein fernes Management braucht eine Station in der richtigen Domäne, einen kontrollierten Proxy oder das gewöhnliche IP-Mapping. RFC 4789 versprach keine versteckte Routingfunktion.

Ohne Port gab es nur eine Engine-Adresse

Auf einem IEEE-802-Netzinterface kann nach RFC 4789 nur eine SNMP-Engine adressiert werden. Command Generators und Notification Receivers teilen den Transportendpunkt mit Command Responders und Notification Originators.

Bei UDP bildet die Kombination aus IP-Adresse und Port einen Endpunkt; die üblichen Ports 161 und 162 helfen bei der Rollentrennung. Das direkte Mapping besitzt MAC und Protokolltyp, aber keinen Transportport. Die SNMP-Nachricht unterscheidet ihre Funktion nach dem Empfang, der Link-Umschlag kann jedoch nicht zwischen mehreren Engines hinter demselben Interface wählen.

Intern darf eine Implementierung komplex sein. Der Standard stellt ihr nur keinen zweiten externen Selektor bereit. Welche Engine die Öffnung belegt, ist eine Architektur- und Konfigurationsentscheidung.

Auch die Mindestgröße wurde festgelegt. Nachrichten bis einschließlich 484 Oktett müssen, bis 1472 Oktett sollen empfangen werden; größere Werte sind erwünscht. RFC 3417 verwendet dieselben Grenzen für SNMP-Transport-Mappings und bevorzugt UDP über IPv4. Systeme mit IPv4 müssen dieses Mapping unterstützen. IEEE 802 war Ergänzung, nicht Ersatz.

Die Transportdomäne hielt die Adresse ehrlich

Damit generische MIB-Module den Endpunkt referenzieren konnten, registrierte RFC 4789 snmpIeee802Domain. Die zugehörige Transportadresse hat den Typ MacAddress.

Erst das Paar gibt den Bytes Bedeutung. Im UDP/IPv4-Domain gehören IP und Port zur Adresse; in der IEEE-802-Domain ist es eine MAC. Keine davon ist automatisch Benutzername, juristische Identität oder dauerhafter Gerätebeweis nach einem Austausch.

Ein Betriebsprotokoll braucht daher Domain, VLAN, Bridge-Pfad, physisches Interface, Engine und Epoche neben der MAC. Fehlt das VLAN, fehlt die Ursache der Erreichbarkeit. Fehlt die Engine, fehlt der Adressat der SNMP-Verarbeitung.

Sicherheit begann jenseits des Empfangspuffers

RFC 4789 betrachtet SNMPv1- und SNMPv2c-Nachrichten nicht als sicher und empfiehlt das Sicherheits- und Zugriffskontrollsystem von SNMPv3. Schon diese Warnung zeigt, dass Layer-2-Nachbarschaft keine Authentisierung war.

RFC 3414 definiert USM für Nachrichtenauthentizität, Zeitschutz und optionale Vertraulichkeit. RFC 3415 definiert VACM: Darf ein Security Name in diesem Kontext mit dieser Operation auf die betreffende MIB-View zugreifen?

Die Verarbeitung ergibt daher mehrere begrenzte Belege. Der Frame erreichte das Interface. Die Engine akzeptierte den Schutz. VACM erlaubte Objekt und Operation. Der Agent lieferte einen Status. Eine spätere, passende Beobachtung zeigt schließlich, ob das Gerät tatsächlich den erwarteten Zustand annahm.

Eine erfolgreiche Antwort ersetzt den letzten Nachweis nicht. Sie beweist allein weder weitergeleiteten Verkehr noch einen geschalteten Ausgang oder dauerhafte Konfiguration nach einem Neustart. Dafür braucht es erneutes Lesen, unabhängige Zähler oder physische Signale.

RFC 1089s historische Leistung liegt deshalb nicht nur in einer Typnummer. Die Spezifikation vergrößerte durch weniger Protokollschichten die Menge verwaltbarer Geräte, ohne Zustellung, Identität, Erlaubnis und Wirkung fälschlich zusammenzulegen.

Quellen