Zusammenfassung

  • draft-ietf-spring-sid-as-source-address-00 wurde am 7. September 2026 veröffentlicht und ist nun ein Dokument der SPRING-Arbeitsgruppe. Das ist eine Arbeitsentscheidung, keine RFC-Freigabe und keine Verifikation der genannten Implementierung.
  • Der Entwurf ersetzt die Loopback-Adresse des Ingress-PE im äußeren IPv6-Quellfeld durch den passenden Service-SID. So kann eine Firewall die beiden Richtungen als umgekehrtes Adresspaar behandeln.
  • Der Treffer gilt für eine Sitzung, nicht für die Identität des Senders. Der Text warnt selbst vor schwächerer Rückverfolgbarkeit, internem SID-Spoofing und hoher Zustandsdynamik.

Die Ausgangslage besteht aus zwei Regeln, die einzeln vernünftig wirken. Ein Ingress-PE kapselt Kundenverkehr und verwendet seine Loopback-Adresse als äußere IPv6-Quelle. Der VPN-Service am anderen Ende erscheint als endgültiges Ziel: ohne SRH direkt im Zieladressfeld, mit SR Policy als letzter Eintrag des Segment Routing Header. Eine SRv6-fähige Firewall kann dieses Ziel auslesen und einen Drei- oder Fünf-Tupel-Zustand anlegen.

Auf dem Rückweg setzt der andere PE seine eigene Loopback-Adresse ein; der Service-SID der ersten Seite wird zum endgültigen Ziel. Die äußeren Werte tauschen also nicht schlicht ihre Plätze. Erwartet die Firewall genau diesen Tausch, sieht sie zwei verschiedene Verbindungen. Ein korrekt geroutetes Antwortpaket oder eine ICMP-Fehlermeldung kann deshalb am Zustandsfilter scheitern.

Der neue Entwurf stellt die Dienstbedeutung symmetrisch her. Nach der Bestimmung des L3-VPN wählt der PE den Service-SID, den die Gegenstelle für diesen Kontext erwartet, und schreibt ihn in die äußere Quelladresse. Die Gegenrichtung tut dasselbe. Steht ein SID im Quellfeld, wird er dort als gewöhnliche IPv6-Adresse behandelt und löst kein Endpoint-Verhalten aus. Für die Firewall entsteht das erwartete umkehrbare Paar.

Der Preis ist eine neue Aussage des Feldes. Zuvor verwies es wenigstens auf den Ingress-PE. Nun bezeichnet es vor allem einen Service, den dieser PE ausgewählt hat. Ein Zustands-Treffer belegt, dass das Paket unter der aktuellen Parser- und Regelgeneration zu einem vorhandenen Eintrag passt. Er benennt weder zwingend das sendende Gerät noch den Kunden, die Berechtigung oder die Echtheit des Wertes.

Die Granularität verteilt diesen Verlust. Ein SID pro VRF benötigt keine zusätzliche Suche, lässt aber mehrere Customer Edges als eine Quelle erscheinen. Ein SID pro Attachment Circuit trennt Zugänge ohne weitere Abfrage. Ein SID pro Präfix ist am feinsten, erfordert jedoch eine zusätzliche Suche nach der Kunden-Quelladresse innerhalb der VRF und kann den Forwarding-Pfad belasten. Die Reihenfolge Präfix, AC, VPN/VRF ist damit zugleich eine Hierarchie aus Zurechnung und Kosten.

Im Sicherheitsteil wird aus Symmetrie ausdrücklich kein Vertrauen. Locator-Präfixe sind im SR-Domain gewöhnlich routbar; ein interner Knoten könnte eine fremde SID-Quelle vortäuschen und damit Regeln umgehen, die das Präfix als vertrauenswürdig lesen. Häufig wechselnde programmierbare SIDs können außerdem Sitzungen schnell erzeugen und altern lassen, Tabellenressourcen verbrauchen und Überläufe auslösen. Zulässige Flüsse, Ursprungsrechte, Anti-Spoofing, Lebenszyklen und Zustandsbudgets bleiben eigenständige Kontrollen.

ICMP liefert einen anderen Beleg. Ein SRv6-Ping darf einen End SID als äußere Quelle verwenden, um die Rückerreichbarkeit zu prüfen. Ein Transitknoten kann einen Fehler mit dem SID melden, bei dessen Verarbeitung das Problem auftrat. Das hilft, Segment und Knoten zu lokalisieren. Bei VPN-Verkehr muss der Ingress-PE weiterhin den eingebetteten Upper-Layer-Header nach RFC 8986 bearbeiten, damit das innere ICMP den CE erreicht. Die Lokalisierung authentifiziert den Meldenden nicht und entscheidet nicht über die Ursache.

Komprimierung fügt eine Parser-Bedingung hinzu. Nach RFC 9800 kann der letzte Routing-Header-Eintrag von der Adresse abweichen, die das endgültige Ziel erhält; komprimierte Anweisungen können auch ohne SRH im Ziel stehen. Der Entwurf empfiehlt deshalb, das endgültige Ziel unkomprimiert als letzten SRH-Eintrag zu erhalten. Rekonstruiert die Firewall in beiden Richtungen nicht dieselbe Zielbedeutung, helfen auch korrekt gewählte Quell-SIDs nicht.

Die Implementierungsangabe ist präzise, aber nicht unabhängig geprüft. New H3C nennt CR16000 und CR19000 ab Software 7.1.119, alle Abschnitte und Reifegrad Production. Der Eintrag verweist noch auf den Vorgänger Draft-13 und nennt keine besondere Implementierungserfahrung. Nach dem Muster von RFC 7942 erklärt der Entwurf, dass die IETF solche Beitragsangaben nicht verifiziert und nicht billigt. Das ist ein Running-Code-Signal, keine Konformitätsbescheinigung, kein Interop-Test und keine Einsatzstatistik.

Heng Lus Trennung der Realitätsebenen verhindert den Fehlschluss. Der Arbeitsgruppenstatus ist Koordination. Die PE-Regel ist Konfiguration. Paketmitschnitt und Tabellenzeile sind Beobachtung. Zustellung und belastbare Attribution sind Ergebnis. Jede Aussage braucht ihren eigenen Beleg.

Die Nachricht ist deshalb kein pauschaler Fortschrittsstempel für SRv6. Eine Arbeitsgruppe übernimmt einen konkreten Mechanismus gegen fälschlich verworfene Rückpakete und legt dabei offen, wie die Quellsemantik verschoben wird. Ein vollständiger Betriebsbeleg verbindet SID-Zuteilung, zulässige PE, Granularität, Parserstand, Sitzung, Paket und Kundenergebnis. „Der Rückweg passte“ bleibt wahr; „der Absender ist bewiesen“ bleibt eine andere Frage.

Quellen

  1. IETF Datatracker — SID as source address in SRv6
  2. Arbeitsgruppenentwurf 00
  3. Datatracker — Vorgängerentwurf
  4. Vorgängerrevision 13
  5. SRv6 Security Considerations, Revision 16
  6. RFC 8402 — Segment-Routing-Architektur
  7. RFC 8754 — IPv6 Segment Routing Header
  8. RFC 8986 — SRv6 Network Programming
  9. RFC 9252 — BGP Overlay Services über SRv6
  10. RFC 9259 — OAM in SRv6
  11. RFC 9800 — Komprimierte SRv6-Segmentlisten
  12. RFC 7942 — Abschnitte zum Implementierungsstatus
  13. Heng Lu — Running-Code Primacy
  14. Heng Lu — Minimum Initial Specification
  15. Heng Lu — Reality Layers