Zusammenfassung

  • RFC 10038 definiert eine DHCPv6-Identity-Association für SRv6-Locators mit IAID, Locator-Struktur, bevorzugter und gültiger Laufzeit, T1/T2, Serverbindung und einem eindeutigen Ergebnis bei fehlender Verfügbarkeit.
  • Eine gültige Reply führt zur Konfiguration des Locators am Client. Lokale Routeninstallation und Protokollankündigung sind getrennte optionale Schritte; lokale SID-Zuteilung, Mehrfachnutzung und SID-Ankündigung liegen außerhalb des Geltungsbereichs.
  • Weiqiang Cheng und Changwang Lin editierten die RFC; Ruibo Han, Daniel Voyer und Geng Zhang sind Mitautoren, Yuanxiang Qiu ist Mitwirkender. Das Dokument ist gemeinsame Standardisierung, kein Nachweis persönlicher Erfindung oder eines bestimmten Einsatzes.

Normative Verben sind keine Stilfrage. Nach einer gültigen Reply muss der Client den zugewiesenen Locator verarbeiten und konfigurieren. Ein DHCPv6-Relay oder -Server darf anschließend eine entsprechende lokale Route installieren und darf sie über ein traditionelles Routingprotokoll ankündigen.

Zwischen diesen Aussagen befindet sich die Verantwortung des Betreibers.

RFC 10038 wurde im August 2026 auf dem IETF Standards Track veröffentlicht. Sie erweitert DHCPv6 um IA_SRV6_LOCATOR, die IA-Locator-Option und NoSRv6LocatorAvail. Damit erhält die Zuteilung eine identifizierbare Transaktion, Struktur und Zeit. Sie wird aber nicht zum versteckten Routingprotokoll.

Auch die persönliche Zuordnung bleibt begrenzt. Weiqiang Cheng und Changwang Lin sind Editoren, Ruibo Han, Daniel Voyer und Geng Zhang weitere Autoren, Yuanxiang Qiu ist Mitwirkender. Chengs am 31. August 2026 erfasstes IETF-Profil nannte ihn Chief Architect of IP Networks am China Mobile Research Institute, Vorsitzenden der Arbeitsgruppe SRv6 Operations und Autor von neun RFCs. Das belegt öffentliche Standardisierungsarbeit, nicht einen Einsatz bei China Mobile oder einem anderen benannten Netz.

Ein Lease mit Identität, Struktur und Zeit

Die IAID unterscheidet die Locator-Association von anderen Associations desselben Clients. T1 gibt an, wann der Client den ursprünglichen Server zur Verlängerung kontaktieren soll. Nach T2 kann er sich an einen beliebigen verfügbaren Server wenden. Die gekapselte Locator-Option enthält bevorzugte und gültige Laufzeit, die Längen von Locator Block, Locator Node, Function und Argument sowie den Algorithm-Wert.

Ein prüfbarer Datensatz muss daher mehr als den IPv6-Präfix enthalten. Er braucht Client, IAID, Relay, Server, Antwort, Struktur und verbleibende Zeit. Renew und Rebind verlängern einen bekannten Zusammenhang. Release oder Ablauf beenden ihn; der Server nimmt den Präfix zurück und löscht die Bindung.

Zwischen aktiv und abgelaufen liegen wichtige Zustände. Die bevorzugte Laufzeit kann enden, während der Locator weiterhin gültig ist. T1 kann überschritten sein, T2 aber noch nicht. Eine zweifarbige Anzeige verliert diese Phasen und lässt erwartete Übergänge wie plötzliche Fehler aussehen.

Nach der gültigen Reply konfiguriert der Client den Locator. Die RFC bestimmt jedoch nicht, wie lokale SIDs daraus entstehen, wie mehrere Locators verwendet oder diese SIDs angekündigt werden. Aus der Reihenfolge der Locators darf keine Dienstlogik abgeleitet werden. Die gemeinsame Nachricht liefert Struktur, keine heimliche Priorität.

Routing beginnt mit einem neuen Objekt

Abschnitt 5.5 beschreibt die optionale lokale Route. Ihr nächster Hop sollte auf den anfragenden Client zeigen. Danach kann das Relay oder der Server die Route so ankündigen, dass andere Router sie lernen.

Eine Serverbindung beweist also keine RIB-Route. Eine RIB-Route beweist keine FIB-Programmierung. Eine lokale Route beweist keine Freigabe durch die Exportrichtlinie. Eine gesendete Ankündigung beweist keine Konvergenz bei allen Empfängern. Und Konvergenz beweist weder SID- noch SR-Policy-Zustand am CPE oder die Zustellung eines Pakets.

Der Algorithm-Wert entscheidet außerdem über die Form. Null erlaubt normale IP-Präfix-Reachability. Ein Wert ungleich Null verlangt die Locators TLV aus RFC 9352 oder RFC 9513. Wer den Wert verwirft und alles als gewöhnlichen IPv6-Präfix exportiert, entfernt eine für die Berechnung nötige Beziehung.

Ein belastbarer Nachweis hält deshalb Serverbindung, Clientkonfiguration, RIB, FIB, Ankündigungsform, Konvergenz, SID, Policy, Filter und Paketbeobachtung getrennt. Locator und IAID korrelieren die Einträge; sie machen sie nicht bedeutungsgleich.

Release zeigt, ob die Kopplung umkehrbar ist

Bei einer Release muss der Locator freigegeben, die lokale Route entfernt und die frühere Ankündigung zurückgezogen werden. Beim Ablauf nimmt der Server den Präfix zurück und löscht die Bindung. Diese klare Vorgabe durchläuft mehrere Systeme mit eigener Zuständigkeit.

Der Server kennt die Association. Das Zugangsgerät kennt den nächsten Hop. Das Routing besitzt Ankündigung und Konvergenz. CPE und Controller können SID-, Policy- und Cachezustand halten. Die Abwicklung braucht einen Korrelationsschlüssel, der aus der beendeten IAID alle abhängigen Zustände ableitet.

Aggregation verändert den sichtbaren Rückzug. Ein Betreiber darf zur Entlastung der RIB eine aggregierte Route statt einzelner Locators ankündigen. Nach Freigabe eines konkreten Präfixes kann das Aggregat bestehen bleiben; der delegierende Router verwirft dann Verkehr für nicht mehr delegierte Präfixe.

„Aggregat vorhanden“ und „einzelner Lease ungültig“ sind gleichzeitig möglich. Der korrekte Test vergleicht die Menge gültiger Delegationen, den Umfang des Aggregats und die Paketbehandlung am Rand. Ein definierter Drop kann der sichere Sollzustand sein.

Vertrauen ist eine überprüfbare Annahme

Das Szenario setzt eine einzige vertrauenswürdige SR-Domain voraus. Der CPE wird vom Betreiber oder einem vertrauenswürdigen Partner verwaltet; auch beim Kunden bleiben Gerät und Ports unter der administrativen Kontrolle des Betreibers.

DHCPv6 besitzt standardmäßig keine Ende-zu-Ende-Verschlüsselung. Entführung, Manipulation und Mithören bleiben möglich. Parallele Zuteilungsmechanismen benötigen nicht überlappende Pools, sonst kann derselbe Locator mehrfach verwendet werden. Ein Limit pro Client verhindert nicht vollständig, dass ein Angreifer viele Clientidentitäten vortäuscht.

Der DHCPv6-Client am Rand muss interne und externe Schnittstellen filtern. Ein Eintrag „trusted“ ersetzt weder Portkontrolle noch Adressraumtrennung oder aktuelle Filterregeln. Vertrauen ist ein laufender Kontrollzustand.

Vom Verwaltungsakt zum laufenden Ergebnis

Heng Lus Running-Code Primacy setzt die Reihenfolge richtig: Die Bindung beschreibt eine Zuteilung, erzeugt aber keine Route durch Autorität. Minimum Initial Specification verlangt einen strengen gemeinsamen Kern nur für Interoperabilität und Sicherheit und lässt künftige lokale Entscheidungen beim Betreiber.

RFC 10038 standardisiert Codes, Formate, Zeiten sowie Client-, Server- und Relayverhalten. Sie entscheidet nicht über SID-Plan, Aggregation oder Dienstpolitik eines Netzes. Wo der gemeinsame Vertrag endet, beginnt die Pflicht zu lokaler Evidenz.

Ein reproduzierbarer Beleg verbindet Clientidentität, IAID, Relay, Server, Locator, Struktur, Algorithm, T1/T2, Laufzeiten, Bindung, Clientkonfiguration, Route, Ankündigung, Konvergenz, SID, Policy, Filter und einen begrenzten Paketversuch. Beim Release wird dieselbe Kette rückwärts geprüft.

„Locator zugeteilt“ ist eine präzise Aussage. „Route installiert und verteilt“ ist eine zweite. „Paket unter dokumentierten Bedingungen zugestellt“ ist eine dritte. Die gemeinsame Arbeit von Cheng und den Mitautoren macht die erste prüfbar, ohne sich die anderen anzueignen.

Quellen