Zusammenfassung

  • RFC 9650 ersetzt für das Register IS-IS Neighbor Link-Attribute Bit Values Standards Action durch Expert Review, damit experimentelle Protokolle koordinierte Werte erhalten können, statt scheinbar freie Bits privat zu besetzen.
  • Der Expertenentscheid und der IANA-Eintrag belegen eine Zuweisung im gemeinsamen Namensraum, nicht Protokollqualität, Implementierung, Freigabe, Interoperabilität oder Routingwirkung.
  • Ein belastbarer Nachweis führt von Antrag und Register über Build und autorisierte Aktivierung bis zu LSP, Peer-Parser, lokaler Policy, Route und beobachtetem Dienst.

Eine öffentliche Bedeutung ist noch kein beobachtetes Verhalten

Im aktuellen IANA-Register steht 0x4 für Local Edge Enabled for Flooding mit Verweis auf RFC 9667. Der Eintrag macht die Bedeutung öffentlich und verhindert, dass dieselbe Position offiziell einer zweiten Bedeutung zugeteilt wird.

Er belegt nicht, dass ein Gerät RFC 9667 implementiert. Ebenso wenig belegt er eine Konfiguration, ein gesendetes LSP, die Auswertung durch einen Nachbarn oder einen geänderten Flooding-Pfad. Die Registerzeile ist für ihre Ebene vollständig und für die anderen Ebenen absichtlich unzuständig.

RFC 5029 definiert den Link-Attributes-Sub-TLV mit Subtype 19 und einem 16-Bit-Flagfeld. 0x1 bedeutet Local Protection Available, 0x2 Link Excluded from Local Protection. Der Sub-TLV ist optional, darf pro Nachbar höchstens einmal vorkommen und wird von Routern ohne Unterstützung still ignoriert. Schon dieses stille Ignorieren trennt die Existenz des Bits von seiner Wirkung.

Welche Engstelle RFC 9650 beseitigt

RFC 5029 verlangte für weitere Werte Standards Action und erlaubte Early Allocation. RFC 9650 erklärt dieses Verfahren für experimentelle Protokolle als unnötig restriktiv. Wer vor einem Standards-Track-RFC Erfahrung sammeln wollte, hatte einen Anreiz, einen nicht registrierten Wert zu verwenden. Mehrere Experimente konnten dadurch dasselbe vermeintlich freie Bit wählen.

Die neue Policy Expert Review senkt die Hürde für koordinierte Einzigartigkeit. Sie senkt nicht die Anforderungen an eine spätere Produktionsfreigabe.

Expert Review hat einen begrenzten Auftrag

RFC 8126 warnt davor, Registrierung durch übermäßigen Zeit- und Arbeitsaufwand unattraktiv zu machen. Wenn reale Nutzung im Register nicht mehr sichtbar ist, schadet das der Protokolleinführung und entwertet das Register. Die passende Policy ist deshalb die am wenigsten strenge, die den Bedarf des Registers erfüllt.

Expert Review bleibt eine Prüfung. RFC 7370 weist IS-IS-Experten an, üblicherweise Anträge aus Working-Group-Dokumenten oder geplanten AD-Sponsored-Dokumenten zu betrachten, Konsens oder Zustimmung zu prüfen und den technischen Gehalt zu bewerten. Sie sollen IETF-Konsens nicht überstimmen. Nach Zustimmung aktualisiert IANA das Register. Scheitert der Dokumentweg, greifen Ablauf und Rückgabe.

Damit lautet der Entscheid: Dieser Antrag darf unter den Registerkriterien einen eindeutigen Wert erhalten. Er lautet nicht: Jede Implementierung ist sicher oder jedes Netz soll die Funktion einschalten.

Warum private Werte spätere Systeme binden

RFC 7120 beschreibt zwei Kollisionspfade. Eine frühe Implementierung wählt einen freien Wert, erhält später aber einen anderen offiziellen Wert; frühe und endgültige Version sprechen dann verschiedene Dialekte. Oder IANA vergibt den privat genutzten Wert an eine andere Erweiterung; zwei Bedeutungen treffen im Feld aufeinander.

Eine frühe öffentliche Zuweisung macht Besitz, Referenz und Lebenszyklus sichtbar. Sie beseitigt nicht den Migrationsbedarf, falls ein Experiment endet. Ein zurückgegebener Registerwert entfernt keine Firmware und keine archivierte Konfiguration.

Der Nachweisweg nach der Zuweisung

Zum Antrag gehören Dokumentrevision, Zweck und Zeit. Der Review-Beleg nennt Experte, Umfang, Kriterien, Rückfragen und Entscheidung. Der Registerbeleg enthält Wert, Referenz, Zustand und beobachteten Zeitpunkt.

Die Implementierung fügt Commit, Build-Herkunft, Sender- und Parsertests sowie das Verhalten bei unbekannten Bits und doppelten Sub-TLVs hinzu. Die Change Authority dokumentiert Freigabe, Geräte, Nachbarschaften, Konfiguration und Rollback. Paketmitschnitt und Peer-Telemetrie trennen Empfang, Syntax, semantische Unterstützung und Policy. Danach folgen Routenberechnung, Installation und Servicebeobachtung.

Die Primärstellung laufenden Codes verhindert, dass ein Soll-Eintrag als Ist-Nachweis dient. Das Register ist maßgeblich für die koordinierte Bedeutung; Binärdatei, Zustand und Beobachtung sind maßgeblich für das Geschehen.

Sicherheit bleibt außerhalb des Zuweisungsurteils

RFC 9650 verändert laut eigenem Sicherheitsteil die Fragen aus RFC 5029 nicht. Zusätzliche LSP-Information kann ausgespäht oder verändert werden. Die jeweilige Spezifikation muss Offenlegung und Manipulation behandeln und bei hohem Risiko Integritätsschutz berücksichtigen.

Expert Review authentifiziert keinen Absender, prüft keinen konkreten Parser und genehmigt keine Routing-Policy. Das ist eine notwendige Arbeitsteilung. Eine Kontrolle gegen Namenskollisionen soll Sicherheits- und Betriebsverantwortung ergänzen, nicht verdecken.

Die Minimum Initial Specification verlangt gerade genug gemeinsame Festlegung, damit unabhängige Systeme dasselbe Symbol nicht widersprüchlich verwenden. Implementierung und Adoption bleiben sichtbar lokal. Die Realitätsschichten halten Antrag, Review, Register, Code, Paket und Route auseinander.

Sources