Zusammenfassung

  • Die IEEE Registration Authority vergibt EtherTypes und LSAPs und hat IANA die OUI 00-00-5E zugeteilt; IANA verwaltet nur die darunter definierten Teilräume.
  • Eine Zwei-Oktett-Protokollnummer hinter der IANA-OUI ist kein EtherType. Träger, OUI und innerer Wert bilden gemeinsam den Beleg.
  • RFC 9542 trennt Feldlage, Namespace, maßgebliches Register, Freigabeverfahren, Spezifikation, Implementierung und Ergebnis.

Der Fehler wirkte amtlich. Er hatte eine Hexzahl, einen Protokollnamen und eine IANA-URL. Trotzdem beschrieb er nicht die Vergabe, die im Paket stand.

88-B7-00-00-5E-00-42 enthält drei verschiedene Entscheidungen. IEEE RA hat 0x88B7 als OUI Extended EtherType vergeben. Dieselbe Stelle hat IANA die OUI 00-00-5E zugeteilt. Innerhalb dieses Bereichs hat IANA 0x0042 für Dokumentationsbeispiele reserviert. Wer nur die letzten zwei Oktette speichert, entfernt den Eigentümer des Unterraums.

RFC 9542 erschien im April 2024 als BCP 141 und löste RFC 7042 ab. Das Dokument schuf kein neues IANA-Register und änderte keine bestehende Zuteilung. Es macht vielmehr sichtbar, dass Delegation präzise bleibt: IANA darf unter einer IEEE-OUI koordinieren, ohne dadurch zur Vergabestelle für EtherTypes zu werden.

Erst die Form, dann die Bezeichnung

Ein EtherType ist ein 16-Bit-Wert ab 0x0600. Im einfachen Ethernet-II-Frame steht er nach Ziel- und Quelladresse, gegebenenfalls nach zusätzlichen Tags. IEEE RA weist EtherTypes zu.

LLC arbeitet anders. Auf ein Längenfeld folgen zwei acht Bit große LSAPs. SNAP setzt anschließend AA-AA-03, eine drei Oktette lange OUI und eine Zwei-Oktett-Protokollnummer. Für diese letzte Nummer ist der OUI-Inhaber zuständig.

Der EtherType 0x88B7 trägt ebenfalls OUI-basierte Kennungen. In 88-B7-00-00-5E-qq-qq ist 0x88B7 die IEEE-Zuteilung, während qq-qq im IANA-Unterraum liegt. Gleiche Feldbreite und räumliche Nähe schaffen keine gemeinsame Vergabestelle.

SNAP kennt zudem die Null-OUI. Hinter 00-00-00 kann ein beliebiger EtherType stehen; dort sind die letzten zwei Oktette tatsächlich der EtherType. Hinter 00-00-5E sind sie eine IANA-Protokollnummer. Ein Schema, das nur den Suffix behält, kann diese Fälle später nicht mehr unterscheiden.

Der Webhost ist nicht automatisch der Registerinhaber

„IANA OUI Ethernet Numbers“ enthält die Werte, die IANA unter ihrer OUI zuteilt. Das SNAP-Protokollnummernregister führt 0x0042 als Dokumentationswert. Hier spricht IANA innerhalb ihres Mandats.

IANA veröffentlicht außerdem „IEEE 802 Numbers“. Der EtherType-Abschnitt sagt ausdrücklich, dass IANA diese Werte nicht vergibt. Er bezeichnet die Liste als beigetragene, ungeprüfte Information und verweist auf IEEE RA. Bereitstellung und Expertenkoordination machen aus einer Informationsansicht keine ursprüngliche Vergabeakte.

Automatische Importe verlieren häufig genau diesen Hinweis. Sie übernehmen Tabellenzeilen, leiten den Eigentümer vom Domainnamen ab und erzeugen einen sauber versionierten Irrtum. Ein Hash beweist, dass die Kopie unverändert ist. Er beweist nicht, dass die Verantwortung der Quelle richtig verstanden wurde.

Wenn diese Daten Sicherheitsregeln steuern, wird aus Provenienz Verhalten. Ein Dokumentationsbeispiel kann als Standard zugelassen, ein lokaler Versuch global interpretiert oder eine historische Liste über eine aktuelle Zuteilung gestellt werden. Die erklärte Rolle des Registers gehört deshalb in das Datenmodell.

Vergaberegeln begrenzen den IANA-Teilraum

Eine neue Protokollnummer unter 00-00-5E muss einem IETF-Standard oder einem mit IETF-Arbeit verbundenen Standard dienen. Das Protokoll muss in einem Internet-Draft oder RFC dokumentiert sein und ein Versionsfeld an fester Stelle oder eine gleichwertige Zukunftsmarkierung besitzen.

Reguläre Zuteilungen benötigen Expert Review. 0x0000 und 0xFFFF sind reserviert und verlangen IESG Ratification. Ein Protokoll, das bereits einen EtherType besitzt, darf für denselben Zweck keine IANA-OUI-Nummer erhalten. Der EtherType kann direkt oder hinter der Null-OUI in SNAP verwendet werden.

Das verhindert parallele Autorisierungsgeschichten. Ohne diese Regel könnten zwei Nummern dieselbe Funktion beanspruchen, aber unterschiedlichen Verfahren, Aktualisierungen und Verantwortlichkeiten folgen.

Auch MAC-Zuteilungen unter der IANA-OUI sind zweckgebunden. Sie müssen Standards dienen, in Zweierpotenzen ausgerichtet sein und dürfen Herstellern nicht helfen, einen eigenen IEEE-Block zu umgehen. Die Delegation deckt IETF-nahe Koordination ab, nicht das gesamte IEEE-Registergeschäft.

Dokumentation und lokales Experiment sind verschiedene Zwecke

0x0042 unter der IANA-OUI ist für Dokumentation vorgesehen. Bei anderen organisationsspezifischen Parametern steht der Zusatzwert 0x42 ebenfalls für Beispiele. So können Spezifikationen konkrete Bytes zeigen, ohne produktive Zuteilungen zu belegen.

IEEE hat dagegen 0x88B5 und 0x88B6 für lokale experimentelle EtherTypes vorgesehen. Diese Werte gehören in ein anderes Register und verfolgen eine andere Politik. „Experimenteller EtherType 0042“ verbindet drei unvereinbare Aussagen zu einem scheinbar plausiblen Etikett.

Beispielwerte können in Vorlagen überleben und in Produktion gelangen. Lokale Experimente können Verwaltungsgrenzen überschreiten. Wer Geltungsbereich, Verantwortlichen und Ablaufdatum mit der Nummer speichert, erkennt diese Drift frühzeitig.

Das Register bestätigt keine laufende Implementierung

Eine maßgebliche Registerzeile belegt eine Zuteilung in einem Namespace. Sie beweist nicht, dass ein Gerät richtig parst, dass die Nutzlast dem Namen entspricht oder dass eine Anwendung ein Ergebnis erhalten hat.

Die Belegkette beginnt mit Bytes, Offsets, Tags und Länge. Träger und OUI bestimmen den Namespace. IEEE- oder IANA-Register bestimmen die Vergabe. Prüfverfahren und Spezifikation bestimmen die Bedingungen. Softwarestand und Konfiguration zeigen die Implementierung. Die Aufzeichnung zeigt ein Paket; der Endpunkt zeigt die Wirkung.

Wer diese Ebenen zusammenzieht, macht aus Eindeutigkeitskoordination eine Betriebszertifizierung. Die Trennung schützt alle Beteiligten: Register bleiben für ihren Raum verantwortlich, Hersteller für ihr Verhalten und Betreiber für die beobachtete Wirkung.

Ein Inventar für den Störungsfall

Speichern sollte es Rohbytes, Position, Tags, Träger, vollständige OUI-Kennung, inneren Wert, Registerinhaber, Quelle und Zeitpunkt, Verfahrensklasse, Spezifikation, Parser-Version und Ergebnis. Der Anzeigename ist nützlich, aber kein Ersatz.

Damit lassen sich Abweichungen unterscheiden. Eine informative IANA-Liste kann älter sein als IEEE RA. Ein gültiger IANA-Wert kann im Dissector als EtherType erscheinen. Ein Dokumentationswert kann im Live-Netz auftauchen. Jede Lage verlangt eine andere Reaktion.

RFC 9542 baut keine zentrale Oberhoheit. Es bewahrt eine Delegationskarte. IEEE hält die direkte Vergabe, IANA den anvertrauten Unterraum und die Implementierung die Pflicht, ihr Verhalten zu belegen. Nur die vollständige Kennung verhindert, dass aus zwei Oktetten nachträglich ein fremdes Mandat wird.

Quellen