Zusammenfassung

  • RFC 5308 führt TLV 236 für IPv6-Erreichbarkeit, TLV 232 für IPv6-Schnittstellenadressen und NLPID 142 für die Protokollunterstützung ein. Die drei Angaben haben verschiedene Geltungsbereiche und bilden zusammen noch keinen Zustellnachweis.
  • In einer gemeinsamen Standardtopologie muss ein gültiger IPv6-SPF-Pfad mit der Fähigkeit jedes Transitknotens, dem RIB, dem FIB und dem Paketergebnis verknüpft werden. RFC 5120 kann die Topologieteilnahme trennen, ersetzt aber keine Prüfung der Datenebene.

Eine richtige Berechnung kann an einer richtigen Nachbarschaft enden

Die Präfixanzeige ist grün. Der Metrikwert liegt im zulässigen Bereich, SPF hat einen Vorgänger bestimmt und der nächste Hop lässt sich auflösen. An beiden Enden läuft IPv6. Dennoch kann das erste Paket an einem Zwischenrouter verschwinden, der an der gewöhnlichen IS-IS-Topologie teilnimmt, aber für diesen Pfad keine wirksame IPv6-Weiterleitung besitzt.

Keine der einzelnen Beobachtungen muss falsch sein. Das Präfix wurde tatsächlich angekündigt. Die Adjazenz besteht. Der SPF-Algorithmus hat aus seinem Graphen korrekt gewählt. Erst die Schlussfolgerung, dieser Graph beweise auch die durchgängige Fähigkeit für jede darin beschriebene Adressfamilie, überschreitet die Aussagekraft der Daten.

RFC 5308 erweitert die vorhandenen IS-IS-LSPs um IPv6. RFC 5120 definiert später mehrere Topologien für Fälle, in denen die Teilnahme getrennt werden soll. Liest man beide Texte zusammen, wird die Grenze deutlich: Eine Adjazenz in der Standardtopologie belegt IS-IS-Konnektivität. Sie ist keine automatische Zusage, dass jede Schnittstelle, Linecard, Routinginstanz und FIB-Generation dieselbe IPv6-Fähigkeit besitzt.

TLV 236 entscheidet nicht über das Paket

IPv6 Reachability wird in TLV 236 kodiert. Ein Eintrag enthält Präfix, 32-Bit-Metrik, die Bits U, X und S sowie gegebenenfalls Sub-TLVs. U kennzeichnet die Abwärtsweitergabe in der Hierarchie, X die Umverteilung aus einem anderen Routingprotokoll und S das Vorhandensein eines Sub-TLV-Blocks. Keines dieser Bits ist eine Bestätigung der Weiterleitung.

Das TLV kann in einem LSP gar nicht, einmal oder mehrfach vorkommen. Link-lokale Präfixe dürfen damit nicht angekündigt werden. Die Präfixbytes werden auf die durch die Präfixlänge vorgegebene Mindestzahl verkürzt. Eine beweistaugliche Erfassung muss daher Länge und signifikante Bytes behalten, statt nur eine normalisierte Textdarstellung zu speichern.

Auch die Metrik hat eine harte Grenze. RFC 5308 übernimmt MAX_V6_PATH_METRIC mit dem Wert 0xFE000000. Ein Präfix mit einer höheren Metrik darf in der normalen SPF-Berechnung nicht berücksichtigt werden. Es kann trotzdem für einen anderen Zweck in der Datenbank stehen. Sichtbarkeit, syntaktische Annahme und normale Auswahlberechtigung sind somit schon im Standard getrennte Zustände.

TLV 232 gehört immer zu seinem PDU

TLV 232 enthält IPv6-Schnittstellenadressen, doch der PDU-Typ bestimmt ihre Bedeutung. In einem Hello dürfen nur link-lokale Adressen der sendenden Schnittstelle stehen. In einem LSP dürfen nur nicht link-lokale Adressen des ankündigenden Intermediate Systems stehen.

Wer lediglich den Adresswert extrahiert und Hello beziehungsweise LSP verwirft, entfernt die entscheidende Reichweite der Aussage. Eine auf den Nachbarlink begrenzte Adresse kann wie eine domänenweite Identität erscheinen. Umgekehrt verliert eine Systemadresse ihren belegbaren Ursprung. Die Bytes bleiben korrekt, ihre spätere Interpretation wird es nicht.

Eine belastbare Messkette speichert deshalb Absender, Schnittstelle, PDU-Typ, Adressbereich, Empfangszeit und Datenbankgeneration zusammen. Bequemlichkeit bei der Indexierung darf den Kontext nicht zerstören, der für eine Prüfung benötigt wird.

NLPID 142 sagt, was der Routingprozess unterstützt

Ein System, das IPv6-Routing über IS-IS unterstützt, muss den IPv6-NLPID 142 im Protocols Supported TLV aufführen. Diese Angabe liegt näher an einer Fähigkeitsaussage als das bloße Vorhandensein eines Präfixes. Sie stammt aber weiterhin aus dem Routingprozess.

Sie bestätigt weder die Programmierung einer bestimmten Linecard noch die Auflösung des link-lokalen Nachbarn. Sie sagt nichts darüber aus, ob die richtige Routinginstanz ihr RIB ausgewählt hat oder ob eine lokale Regel das Paket verwirft. Bei ECMP gilt die Erklärung auch nicht als Test aller gleichwertigen nächsten Hops. Eine erfolgreiche Sonde kann zufällig nur das gesunde Mitglied erreicht haben.

Authentifizierung schützt Herkunft und Integrität des LSP, erweitert aber dessen Zuständigkeit nicht. Ein authentischer Kontrollplaneintrag kann ein echtes Präfix über eine echte Nachbarschaft beschreiben, während im ausgewählten Transitknoten der nutzbare IPv6-FIB-Eintrag fehlt.

Die gemeinsame Topologie braucht eine zusätzliche Invariante

Eine gewöhnliche IS-IS-Adjazenz kann LSPs für mehrere Netzwerkschichtprotokolle transportieren. RFC 5308 verpflichtet einen IPv6-fähigen Knoten zur NLPID-Angabe, entfernt einen nicht fähigen Knoten aber nicht automatisch aus jedem IPv6-SPF-Pfad der Standardtopologie.

Darum braucht eine integrierte Bereitstellung eine betriebliche Invariante außerhalb des rohen Graphen: Jeder Knoten, der als Transit für einen IPv6-Pfad gewählt werden kann, muss die dafür geltende Fähigkeit in Kontroll- und Datenebene besitzen. Ein globales Inventarfeld „IPv6 aktiviert“ ist dafür zu grob.

Der Nachweis sollte den tatsächlich gewählten Vorgänger und nächsten Hop mit Schnittstelle, Routingkontext, Softwarestand, RIB-Generation, FIB-Generation und Paketbeobachtung verbinden. Bei ECMP umfasst er sämtliche auswählbaren Mitglieder. Die Zustandsfolge sollte sichtbar bleiben: im LSP gesehen, syntaktisch akzeptiert, für normales SPF berechtigt, bevorzugt, aufgelöst, im RIB installiert, im FIB programmiert und durch Zustellung bestätigt.

RFC 5120 macht Mitgliedschaft explizit

RFC 5120 signalisiert die Topologieteilnahme in IIHs. Meldet die Gegenseite auf einer Punkt-zu-Punkt-Verbindung eine Topologie-ID nicht, darf der lokale Router diesen Nachbarn nicht in seinem LSP für diese Topologie aufführen. Ohne eine gemeinsame Topologie sollten zwei Router keine Adjazenz bilden. MT ID 2 ist für IPv6-Routing reserviert; TLV 237 stellt die Topologiemitgliedschaft vor das von TLV 236 übernommene IPv6-Reachability-Format.

Die Regel für Broadcast-LANs verhindert eine zu einfache Gleichsetzung. Dort wird auch ohne gemeinsame Multitopologie eine Adjazenz aufgebaut, damit alle Teilnehmer denselben DIS wählen. Die Basisnachbarschaft ist real, berechtigt aber nicht zur Verwendung in jeder Topologie. Dafür zählt die tatsächlich gemeinsame Mitgliedschaft.

Getrennte IPv4- und IPv6-Topologien können ungeeignete Transitknoten ausschließen. Dafür entstehen weitere Betriebszustände: Mitgliedschaft, topologiespezifisches Overload, TLV-237-Anzeigen, separate SPF-Ergebnisse und möglicherweise getrennte RIBs. Überlappen bei mehreren Topologien derselben Adressfamilie die Adressen einer Schnittstelle, verlangt RFC 5120 einen zusätzlichen lokalen Mechanismus zur Wahl des richtigen RIB. Mehr Protokollausdruck ist noch keine automatische Datenentscheidung.

RFC 7775 korrigiert die alte Präferenzfolge

RFC 5308 ordnete die IPv6-Präferenz ursprünglich als Level 1 up, Level 2 up, Level 2 down und Level 1 down. RFC 7775 stellte später klar, dass das zugrunde liegende Zwei-Ebenen-Modell keinen passenden Level-2-Inter-Area-Routentyp kennt. Eine Klasse „Level 2 down“ durfte deshalb nicht in dieser Form entstehen. Die Präferenzbeschreibung wurde durch Regeln ersetzt, die zu den tatsächlich unterstützten Typen von TLV 236 und TLV 237 passen.

Eine heutige Implementierungsprüfung muss die Korrektur berücksichtigen und darf die Liste von 2008 nicht als endgültig behandeln. Der Beleg sollte TLV, Topologie, Level, U- und X-Bit, Quellprotokoll, Metrik, Präferenzklasse und SPF-Generation erhalten. Dann lässt sich eine Entscheidung nach einer Normkorrektur neu auswerten, ohne die empfangenen LSP-Bytes umzudeuten.

Der Beleg muss der Adressfamilie bis zum Ergebnis folgen

Ein nicht geheimer Betriebsbeleg kann Knotenidentität, Adjazenz und PDU-Typ; Topologie-ID; Protocols Supported und IPv6-NLPID; TLV-232-Adresse mit Hello- oder LSP-Kontext; TLV-236- oder TLV-237-Präfix, Bits, Metrik und Sub-TLVs; SPF-Generation; Vorgänger und nächsten Hop; alle ECMP-Mitglieder; IPv6-Fähigkeit jedes Transitknotens; RIB-Auswahl; FIB-Generation und Programmergebnis; link-lokale Nachbarauflösung; Sondenpfad; Zustellergebnis und Rollbackentscheidung verbinden.

Das ist mehr als ein ausführlicheres Log. Die Kette bewahrt die Zuständigkeitsgrenze zwischen einem Routingprozess, der Erreichbarkeit beschreiben darf, und einem Weiterleitungssystem, das das Paket bewegen muss. Der Graph kann als Graph korrekt sein, während die Behauptung „IPv6 hat diesen Pfad durchlaufen“ unbelegt bleibt.

Sources