Zusammenfassung

  • RFC 10038 lässt einen SRv6-Segment-Endpunkt über DHCPv6 einen strukturierten Locator beziehen, einschließlich Laufzeiten, Algorithmus und Feldern des Locator-Aufbaus.
  • Weil eine Zuteilung eine Locator-Route erzeugen und bekannt geben kann, werden Erneuerung, Freigabe und Ablauf zu Ereignissen des Routing-Zustands statt zu bloßer Adresspflege.

Der Lease hinter der SID

Im SRv6 hat der Locator eine strukturelle Aufgabe. Er bezeichnet den Adressraum, aus dem ein Knoten Segment Identifiers zuteilt, und bestimmt damit mehr als die Erreichbarkeit einer Schnittstelle. RFC 10038 überträgt diese Struktur in zwei neuen DHCPv6-Optionen. IA Locator enthält bevorzugte und gültige Laufzeit, einen IGP-Algorithm-Wert, die Längen von Locator-Block und Knotenteil, Function- und Argument-Längen sowie die Locator-Bytes selbst.

Diese Felder platzieren eine Entscheidung an der Zuteilungsgrenze. Der Client kann eine Präferenz nennen, doch der Server durchsucht seinen konfigurierten Locator-Pool und erzeugt die Bindung nach seiner Richtlinie. Die Summe der Strukturlängen darf 128 Bit nicht überschreiten; Locator-Block und Knotenteil dürfen zusammen nicht null sein. Ein Client muss einen Locator verwerfen, dessen bevorzugte Laufzeit die gültige Laufzeit übersteigt. Das sind Protokollfakten, aber kein Nachweis, dass ein bestimmtes Produkt sie korrekt prüft.

IANA hat die Optionscodes 149 und 150 sowie Statuscode 23, NoSRv6LocatorAvail, vergeben. Eine negative Antwort ist damit ein definiertes Ergebnis und keine Aufforderung, lokal einen Locator zu erfinden. Die Spezifikation schreibt weder die Pool-Gestaltung vor noch entscheidet sie, welche Organisation eine Zuteilung genehmigen darf.

Ein Lease-Wechsel kann zum Routenwechsel werden

Der Lebenszyklus folgt DHCPv6: Solicit, Advertise, Request und Reply begründen eine Bindung; Renew und Rebind sollen sie erhalten; Release gibt sie zurück. Bleibt nach Ablauf des maßgeblichen Timers eine Antwort aus, betrachtet der Client den Lease als abgelaufen und beginnt neu. Nach gültiger Freigabe oder Ablauf nimmt der Server den Locator zurück.

RFC 10038 greift dann in das Routing ein. Server oder Relay dürfen eine lokale Route für den zugeteilten Locator installieren, den anfragenden Client als nächsten Hop setzen und die Route über ein IGP bekannt geben. Eine Freigabe verlangt, die lokale Route zu entfernen und die vorherige Bekanntgabe zurückzunehmen. Locator mit Algorithm null können gewöhnliche IP-Erreichbarkeit verwenden; andere Werte benötigen die für IS-IS oder OSPFv3 definierten Locator-TLVs.

Die betriebliche Folgerung lautet: Lease-Verzeichnis, RIB-Eintrag und IGP-Ankündigung sind verschiedene Darstellungen einer Befugnisentscheidung. In der Umsetzung können sie dennoch auseinanderlaufen. Eine erfolgreiche DHCP-Antwort beweist nicht, dass die Route installiert, verbreitet, in der Weiterleitung programmiert oder durchgängig nutzbar ist. Umgekehrt würde eine nach Ablauf der Bindung verbliebene Route Erreichbarkeit anzeigen, obwohl die Zuteilungsbefugnis beendet ist. Hier wird nicht behauptet, dass einer dieser Fehler in einem benannten Netz eingetreten ist.

Aggregation verändert die Form des Fehlers

RFC 10038 beschreibt einen Stabilitätskonflikt. Aggregierte Ankündigungen können die RIB bei Änderungen einzelner Leases beruhigen. Ein zurückgenommener spezifischer Locator kann jedoch weiter von einem Aggregat abgedeckt sein; Datenverkehr zu einem Präfix, das an der Kundenschnittstelle nicht mehr delegiert ist, kann dort verworfen werden. Das Aggregat erhält grobe Erreichbarkeit, obwohl die konkrete Befugnis verschwunden ist.

Für die Überwachung ist dieser Unterschied wesentlich. Wer ein Aggregat als Beleg für jeden darunterliegenden Locator wertet, verwechselt eine Routing-Zusammenfassung mit dem zugrunde liegenden Lease-Zustand. Betreiber brauchen beide Ansichten: die Aggregationsrichtlinie zum Schutz der RIB und den Bindungszustand, der erklärt, ob ein bestimmter Locator noch an einem bestimmten Endpunkt enden soll.

Sicherheit beginnt bei der Zuteilungsbefugnis

RFC 10038 übernimmt die DHCP-Sicherheitshinweise und nennt ausdrücklich das Fehlen einer Ende-zu-Ende-Verschlüsselung zwischen DHCP-Clients und Servern. Ohne andere Schutzmaßnahmen bleiben Übernahme, Manipulation und Abhören möglich. Gemischte Zuteilungsverfahren können außerdem denselben Locator mehreren Geräten zuweisen. Getrennte Pools sind eine Gegenmaßnahme.

Der Standard macht aus einem DHCP-Austausch keinen Beleg organisatorischer Genehmigung. Dieser Nachweis bleibt lokal: Welche Server und Relays waren vertrauenswürdig, welche Client-Identität wurde zugelassen, welcher Pool und Algorithmus waren genehmigt und welcher Änderungsnachweis erklärt die Bindung? Protokollgültigkeit und geschäftliche Befugnis sind unterschiedliche Beweise.

Quellen