Zusammenfassung

  • RFC 10038 wurde im August 2026 auf dem IETF Standards Track veröffentlicht. Er definiert DHCPv6-Option 149 für eine SRv6-Locator-Identitätsassoziation, Option 150 für den einzelnen Locator und Statuscode 23, wenn kein Locator verfügbar ist.
  • Ein erfolgreicher Reply belegt eine serverseitige Bindung innerhalb einer vertrauenswürdigen SR-Domäne. Client-Konfiguration, lokale Route, IGP-Ankündigung, RIB-Auswahl, FIB-Programmierung, SID-Verhalten, Filter, Paketergebnis, Rückzug und Wiedervergabe bleiben getrennte Verantwortungsbereiche.

Die entscheidende Frage lautet nicht nur: „Wurde der Locator vergeben?“ Sie lautet auch: „Wer darf jetzt behaupten, dass er erreichbar ist?“ Der DHCPv6-Server kann über seinen Pool und die Bindung Auskunft geben. Er kann nicht für einen entfernten Router bestätigen, dass dessen Import-Policy die Route angenommen hat. Und er kann nicht für den Endpunkt bestätigen, dass dort die vorgesehene Funktion existiert.

RFC 10038 schafft für den ersten Teil ein gemeinsames Verfahren. Innerhalb einer einzigen vertrauenswürdigen SR-Domäne kann ein SRv6 Locator per DHCPv6 an einen SRv6 Segment Endpoint Node verteilt werden. Ein verwaltetes CPE darf sich dabei physisch beim Kunden befinden. Die neuen Werte sind in den IANA DHCPv6 Parameters registriert.

OPTION_IA_SRV6_LOCATOR mit Code 149 enthält IAID, T1, T2 und verschachtelte Optionen. Mehrere Instanzen sind möglich; ihre IAIDs müssen in einem von anderen IA-Typen getrennten Nummernraum eindeutig sein. Darin liegt OPTION_IALOCATOR mit Code 150. Diese Option trägt preferred und valid lifetime, Algorithm, LB-Len, LN-Len, Fun-Len, Arg-Len und den minimal codierten Locator.

LB-Len plus LN-Len ergibt die Locator-Länge. Die Summe aller vier Längen darf 128 nicht überschreiten, und die Locator-Länge darf nicht null sein. Eine verletzende Option ist ungültig. Ein korrektes Format ist jedoch nur eine Aussage über die Nachricht, nicht über den Datenpfad.

Ein Hint ändert nicht die Zuständigkeit

Der Client soll T1, T2 sowie preferred und valid lifetime normalerweise mit null senden. Der Server ignoriert clientseitig gesetzte Werte in diesen Feldern und bestimmt die Zeiten. Nicht-null LB-Len und LN-Len zusammen mit :: können einen Größenwunsch ausdrücken. Dieser Wunsch verpflichtet den Server weder zu einem bestimmten Präfix noch zu einem Layout oder einer Laufzeit.

Pool, Mehrfachvergabe und Ablehnung unterliegen der Server-Policy. Fehlt eine Ressource, kann NoSRv6LocatorAvail, Status 23, folgen. Ein Locator mit einer preferred lifetime oberhalb der valid lifetime muss der Client verwerfen. Aus der Reihenfolge mehrerer Locators darf er keine Priorität oder Dienstlogik ableiten.

RFC 9915 stellt den DHCPv6-Rahmen mit Solicit, Advertise, Request, Reply, Renew, Rebind und Release bereit. Er belegt eine Adressierungs- und Bindungstransaktion. Eine Quittung des Routingprotokolls ist darin nicht enthalten.

Der Locator ist auch keine gewöhnliche Hostadresse und kein vollständiger SID. RFC 8402 definiert die Segment-Routing-Architektur; RFC 8986 beschreibt SRv6 Endpoint Behaviors und SID-Struktur. Lokale SID-Vergabe, die Nutzung mehrerer Locators und die Ankündigung einzelner SIDs liegen außerhalb von RFC 10038. Der Zielknoten behält seine lokale Gestaltungs- und Betriebsautorität.

Die Bindung startet, aber ersetzt nicht das Routing

Ein DHCPv6-Relay oder -Server kann lokal eine Locator-Route installieren, deren Next Hop auf den anfragenden Knoten zeigt. Danach kann er diese Route mit einem herkömmlichen Routingprotokoll ankündigen. Es handelt sich um zwei betriebliche Schritte, nicht um automatisch ausgeführte Bestandteile des Reply.

Nach der Ankündigung prüfen Nachbarn Authentisierung, Importregeln und Topologie. Ihre RIBs wählen oder verwerfen den Pfad. Die Plattformen schreiben die Auswahl in ihre FIB. Eine Route kann am Ursprung vorhanden und anderswo gefiltert sein; sie kann in der RIB stehen und wegen Verzögerung oder Ressourcenmangel in der FIB fehlen.

Algorithm null nutzt normale IPv6-Präfixerreichbarkeit. Bei einem Algorithm ungleich null sind die von RFC 10038 bezeichneten Locator-TLVs erforderlich. RFC 9350 zeigt, dass IGP Flexible Algorithms topologische Bedingungen tragen. Wer lediglich das Präfix weitergibt, kann die Bits erhalten und zugleich die beabsichtigte Pfadsemantik verlieren.

Am Endpunkt regelt RFC 8754 den IPv6 Segment Routing Header, RFC 8986 das Verhalten. Der Knoten kann erreichbar sein, ohne den erwarteten SID zu besitzen. Er kann eine andere Funktion ausführen oder den Verkehr filtern. Vergabe, Weiterleitung und Dienstberechtigung sind deshalb drei unterschiedliche Aussagen.

Eine Freigabe muss durch das Netz zurücklaufen

Bei einem gültigen Release muss die vergebende Stelle die Bindung freigeben, ihre lokale Route entfernen und die zuvor angekündigte Route zurückziehen. Diese Vorgänge liegen in unterschiedlichen Systemen und teilen keine atomare Transaktion. „Im Pool frei“ bedeutet nicht „aus jeder RIB und FIB verschwunden“.

Die IA hat keine eigene, darüberliegende Laufzeit; sie endet, wenn sämtliche darin enthaltenen Locators enden. T1 richtet die Erneuerung zunächst an den ursprünglichen Server, T2 an einen verfügbaren Server. Lifetimes zählen verbleibende Sekunden, 0xffffffff bedeutet unendlich. Sie messen die administrative Gültigkeit, nicht das letzte Paket.

Aggregation verschiebt den Ort des Nachweises. Ein weiterhin angekündigtes Aggregat kann Pakete trotz Rückzug des spezifischen Locators zur delegierenden Kante transportieren. Dort müssen nicht mehr delegierte Präfixe an der kundenseitigen Schnittstelle verworfen werden. Andernfalls bleibt die alte Weiterleitungsautorität hinter dem Aggregat bestehen.

Vor einer Wiedervergabe sind Bindung, lokale Route, Ankündigung, entfernte RIB/FIB-Zustände, lokale SIDs, erlaubte und verbotene Canaries sowie das letzte Paket abzugleichen. Eine Quarantäne trennt den alten vom neuen Inhaber.

Vertrauen ist ein Geltungsbereich, kein Sicherheitsbeweis

Die Annahme einer vertrauenswürdigen SR-Domäne beschreibt den Einsatzraum. Sie schafft keine universelle Ende-zu-Ende-Verschlüsselung für DHCPv6 und authentisiert nicht jedes Paket. Ohne zusätzliche Schutzmaßnahmen bleiben Entführung, Manipulation und Abhören möglich. Grenz-CPEs brauchen Filter an internen und externen Schnittstellen; Infrastruktur-Locator-Raum sollte von gewöhnlichen Endnutzeradressen unterscheidbar sein.

Zwei Zuteilungssysteme können denselben Locator vergeben, wenn ihre Pools nicht getrennt sind. Ein Limit pro Client verhindert nicht unbedingt viele vorgetäuschte Clients. RFC 7227 und RFC 8168 verlangen Disziplin bei neuen Optionen und adressspezifischer Semantik; RFC 8987 ergänzt den betrieblichen Rahmen für SRv6 Network Programming. Die IANA-Registrierung schafft ein gemeinsames Protokollwort, aber keine geprüfte Poolgrenze.

Ein gemeinsames Journal verbindet Vertrag und Wirkung

Zu jedem Locator gehören DUID, IAID, Port- oder Relay-Kontext, Autorisierung, Policy-Version, angefragter Hint, gewährtes Layout, Transaktionszeiten, Lifetimes, T1/T2, Bindungszustand und Pool-Eigentümer. Hinzu kommen lokale SIDs, RIB/FIB-Route und Next Hop am Ursprung, IGP-Typ, Algorithm und Version, entfernte RIB/FIB-Beobachtungen, Filter, erlaubte und verbotene Paket-Canaries sowie Release oder Ablauf, Rückzug, letztes Paket, Quarantäne und Wiedervergabe.

Heng Lus Prinzip vom Vorrang des laufenden Codes legt den Beweis in diesen ausgeführten Pfad. Seine Unterscheidung zwischen technischer und praktischer Datenhoheit erklärt, warum der Besitzer der Bindungsdatenbank die verteilten Routenkopien nicht beherrscht. Sein Modell einer minimalen Anfangsspezifikation mit lokalisierten Folgeentscheidungen passt zur Grenze: Das Protokoll vereinheitlicht die Übergabe; lokale Betreiber verantworten Annahme, Route, Filter und Ergebnis.

RFC 10038 macht die Vergabe präziser. Er macht die Erreichbarkeit nicht automatisch wahr.