Zusammenfassung

  • RFC 9631 definiert experimentell CRH-16 und CRH-32; jeder kurze SID verweist auf einen lokalen Eintrag mit IPv6-Adresse, topologischer Funktion und optionalen Argumenten.
  • Gleiche Zahlen können an verschiedenen Knoten oder in verschiedenen Tabellenständen andere Wirkungen haben. Das Paket enthält weder den FIB-Stand noch die Herkunft der installierten Bedeutung.
  • Ein belastbarer Pfadbeleg verbindet jeden Lookup mit installiertem Zustand, ACL/uRPF-Entscheidung, Zielumschreibung, tatsächlichem Ausgang, nächstem Knoten und Anwendungsergebnis.

Der gleiche SID traf zwei Router. Beide fanden einen gültigen Eintrag. Der eine berechnete den günstigsten Pfad, der andere erzwang eine Schnittstelle. Formell war derselbe Wert verarbeitet worden; operativ lagen zwei Befehle vor.

Die Kompaktheit hatte Kontrolle unsichtbar gemacht.

RFC 9631 beschreibt CRH-16 und CRH-32 als IPv6-Experiment. Die Kennungen sparen Platz, weil sie umfangreichere Bedeutung außerhalb des Pakets referenzieren.

Die Funktion steckt in der Tabelle

CRH-SIDs stehen in umgekehrter Reihenfolge. Der Knoten vermindert Segments Left, wählt den aktuellen SID und sucht ihn in der CRH-FIB. Der Treffer liefert eine IPv6-Adresse, eine topologische Funktion und gegebenenfalls Argumente. Die Funktion kann Least-Cost-Weiterleitung oder einen bestimmten Ausgang verlangen.

Ein SID ist somit kein vollständig codierter Weg. Er ist ein lokaler Verweis. RFC 9631 erlaubt ausdrücklich knotenspezifische Bedeutung, weil jeder SID von genau einem CRH-Router verarbeitet wird, dessen Adresse dem aktuellen Ziel entspricht.

Die 2 eines Knotens muss nicht der 2 eines anderen entsprechen. Selbst am gleichen Gerät kann sie sich durch CLI, PCEP, NETCONF oder ein verteiltes Routingupdate verändern.

Zur Auswertung gehören Knotenidentität, Lookup-Zeit, installierte Revision, Eintrag, Funktion, Argumente und Provisionierungsquelle. Ohne diese Daten belegt der Header nur, welche Zahl vorlag, nicht welche Entscheidung gültig war.

Ein gültiger Header endet vor der Weiterleitung

Die Regeln verwerfen zu große Header, berechnen die Mindestlänge und erkennen unmögliche Längen, fehlende Einträge sowie Multicast-Adressen vor dem letzten Segment. Vorgesehene Fehler lösen ICMPv6 Parameter Problem aus.

Danach kopiert der Knoten die Adresse des Eintrags in das IPv6-Zielfeld und übergibt Paket, Funktion und Argumente an das IPv6-Modul. Erst dort werden nächster Hop, Schnittstelle und tatsächliche Weiterleitung bestimmt.

Ein gültiger CRH beweist daher keinen Ausgang. Kein sichtbarer ICMPv6-Fehler beweist ebenfalls wenig: Fehlermeldungen können verloren gehen, gefiltert oder begrenzt werden. Ein gültiger Eintrag kann auf einen ausgefallenen Link zeigen. Ein Empfänger kann das Paket annehmen, während die Anwendung es verwirft.

Validierung, Lookup, Umschreibung, Next-Hop-Wahl, Ausgang und Anwendung sind getrennte Ereignisse. Ein gemeinsamer Erfolgsstatus verwischt genau die Grenze, die für eine Störung gebraucht wird.

Provisionierung und Ausführung brauchen eine gemeinsame Zeitachse

Die CRH-FIB kann per CLI, PCEP- oder NETCONF-Controller oder verteiltem Routingprotokoll befüllt werden. Diese Verfahren liegen außerhalb des RFC. Das schützt lokale Architekturentscheidungen, überträgt aber deren Konsistenz an den Betreiber.

Eine erfolgreiche Controllertransaktion ist keine ASIC-Bestätigung. Knoten konvergieren zu unterschiedlichen Zeiten. Ein Rollback kann den SID, aber nicht seine Argumente wiederherstellen. Teilinstallationen können neue Funktionen mit altem Kontext verbinden.

Das Paket trägt keine Tabellen-epoch. Notwendig sind Konfigurationswunsch, Kandidatenzustand, operativer Zustand, Hardwareinstallation und Paketbeobachtung auf abgestimmter Zeitbasis. Zwei korrekte Snapshots vor und nach einer Änderung ordnen das Paket dazwischen nicht automatisch zu.

Auch Interoperabilität verlangt Funktionsgleichheit. RFC 9631 fragt ausdrücklich, ob Implementierungen identische Funktionen und Argumente besitzen und semantisch gleich ausführen. Gemeinsame Syntax mit anderem Verhalten ist keine Pfadinteroperabilität.

Quelladresse ist ein Signal, keine Identität

Vertrauen besteht im Modell zwischen Knoten desselben Betreibers und wird über die Quelladresse erkannt. ACLs müssen CRH-Pakete aus nicht vertrauenswürdigen Quellen zu lokalen Adressen verwerfen.

Quelladressen lassen sich fälschen. EFP-uRPF reduziert einige Fälschungen, nicht alle. Jede Netzgrenze muss zusätzlich eingehende CRH-Pakete sperren, die eine Adresse einer vertrauenswürdigen Schnittstelle vortäuschen.

Der Sicherheitsbeleg enthält Eingangsinterface, Präfixsatz, ACL-Version, Trefferregel, Zähler, uRPF-Routingzustand und Entscheidung. Zudem muss die Regel an jeder relevanten Grenze wirksam sein.

Authentication Header kann das Paket in seinem Schlüsselkontext schützen. Er authentisiert weder die historische FIB noch die Platzierung einer ACL oder den tatsächlich genommenen Weg.

Weniger Bits sind noch kein Leistungsergebnis

Als Motivation nennt RFC 9631 Headerkopien in begrenzten ASIC-Speicher und Hosts, die wegen unvollkommenem Path MTU Discovery nahe der IPv6-Mindestgröße von 1280 Byte bleiben.

Das begründet ein Experiment. Das Ergebnis hängt von Parser, Header-Tiefe, SID-Zahl, Nutzlast, MTU, ICMPv6, Hardware und Verkehr ab. Ein kurzer Header kann einen langsamen Softwarepfad auslösen oder an einem nicht unterstützenden Knoten scheitern.

Ein Leistungsversprechen benötigt Basiswert, identischen Verkehr, Versionen, Größenverteilung, Verlust, Latenz und Zählerdefinition. Feldbreite ist Spezifikation; Kostenvorteil ist Messung.

Der experimentelle Status ist kein vorweggenommenes Urteil

RFC 9631 gehört nicht zum Standards Track. Experimentberichte sollen Einführungsaufwand, Synchronisierung, Hardware, SID-Reichweite, Sicherheit, Leistung, ACL-Wirkung und -Kosten, FIB-Befüllung, Maßstab, Interoperabilität und OAM behandeln.

Unterstützung in ping, traceroute, tcpdump und Wireshark verbessert die Beobachtung. Sie beweist weder gleiche Funktionssemantik noch sichere Grenzen oder Anwendungserfolg.

Parser, FIB, Ausgangscapture, Folgeknoten und Anwendung besitzen jeweils nur ihren Teil der Aussage. Der Pfad entsteht als Beleg erst durch die überprüfbare Verbindung dieser Teile.

Quellen