Zusammenfassung

  • RFC 3359 veröffentlichte eine gemeinsame Karte der IS-IS-TLV-Werte, um Kollisionen zu vermeiden, erklärte aber ausdrücklich, weder Standard noch Zuteilungsstelle zu sein.
  • RFC 3563 überführte diese Momentaufnahme später in ein vorläufig von IANA geführtes Register mit Designated-Expert-Prüfung; eine Registrierung belegt jedoch weder Softwareunterstützung noch Einsatz oder Netzergebnis.

Zwei Entwicklergruppen können sorgfältig handeln und gemeinsam trotzdem einen Fehler erzeugen. Beide prüfen ihre Unterlagen, sehen denselben scheinbar freien Oktettwert und geben ihm für unterschiedliche Erweiterungen verschiedene Bedeutungen. Getrennt arbeiten beide Implementierungen korrekt. Treffen sie aufeinander, steht auf der Leitung eine Zahl, während die Empfänger zwei Semantiken anwenden.

Der Fehler beginnt nicht mit einem beschädigten Paket. Er beginnt mit einem Namensraum ohne gemeinsames Gedächtnis.

RFC 3359, im August 2002 als Informational veröffentlicht, schuf ein solches Gedächtnis für Type-Length-Value-Elemente in IS-IS. T. Przygienda sammelte bekannte, verwendete oder geplante Werte der obersten Ebene, vermerkte ihre Eignung für IIH, LSP oder SNP und nannte einen groben Ursprung. Vor einer neuen Wahl ließ sich damit erkennen, was bereits belegt oder angekündigt war.

Die Tabelle war institutionell uneinheitlich, weil es die Protokollgeschichte ebenfalls war. Einige Werte stammten aus ISO 10589, andere aus der IP-Erweiterung von IS-IS in RFC 1195, weitere waren noch IETF-Entwürfen zugeordnet. Ein alter DECnet-Eintrag und proprietäre Werte von Lucent und Nortel standen neben offener Standardisierungsarbeit. „Benutzt“ hieß nicht „von einer einzigen Stelle standardisiert“, und die Zeilen hatten unterschiedliche normative Qualität.

Gerade diese Mischung machte die Liste nötig. Erweiterungen entstanden in ISO-, SIF- und IETF-Zusammenhängen, doch alle beschrieben dasselbe Zahlenfeld auf der Leitung. Betrachtete jede Gemeinschaft nur ihre eigenen Dokumente, konnte eine Kollision die institutionelle Grenze überschreiten, bevor eine Organisation davon erfuhr.

RFC 3359 begrenzte den eigenen Anspruch ungewöhnlich deutlich. Das Dokument sollte künftige Konflikte vermeiden, stellte aber weder einen Standard noch eine Autorität zur Vergabe von TLV-Nummern dar. Die Auswahl wurde auf einer gemeinsamen, informativen Grundlage unter ISO-, SIF- und IETF-Gruppen koordiniert. ISO bot für diesen Raum keine Nummerierungsstelle; die Verantwortung von IANA war damals als auf IP-bezogene Codepunkte begrenzt beschrieben. Ein plausibles Zentralorgan existierte zu diesem Zeitpunkt nicht.

Die Liste koordinierte durch Offenlegung. Wer sah, dass ein Wert benutzt oder vorgemerkt war, konnte einen anderen wählen. Ihre Wirksamkeit brauchte keine Polizeigewalt; sie beruhte darauf, dass Beteiligte Interoperabilität höher gewichteten als einen privaten Anspruch auf ein Oktett.

Die Grenzen blieben konkret. RFC 3359 nannte nicht für jeden Wert das genaue Ursprungsdokument und löste keine sub-TLV-Codepunkte. Regelmäßige Aktualisierungen waren vorgesehen, und ein amtliches Register konnte die Liste später ersetzen. Eine Zeile warnte vor Wiederverwendung; sie war keine vollständige Herkunftskette und kein Einsatznachweis.

Im selben Jahr beendete RFC 3232 die Praxis, den umfassenden Assigned-Numbers-Katalog immer wieder als neue RFC herauszugeben, zugunsten einer Online-Datenbank. Ein lebendes Register konnte sich ändern, ohne für jede Vergabe ein historisches Dokument neu zu veröffentlichen. IS-IS war zusätzlich schwierig: Der Kern kam von ISO, Interneterweiterungen liefen über die IETF, und Implementierungen belegten bereits Werte außerhalb eines einzigen sauberen Verfahrens.

Die institutionelle Reparatur folgte 2003 mit RFC 3563. Sie dokumentierte die Zusammenarbeit zwischen ISOC/IETF und ISO/IEC JTC1/SC6, unterschied von ISO betreute IS-IS-Kernmechanismen von Interneterweiterungen im IETF-Bereich und bat IANA, das TLV-Register vorläufig zu führen, bis JTC1 einen Registrierungsdienst anbieten konnte.

„Vorläufig“ ist entscheidend. RFC 3563 erklärte IANA nicht zur dauerhaften Souveränin. Die Zuteilungsbefugnis konnte nach Mitteilung auf JTC1 übergehen, während IANA eine von JTC1 aktualisierte Informationskopie behalten durfte. Seitenverwaltung, Wertgenehmigung und Protokollstandardisierung waren trennbare Aufgaben.

Das neue Verfahren begann mit Kontinuität. Sein Anfangsstand sollte mit RFC 3359 synchronisiert werden. Die informelle Karte wurde zum Ausgangsbeleg des formellen Registers. Neue Werte verlangten die Zustimmung eines vom IESG bestimmten Experten. Die IETF sollte JTC1/SC6 informieren; JTC1/SC6 sollte Anträge aus dem eigenen Umfeld an das IANA-Verfahren verweisen.

Damit entstand ein gemeinsamer Eingang für neue Vergaben, keine nachträgliche Gleichstellung alter Zeilen. Eine Spezifikation musste weiterhin Syntax und Verhalten bestimmen, Software musste sie implementieren, Betreiber sie einschalten und Gegenstellen sie richtig austauschen und auswerten.

Auch das Register selbst gewann Struktur. RFC 6233 ergänzte eine Purge-Spalte, die anzeigt, ob ein TLV in einem gelöschten LSP vorkommen darf. Das ist keine Dekoration: Der PDU-Kontext entscheidet, ob identische Bytes zulässig sind. Das Register kann einen begrenzten Teil der Protokollauslegung tragen; die vollständige Regel bleibt in der definierenden RFC.

RFC 7370, 2014 auf dem Standards Track veröffentlicht, verfeinerte Tabelle und menschliche Prüfung. Zusammengehörige sub-TLV-Register wurden vereinigt, wenn ein gemeinsamer Namensraum beabsichtigt war. Zugleich erhielten Designated Experts Leitlinien für Codepunkte, die vor Veröffentlichung eines Entwurfs als RFC beantragt wurden.

Die Prüfung war nicht bloß persönliches Gefallen. Bei Arbeitsgruppendokumenten sollte Konsens mit den Vorsitzenden bestätigt werden; ohne passende Gruppe war ein durch einen Area Director unterstützter Weg vorgesehen. Experten sollten technische Substanz prüfen, den IETF-Konsens aber nicht überstimmen. Kam das Dokument nicht voran, konnte die Vergabe nach der Early-Allocation-Disziplin aus RFC 7120 auslaufen und entfernt werden.

Prüfung ist damit ein Filter mit dokumentierbaren Eingaben, kein Privateigentum am Zahlenraum. RFC 8126 stellt das Vokabular dafür bereit: Standards Action, Specification Required, Expert Review und andere Regeln verlangen unterschiedliche Voraussetzungen. Keine verspricht gute Implementierung oder tatsächliche Nutzung.

Umgekehrt kann übermäßige Reibung schaden. RFC 9650 änderte 2024 ein Register für IS-IS-Neighbor-Link-Attribute-Bits von Standards Action zu Expert Review. Die strenge Regel verhinderte Vergaben an experimentelle Protokolle und erhöhte den Anreiz, unregistrierte Werte zu besetzen. Ist der legitime Eingang zu eng, bildet die offizielle Karte die wirkliche Nutzung schlechter ab.

Die dauerhafte Aufgabe lautet daher nicht Zentralisierung gegen Freiheit. Koordination muss billiger und glaubwürdiger sein als stille Wiederverwendung. Zu wenig Verfahren erlaubt Kollisionen; zu viel drängt Experimente aus der Dokumentation. Begrenzte Expertenprüfung, sichtbare Referenzen und Ablaufregeln suchen die Mitte.

Die heutige IANA-Seite ist das lebende Ergebnis dieser Entwicklung. Sie enthält Haupt- und Unterregister, Anwendungsspalten, Referenzen und Richtlinien, die 2002 nicht sämtlich vorhanden waren. Dieser Beitrag friert die Seite als datierte Quelle ein; er behauptet weder, die heutige Form habe schon in RFC 3359 bestanden, noch, sie werde unverändert bleiben.

Vor allem ist eine Registerzeile kein laufender Code. Sie belegt, dass ein Koordinationsverfahren Wert, Namen und Referenz unter einer Regel verbindet. Sie belegt nicht, dass ein Parser den Wert versteht, er in der beobachteten PDU zulässig ist, Produkte interoperieren, Betreiber ihn aktiviert haben, eine Route in die Datenbank gelangte oder ein Paket ankam.

Dafür braucht es spätere Belege. Fähigkeitsdokumente und Konformitätstests sprechen zur Implementierung, Konfigurationen zur Absicht, Paketmitschnitte zum Auftreten an einem Messpunkt, Protokolle und Datenbankzustand zur lokalen Verarbeitung, Verkehrstests zum Ergebnis. Das Register schafft gemeinsame Koordinaten; es ersetzt diese Belege nicht.

Zwei Texte von Lu Heng dienen offengelegt als analytische Perspektiven. „Minimum Initial Specification“ erklärt, warum eine kleine gemeinsame Tabelle schon vor Klärung der endgültigen institutionellen Zuständigkeit nützlich sein konnte. „Reality Layers“ trennt Nummerneintrag, Spezifikation, Implementierung, Einsatz und Ergebnis. Das sind redaktionelle Lesarten, keine Behauptungen über Urheberschaft oder Absicht von RFC 3359.

RFC 3359 hatte keine Vergabegewalt. Machtlos war sie dennoch nicht. Sie gab Gemeinschaften vor der Wahl eine gemeinsame Tatsache. Mitunter genügt genau das, damit zwei jeweils korrekte Privatwelten keine inkompatible öffentliche Leitung schaffen.

Quellen