Stateless Ingress: Orchestrating Local-to-Cloud Tunnels via IPv6 Segment Routing (SRv6)

Stateful Edge-Proxys sind die primäre Engstelle für Hochdurchsatz-Tunneling. IPv6 Segment Routing (SRv6) integriert Routing-Logik direkt in den Paket-Header und eliminiert so die Edge-State-Engstelle vollständig.

---

Die Engstelle im Edge Computing

In modernen verteilten Architekturen ist der Netzwerk-Edge enorm komplex geworden — belastet durch Reverse Proxys, Load Balancer, NAT-Gateways und zustandsbehaftete Firewalls. Wenn ein Paket an einer Cloud-Grenze ankommt, das für eine lokale Entwicklungsumgebung, einen internen Microservice oder ein On-Premise-Gerät bestimmt ist, muss ein zentraler Ingress-Controller es abfangen, die Verbindung beenden, eine Routing-Status-Datenbank oder In-Memory-Tabelle konsultieren und die Nutzlast in einen Tunnel kapseln.

Diese zustandsbehaftete Verarbeitung bildet seit über einem Jahrzehnt die Grundlage für die Web-Traffic-Auslieferung. Bei hohen Durchsatzraten und ultra-niedrigen Latenzanforderungen wird sie jedoch zur fatalen Engstelle. Die Rechenkosten für die Pflege von Status-Tabellen begrenzen die Skalierbarkeit und erhöhen die Paket-Latenz.

SRv6 durchbricht dieses Paradigma grundlegend. Vom IETF im Februar 2021 als RFC 8986 standardisiert, ermöglicht das SRv6 Network Programming-Framework einem Netzwerkbetreiber oder einer Anwendung, ein Paketverarbeitungsprogramm durch Codierung einer Sequenz von Anweisungen direkt im IPv6-Paketheader zu spezifizieren. Jede Anweisung wird durch eine SRv6 Segment Identifier (SID) identifiziert und auf einem oder mehreren Knoten im Netzwerk ausgeführt — kein zentraler Zustandsautomat erforderlich.

Anstatt auf eine monolithische Middleware-Appliance zu setzen, die jeden aktiven Tunnel und Fluss verfolgt, embedden die SR-Headend-Knoten explizite Routing-Anweisungen — sogenannte Segments — direkt in den IPv6-Paketheader. Transit-Router müssen nichts über Tunnel wissen; sie führen die Header-Anweisungen in Hardware in Sequenz bei Line-Rate aus. Durch das Verschieben des Zustands aus der Appliance in das Paket selbst erreichen Architekten echtes stateless network ingress.

---

Das Engpass-Problem bei zustandsbehafteten Proxys in Hochdurchsatz-Umgebungen

Um den Wert von SRv6 voll zu erfassen, betrachten wir die tatsächlichen Kosten zustandsbehafteten Ingresses in großem Maßstab. Tools wie Nginx, HAProxy, Envoy oder Hardware Application Delivery Controller (ADCs) sitzen an der Cloud-Grenze. Beim Eintreffen eines eingehenden Pakets muss der Proxy eine 5-Tupel-Lookup (Quelle IP, Ziel IP, Quellport, Zielport, Protokoll) gegen eine Verbindung-Status-Tabelle durchführen, um zu bestimmen, zu welchem Tunnel das Paket gehört.

Das Pflegen dieses Zustands ist teuer. Wenn die Anzahl der gleichzeitigen Tunnel in die Zehntausende oder Hunderttausende wächst, wachsen auch die Status-Tabellen entsprechend. Der Proxy muss TCP-Verbindungszustände — SYN, ESTABLISHED, FIN, WAIT — kontinuierlich verfolgen, Speicher für verworfene Verbindungen freigeben und Puffer für unterschiedliche MTU-Größen verwalten.

Die Hub-and-Spoke-Architektur zwingt den Traffic zudem durch einen zentralen Inspektionspunkt, was eine optimale kürzeste Pfad-Routing-Entscheidung im Netzwerk verhindert. Jedes Paket muss vor dem Ziel den Load Balancer umfahren — ein Phänomen namens Tromboning — was Latenz und Durchsatzbegrenzungen verursacht, die besonders bei Echtzeit-Datenpipelines schädlich sind.

---

Die Mechanik des SRv6 Network Programming

Die Lösung liegt in der nativen Programmierbarkeit von IPv6. SRv6 nutzt den 128-Bit-Adressraum von IPv6, um nicht nur Netzwerk-Endpunkte, sondern auch spezifische Weiterleitungsoperationen zu codieren.

In einem SRv6-fähigen Netzwerk wird eine IPv6-Adresse als Segment Identifier (SID) verwendet. Wie in RFC 8986 (Abschnitt 3.1) definiert, ist ein standardmäßiger 128-Bit SRv6 SID in drei logische Komponenten gegliedert:

Locator (B:N): Die wichtigsten Bits, die die Netzwerkadresse des SRv6-fähigen Knotens darstellen. Diese werden nativ via Interior Gateway Protocols — IS-IS oder OSPFv3 — mit SRv6-Erweiterungen geroutet. Der Locator wird als B:N ausgedrückt, wobei B der vom Betreiber zugewiesene SRv6 SID-Block ist und N den spezifischen Knoten identifiziert.

Function: Ein eindeutiger Bezeichner für die genaue Operation, die der Zielknoten beim Eintreffen des Pakets ausführt.

Argument (ARG): Optionales Metadatenfeld, das an die Funktion übergeben wird, um Verhaltensvariationen am Zielort ohne zusätzliche Signalisierung zu ermöglichen.

Wenn ein Paket am Netzwerk-Edge ankommt, kapselt der SR-Headend-Knoten es mit einem spezialisierten IPv6-Extension-Header namens Segment Routing Header (SRH), standardisiert in RFC 8754 (März 2020). Dieser Header trägt eine geordnete Segment-Liste von SIDs. Während das Paket durch das Netzwerk traversiert, inspiziert jeder SRv6-fähige Knoten den aktiven SID. Wenn der Locator mit dem eigenen konfigurierten Locator-Block übereinstimmt, führt der Knoten die entsprechende Function aus.

RFC 8986 definiert eine Grundmenge standardisierter Endpunkt-Verhaltensweisen. Die wichtigsten operational relevanten sind:

• End: Die grundlegende Transitfunktion. Der Knoten dekrementiert den Segments Left-Zähler, aktualisiert die IPv6-Zieladresse mit dem nächsten SID in der Liste und leitet basierend auf einer IGP FIB-Lookup an der neuen DA weiter.
• End.X: Aktualisiert das aktive Segment und verbindet den Paketfluss explizit an einer bestimmten Layer-3-Adjazenz — essentiell für Traffic Engineering mit strengen Pfadbeschränkungen.
• End.DX4 / End.DX6: Der Knoten decapsuliert den äußeren IPv6-Header und leitet die innere IPv4- oder IPv6-Nutzlast an den nächsten Hop weiter. Dies ist die Schlüssel-Funktion für die direkte Zustellung getunnelter Daten an den lokalen Endpunkt.
• H.Encaps (Headend Encapsulation): Ein Ingress-Verhalten, das ein eingehendes IP-Paket in einen äußeren IPv6-Header mit SRH einschließt, der die vollständige Segmentliste enthält. Dies ist die Funktion, die am zustandslosen Ingress-Edge angewandt wird.

---

Erreichen eines zustandslosen Ingress: Eliminierung der Middleware

Durch das Verketten dieser Verhaltensweisen können Architekten ein Ingress-Modell einsetzen, das null Zustandsinformationen pro Fluss vom Netzwerk-Edge verlangt.

Der SR-Headend empfängt ein eingehendes Paket vom Internet oder einem Peering-Partner. Anstatt die TCP-Verbindung zu beenden oder eine Status-Tabelle zu konsultieren, führt der Ingress-Knoten eine einzelne, hardware-accelerierte Policy-Übereinstimmung durch — typischerweise verteilt via BGP — und wendet sofort H.Encaps an. Die Nutzlast wird in einen IPv6-Header eingekapselt, der die genaue SID-Liste trägt, um das Ziel zu erreichen.

Transit-Router im Kern kennen die Tunnel nicht, führen keine Verbindungszustände, und haben keine pro-Fluss-Einträge zu aktualisieren. Sie schauen nur auf die aktive IPv6-Zieladresse und leiten basierend auf dem kürzesten IGP-Pfad weiter. Der pro-Fluss-Zustand wird im Kern vollständig eliminiert.

Am Endknoten — einem Provider-Edge-Router, einem On-Premise-Gateway oder einem Entwickler-Arbeitsplatz mit SRv6-fähigem Netzwerkstack — entfernt die Funktionen End.DX4 oder End.DX6 den äußeren IPv6-Header und SRH, um die ursprüngliche Nutzlast direkt an die lokale Anwendungsschnittstelle zu liefern.

Open-Source-Implementierungen

Zwei produktionsreife Open-Source-Stacks machen SRv6 zugänglich für Labore und softwaredefinierte Deployments:

Linux Kernel: SRv6-Unterstützung wurde in Kernel 4.10 eingeführt (Encapsulation) und mit seg6local Endpunkt-Verhaltensweisen in Kernel 4.14 erweitert. Das Standard-iproute2-Werkzeugset bietet SRv6 via encap seg6 (Source Routing) und encap seg6local (Endpunkt-Funktionen). Der Linux Kernel unterstützt inzwischen die meisten RFC 8986-Verhaltensweisen und integriert SRv6 mit eBPF, Netfilter, FRRouting, Cilium und SONiC.

FD.io VPP (Vector Packet Processing): VPPs SRv6-Implementierung unterstützt das vollständige Set an RFC 8986 LocalSID-Verhaltensweisen — End, End.X, End.DX4, End.DX6, End.DT4, End.DT6, End.DX2 und mehr — sowie SR Policy-Steering mit T.Insert und T.Encaps. VPP verarbeitet Pakete in Vektoren durch seine DPDK-basierte Datenebene und erreicht hardware-ähnliche Weiterleitungsraten in Software.

---

Traffic Engineering, Flex-Algo und uSID-Kompression

Ersetzen von RSVP-TE durch Source Routing

Altes Traffic Engineering basierte auf RSVP-TE (Resource Reservation Protocol — Traffic Engineering, RFC 3209), einem zustandsbehafteten Signalisierungsprotokoll, das von jedem Router entlang eines Pfades aktiv Bandbreite reservieren und Tunnel-Zustand pflegen muss. Im großen Maßstab verursacht der Steuerungskanal von RSVP-TE erheblichen CPU-Overhead bei Kernroutern.

SRv6 erreicht dasselbe granulare Traffic Engineering zustandslos durch Source Routing. Der SR-Headend legt den gesamten Weiterleitungsweg fest, indem er SIDs in der SRH stapelt. Kern-Router benötigen keine Signalisierungszustände. Für weitere Optimierungen verwenden moderne SRv6-Implementierungen Flexible Algorithm (Flex-Algo), standardisiert in RFC 9350 (Februar 2023, Standards Track).

Flex-Algo erlaubt es Netzwerkbetreibern, mehrere logische Routing-Topologien über die gleiche physische Infrastruktur zu berechnen, indem sie auf Constraint-basierte Algorithmen setzen. Wie in RFC 9350 spezifiziert, ist in SRv6 der Locator — nicht der SID — das Bindeglied zum Algorithmus. Ein Knoten wird mit einem eigenen Locator für jedes (Topologie, Algorithmus)-Paar konfiguriert, das er unterstützt. Zum Beispiel:

• Algorithmus 128 könnte Pfade berechnen, die strikt für minimale Faser-Latenz optimiert sind.
• Algorithmus 129 könnte Pfade berechnen, die Links mit einer bestimmten administrativen Gruppierung ausschließen.

Wenn der zustandslose Ingress-Knoten ein Paket kapselt, wählt er den Locator-Block, der mit dem gewünschten Flex-Algo verbunden ist, um sicherzustellen, dass kritischer Traffic den constraint-konformen Pfad nimmt, ohne zentrale Signalisierung von Zustandsänderungen im Netzwerk.

Header-Overhead mit RFC 9800 (uSID) überwinden

Eine der echten Herausforderungen früher SRv6-Implementierungen war der Encapsulation-Overhead. Jeder SID ist eine vollständige 128-Bit IPv6-Adresse. Laut Huawei-Dokumentation zur SRH-Struktur beträgt die SRH-Länge (n × 16 + 8) Bytes, wobei n die Anzahl der Segmente ist. Ein 6-Hop-Pfad benötigt allein 104 Bytes für die SRH — zusätzlich zum standardmäßigen 40-Byte IPv6-Outer-Header. Für Pfade mit expliziten Hop-by-Hop-Beschränkungen kann dieser Overhead die MTU-Fragmentierung erzwingen und die Hardware-ASIC-Throughput auf Plattformen mit festen Parsing-Puffern verschlechtern.

Die Lösung ist Compressed SRv6 Segment List Encoding, offiziell veröffentlicht als RFC 9800 (Standards Track, Juni 2025), das RFC 8754 aktualisiert. RFC 9800 definiert die Endpoint-Verhaltensweisen NEXT-CSID und REPLACE-CSID, die häufig im micro-SID (uSID)-Architektur eingesetzt werden.

Anstelle eines separaten 128-Bit-SID pro Hop packt RFC 9800 mehrere komprimierte SIDs (C-SIDs) in einen einzigen 128-Bit-Container. Mit einem 32-Bit-Locator-Block (GIB) und 16-Bit-C-SIDs trägt ein einzelner 128-Bit-Container bis zu sechs unterschiedliche Weiterleitungsanweisungen. Das Kernverfahren ist „Shift-and-Lookup“: Wenn ein Knoten seinen C-SID verarbeitet, verschiebt er die verbleibenden C-SIDs im Container und führt eine FIB-Lookup mit der nächsten durch — was das Dekrementieren von Segments Left für Micro-Segmente überflüssig macht.

Wichtig: uSID-Kompression ist transparent für transitierende Knoten, die kein SRv6 unterstützen; sie sehen nur eine standardmäßige IPv6-Zieladresse. Das ermöglicht eine inkrementelle Einführung: Nur SR-fähige Endpunkte müssen die komprimierte Codierung unterstützen, während der Rest des Netzwerks Pakete mit Standard-IPv6-Weiterleitung weiterleitet.

Die Interoperabilität verschiedener Anbieter für uSID wurde 2023 vom European Advanced Networking Test Center (EANTC) validiert, mit Beteiligung von Arista, Arrcus, Cisco, Huawei, Juniper, Nokia, Keysight und Spirent. Die Tests 2024 konzentrierten sich speziell auf uSID-Micro-SID-Szenarien.

---

Migrationsstrategien und gemischte Umgebungen

Der Übergang von einer legacy Ingress-Architektur zu SRv6 erfordert bewusste Planung, insbesondere dort, wo SRv6-unaware Endpunkte noch existieren.

Nicht alle Ziel-Workloads können SRv6-Header verarbeiten. Für diese Endpunkte sitzt ein lokaler Proxy direkt vor dem legacy-Workload, der als finales SRv6-Segment-Ende fungiert. Er beendet die Segment-Liste, entfernt IPv6- und SRH-Header und leitet den ungekapselten IP-Verkehr an die Anwendung weiter. Obwohl technisch ein Proxy eingeführt wird, beschränkt sich der Zustand auf die äußerste Edge — die massiven zentralen Status-Tabellen am primären Cloud-Ingress werden weiterhin eliminiert.

Für SR-MPLS/SRv6-Koexistenz wird ein Binding SID am Gateway des Domain-Netzwerks verwendet, um eine komplette SRv6 SR-Policy auf ein einzelnes MPLS-Label abzubilden, was nahtloses Stitching ermöglicht: Domain A (SR-MPLS) endet am Gateway, das in den SRv6-Domänen re-kapselt. BGP kann beide SIDs gleichzeitig für dasselbe VPN-Präfix signalisieren, sodass das Gateway die Übersetzung übernimmt.

Aus Sicht des Control-Planes vereinfacht SRv6 die Operationen. Anstatt RSVP-TE oder LDP neben einem IGP laufen zu lassen, betreibt ein SRv6-Netzwerk typischerweise einen BGP-freien Kern, der auf IS-IS oder OSPFv3 mit SRv6-Erweiterungen setzt, um Locator-Blocks zu verteilen. BGP Link-State (BGP-LS) exportiert Topologie-Informationen an ein Path Computation Element (PCE), das optimierte Segment-Listen berechnet und sie bei Bedarf an SR-Headend-Knoten via PCEP oder BGP SR-Policy (RFC 9256) verteilt.

Sicherheitsüberlegungen

Das Sicherheitsmodell von SRv6 unterscheidet sich grundlegend von MPLS. MPLS-Labels sind lokal bedeutend und nicht routbar, was die Topologie-Exposition einschränkt. SRv6 SIDs sind global routbare IPv6-Adressen, was die Topologie des Domain-Netzwerks potentiell für Angreifer sichtbar macht, wenn SID-Präfixe nicht ordnungsgemäß gefiltert werden. RFC 8754 (Abschnitt 5) beschreibt das Sicherheitsmodell des SR-Domains: Die häufigste Deployment-Strategie basiert auf iACL-Filtering am Ingress des Domains, um Pakete mit einem SRH Routing Type 4, die von nicht vertrauenswürdigen Quellen kommen, zu blockieren, kombiniert mit uRPF gegen Spoofing.

RFC 9602 (Oktober 2024) weist eine dedizierte IPv6-Präfix für SRv6 SIDs zu und betont, dass Deployments ohne dieses Präfix zusätzliche Vorsichtsmaßnahmen erfordern, um SRv6-Pakete vor Leckagen über Domain-Grenzen hinweg zu schützen. Das laufende IETF-Entwurf draft-ietf-spring-srv6-security (Stand Anfang 2026 bei Revision 14) bietet detaillierte Bedrohungskategorien und Gegenmaßnahmen.

---

Reifegrad des Ökosystems und produktive Deployments

SRv6 ist keine frühe Innovation mehr. Produktive Deployments sind auf mehreren Kontinenten und in verschiedenen Anwendungsfällen im Einsatz:

Telekommunikation und Carrier: SoftBank (Japan) nutzt SRv6 für 5G-Netz-Slicing, um isolierte, eingeschränkte Netzwerkpfade für bestimmte Service-Stufen zu schaffen. Bell Canada hat SRv6 mit uSID im Backbone eingesetzt, mit multivendor Interoperabilität zwischen Cisco, Nokia und Juniper, öffentlich 2023 demonstriert. China Unicom und China Telecom setzen SRv6 großflächig in ihren nationalen Backbones ein.

Hyperscaler: Microsoft präsentierte SRv6 als Schlüsseltechnologie für groß angelegte KI-Backend-Netzwerke auf dem 2025 Open Compute Project (OCP) Global Summit, fokussiert auf das Azure Fairwater DC. Alibaba und Microsoft haben SRv6 uSID-Verbesserungen zum SONiC-Netzwerkbetriebssystem beigetragen, um Hyperscaler-Umgebungen mit SRv6 in SDN-Fabrics zu integrieren. Reliance Jio, in Zusammenarbeit mit Cisco, rollt SRv6 in seinem Netzwerk aus, mit Ziel für 100 Millionen Haushalte und 600 Millionen mobile und Enterprise-Kunden.

Hardware-Unterstützung: Produktive SRv6-Implementierungen existieren bei Cisco ASR 9000/NCS 5500/NCS 540 (IOS XR), Cisco Nexus (NX-OS), Huawei NE40E/NE5000E/NE8000 (VRP), Juniper MX/PTX, Nokia 7750 SR, Arista 7280R3, und Arrcus ArcOS. FRRouting (FRR) 10.5 fügte wichtige SRv6 uSID-Verbesserungen hinzu, inklusive Multi-Locator-Unterstützung, F4816-Format und SRv6 uSID-Locator-Zuweisung pro-VRF.

---

Fazit

Der Übergang von zustandsbehafteter Middleware zu zustandslosem, paketgetriebenem Routing markiert eine fundamentale Reife in der Netzwerktechnik. Mit wachsender Komplexität verteilter Architekturen und zunehmender Telemetrie im lokalen und Cloud-Bereich kann der Netzwerk-Edge nicht mehr als zentraler Zustandsautomat im großen Maßstab funktionieren.

SRv6 — standardisiert durch RFC 8754, RFC 8986, RFC 9350 und zuletzt RFC 9800 — bietet das vollständige Werkzeugset: zustandslose Encapsulation am Headend, constraint-aware Forwarding via Flex-Algo und header-effiziente Lieferung durch uSID-Kompression. Das Steuerungssystem vereinfacht sich auf einen BGP-freien Kern, der auf IS-IS oder OSPFv3 mit SRv6-Erweiterungen setzt, ergänzt durch optionales PCE-basiertes Pfad-Optimierung mittels BGP-LS.

Die praktischen Rahmenbedingungen sind real: SRv6 erfordert IPv6-Infrastruktur im gesamten SR-Domain, SRH-Overhead bleibt eine Design-Constraint auf Plattformen ohne uSID-Unterstützung, und die Sicherheit an Domain-Grenzen erfordert disziplinierte ACL- und uRPF-Konfiguration. Doch das Ökosystem ist in Bewegung. Hardware-Unterstützung in Line-Rate ist bei allen großen Anbietern verfügbar. Hyperscaler setzen es im KI-Training ein. Die IETF-Standards sind vollständig. Für Entwickler, die lokale-to-Cloud-Tunnel-Infrastruktur heute bauen, ist SRv6 keine Zukunftsvision mehr — es ist eine produktionsreife Architekturentscheidung.

---

Referenzübersicht

RFC	Titel	Status	Datum
RFC 8402	Segment Routing Architektur	Standards Track	Juli 2018
RFC 8754	IPv6 Segment Routing Header (SRH)	Standards Track	März 2020
RFC 8986	SRv6 Network Programming	Standards Track	Februar 2021
RFC 9256	Segment Routing Policy Architektur	Standards Track	Juli 2022
RFC 9259	OAM in SRv6	Standards Track	Juni 2022
RFC 9350	IGP Flexible Algorithm	Standards Track	Februar 2023
RFC 9602	SRv6 SIDs in der IPv6 Adressierungsarchitektur	Informational	Oktober 2024
RFC 9800	Komprimierte SRv6 Segment List Codierung	Standards Track	Juni 2025

---

Änderungsprotokoll

Faktencheck gegen Live-Quellen (Juni 2026):

• Datum RFC 8986 korrigiert: Artikel gab kein Datum an; bestätigt Februar 2021 (Standards Track, IETF).
• RFC 8754 ergänzt: Die SRH-Spezifikation (RFC 8754, März 2020) fehlte im Original und ist architektonisch grundlegend; ergänzt überall.
• SRH-Overhead-Formel korrigiert: Ursprünglich hieß es „8 Hops würden 128 Bytes hinzufügen.“ Korrekt ist (n × 16) + 8 Bytes für die SRH, also bei 8 Segmenten 136 Bytes plus 40-Byte IPv6-Header. Korrektur basierend auf Huawei-Dokumentation.
• uSID: RFC-Nummer korrigiert und aktualisiert: Ursprünglich wurde uSID informell ohne RFC-Referenz beschrieben und fälschlich als bereits vollständig in RFC 8986 standardisiert dargestellt. Die Komprimierung wurde als RFC 9800 (Standards Track, Juni 2025) veröffentlicht. Artikel entsprechend aktualisiert.
• Flex-Algo: RFC-Nummer ergänzt: Standardisiert in RFC 9350 (Februar 2023). Klarstellung, dass in SRv6 es der Locator ist, nicht der SID, der an den Algorithmus gebunden ist (siehe RFC 9350 Abschnitt 2).
• Linux Kernel Version korrigiert: Ursprünglich „Kernel v4.10+“ unterstützt SRv6. Korrekt: Kernel 4.10 führte SRv6-Encapsulation ein; seg6local Endpunkt-Verhaltensweisen kamen in Kernel 4.14. Korrektur.
• VPP-Behauptung verifiziert: Unterstützung bei fd.io bestätigt; Verhaltensliste präzisiert (End, End.X, End.DX4, End.DX6, End.DT4, End.DT6, End.DX2, End.B6.Encaps).
• NVIDIA Omniverse-Abschnitt entfernt: Der ursprüngliche Abschnitt enthielt spezifische, nicht belegte Integrationsbehauptungen (z.B. „Omniverse local bridge“ als SRv6-Endpunkt). Keine verifizierte technische Dokumentation unterstützt diese Darstellung. Der Grundgedanke (SRv6 für industrielle Telemetrie) bleibt, die produktspezifischen Claims wurden entfernt.
• Produktive Deployments ergänzt: SoftBank, Bell Canada, China Unicom, China Telecom, Microsoft Azure, Alibaba, Reliance Jio, und das SONiC-Ökosystem. Quellen: IETF-Deployment-Status-Drafts, Cisco, Nokia, segment-routing.net.
• Sicherheitsabschnitt ergänzt: SRv6 SIDs sind global routbar, im Gegensatz zu MPLS-Labels. Domain-Grenzfilterung (RFC 8754 Abschnitt 5, RFC 9602) und das laufende draft-ietf-spring-srv6-security sind wichtige Sicherheitsaspekte.
• RFC 9602 ergänzt: Veröffentlicht Oktober 2024 — weist ein dediziertes IPv6-Präfix für SRv6 SIDs zu — relevant für Adressierung und Sicherheitslage. In Referenztabelle aufgenommen.
• Referenztabelle ergänzt: Alle RFCs mit Status und Datum tabellarisch dargestellt.
• Front Matter / Metadaten entfernt: Titel, Überschrift, Metadaten entfernt gemäß Workflow.