Zusammenfassung

  • Reichen 255 Oktette nicht aus, kann ein IS-IS-Objekt aus mehreren TLVs desselben Typs und Schlüssels bestehen. Jeder Teil muss eigenständig parsbar sein; der Empfänger verarbeitet alle Teile unabhängig von Reihenfolge und LSP-Fragment.
  • Das neue Capability-Sub-TLV vom Typ 30 ist ausschließlich informativ, nennt keine einzelnen Codepoints und darf das Sende- oder Empfangsverhalten des Protokolls nicht verändern.
  • Eine Freigabe braucht deshalb einen externen Nachweis für jeden Empfänger und jeden betroffenen Codepoint sowie einen gestuften Versuch mit überprüftem Rückweg.

Die gefährlichste Abweichung kann völlig ruhig aussehen. Zwei Router erhalten dieselben beiden TLV-Teile. Einer fügt die Attribute zusammen, der andere berücksichtigt nur den ersten Teil. Beide Nachbarschaften bleiben aktiv. Erst die voneinander abweichende Pfadberechnung zeigt, dass sie nicht mehr dieselbe Netzrealität besitzen.

RFC 9885 macht diese alte Größenbegrenzung beherrschbar. IS-IS überträgt Informationen in Type-Length-Value-Tupeln. Type und Length belegen jeweils ein Oktett; damit endet der Value eines einzelnen TLV bei 255 Oktetten. Größere Netze und zusätzliche Traffic-Engineering-Attribute können ein logisches Objekt über diese Grenze treiben. Wo frühere Spezifikationen keinen anderen Mechanismus festgelegt haben, kodifiziert die RFC mehrere Vorkommen als reguläre Erweiterung.

Ein MP-TLV ist jedoch kein beliebig zerschnittener Bytestrom. Seine Teile gehören zusammen, wenn sie denselben Typ und – soweit vorhanden – denselben bereits definierten Objektschlüssel tragen. Die Bedeutung des Schlüssels bleibt Sache der ursprünglichen TLV-Spezifikation. Jeder Teil muss ohne die anderen parsbar sein. Ein Sub-TLV oder eine andere Dateneinheit darf nicht über zwei Teile hinweg geteilt werden; das wäre eine ungültige Kodierung.

Der Empfänger setzt Bedeutung zusammen

Ein unterstützender Empfänger muss die Informationen sämtlicher Teile übernehmen. Ankunftsreihenfolge und Platzierung in LSP-Fragmenten sind unerheblich. Teile können in einem oder mehreren LSPs stehen; auch ihre Position in einem IIH ändert nichts. Inhaltlich werden sie wie eine logische Verkettung verarbeitet, wobei der wiederholte Schlüssel die Objektidentität erhält.

Widersprüche bleiben trotzdem Fehler. Ein fester Wert wie eine Metrik kann außerhalb des Schlüssels liegen und in mehreren Teilen unterschiedlich erscheinen. Auch ein nur einmal zulässiges Sub-TLV kann mit konkurrierenden Werten vorkommen. Gibt die ursprüngliche Spezifikation keine eigene Regel vor, zählt das erste Vorkommen im LSP mit der niedrigsten Nummer; im IIH zählt das erste Vorkommen.

Die Pflichten von Sender und Empfänger sind absichtlich verschieden. Ein Empfänger darf zwei Teile von je 100 Byte nicht ablehnen, nur weil sie gemeinsam in ein TLV gepasst hätten. Ein Sender sollte dagegen erst mehrere TLVs erzeugen, wenn MP-TLV für den Codepoint anwendbar ist und die Information tatsächlich die Einzelkapazität überschreitet. Fehlt lediglich im aktuellen LSP der Platz, sollte das noch vollständige TLV in ein anderes LSP verschoben werden.

Diese Asymmetrie ist Interoperabilitätsvorsorge. Der Empfänger bleibt gegenüber einer gültigen, aber unnötig geteilten Darstellung robust. Der Sender vergrößert die Fehlerfläche nicht ohne Not. Die Beobachtung „angenommen“ beweist daher noch nicht, dass die Erzeugung angemessen war.

Typ 30 ist ein Hinweis, kein Handshake

Bei nur implizit spezifizierter Unterstützung kann eine Teilbereitstellung erhebliche Folgen haben. Ein alter Router wählt möglicherweise ein Vorkommen aus und ignoriert weitere. Fehlen dadurch Linkattribute für eine Constraint-Berechnung, arbeiten Router mit unterschiedlichen Eingangsdaten. Die RFC nennt unerwartete Weiterleitung, Schleifen und verworfenen Verkehr. Das ist eine bedingte Risikobeschreibung, kein Bericht über ein konkretes Netz.

Zur Diagnose registriert RFC 9885 im Router-CAPABILITY-TLV das Sub-TLV Typ 30 mit Länge null. Es signalisiert Unterstützung für Codepoints, bei denen ältere Texte die Mehrteiligkeit nicht ausdrücklich beschrieben hatten. Der Geltungsbereich des tragenden Capability-TLV ist je IS-IS-Level begrenzt.

Die entscheidende Norm folgt sofort: Die Meldung dient nur Informationszwecken. IS-IS-Implementierungen dürfen weder ihre Aussendung noch die Verarbeitung empfangener Informationen aufgrund dieser Meldungen verändern. Sie ist keine Verhandlung, keine Zustimmung und keine automatische Sicherheitssperre.

Typ 30 besitzt außerdem keine Syntax zur Aufzählung unterstützter Codepoints. Das Dokument nimmt eine breite Unterstützung an, erkennt aber ausdrücklich an, dass reale Implementierungen MP-TLV nur für bestimmte Einsatzfälle gebaut haben können. Hinter einer einzigen sichtbaren Meldung bleibt somit eine Matrix aus Plattform, Version, Rolle und Codepoint offen.

Die MP-Spalte der IANA-Register beantwortet wiederum eine andere Frage. Y bedeutet, dass das Verfahren für die Definition dieses Codepoints anwendbar ist. Es sagt nichts über das installierte Binary, die lokale Aktivierung, tatsächlich gesendete Teile oder eine konsistente Verarbeitung durch alle Empfänger.

Die Freigabe liegt beim Betreiber

Die RFC empfiehlt codepointspezifische Schalter für die Erzeugung. Kann MP-TLV deaktiviert werden, muss die Implementierung zwei Situationen protokollieren: den Empfang eines MP-TLV bei deaktivierter Nutzung und den lokalen Bedarf, bei deaktivierter Erzeugung ein MP-TLV zu bilden. Solche Einträge zeigen Exposition und Bedarf, erteilen aber keinen Änderungsauftrag.

Vor der Aktivierung muss der Betreiber belegen, dass alle vorgesehenen Empfänger den betroffenen Codepoint korrekt verarbeiten. Dazu gehören Level, Empfängerrolle, Plattform, installiertes Image, Testbytes, Parsergebnis, Pfadberechnung, FIB und Rückfalltest. IS-IS-Authentisierung bleibt wichtig; authentische Daten können von einer alten Implementierung trotzdem unvollständig verstanden werden. Herkunftsintegrität und semantische Fähigkeit sind getrennte Nachweise.

Der Vorrang laufenden Codes wird damit konkret. Das Register beschreibt die Anwendbarkeit, der Router gibt eine allgemeine Behauptung ab. Die entscheidende Realität ist das beobachtete Verhalten genau jenes Binaries, das Routen berechnet und installiert.

Quellen