Zusammenfassung

  • RFC 9947 beschränkt den experimentellen Alternate-Marking-SRH-TLV auf eine kontrollierte SR-Domäne und erwartet zugleich, dass Ergebnisse aus freiwilligen Tests in produktiven Netzen als Internet-Drafts den Independent Submissions Editor oder die IETF-Arbeitsgruppe SPRING erreichen. Paketgrenze und Veröffentlichungsbefugnis sind verschiedene Kontrollen.
  • Ein belastbares Ergebnis braucht einen Evidenzexport-Beleg, der Freigabestelle, Spezifikations- und Implementierungsversion, experimentellen Wert, Funktionsumfang, Vergleich nach RFC 9343, Geräteklassen, Stichprobe, Unsicherheit, negative Ergebnisse, Aggregation, Artefakt-Hashes und Korrekturen verbindet, ohne Rohverkehr, Kunden oder verwertbare Topologie offenzulegen.

Das Experiment soll außerhalb seines Ortes überzeugen

RFC 9947 wurde im März 2026 als Experimental RFC im Independent Stream veröffentlicht. Die Erweiterung entstand außerhalb der IETF, besitzt keinen IETF-Konsens und ist kein Kandidat für irgendeine Stufe des Internet Standard. Sie veranlasst auch keine IANA-Zuweisung.

Technisch platziert sie Alternate-Marking-Daten für SRv6 in einem TLV des Segment Routing Header. Die Standards-Track-Lösung RFC 9343 nutzt dafür IPv6 Hop-by-Hop oder Destination Options. RFC 9947 ersetzt sie nicht. Beide Formen können nebeneinander bestehen, und gerade ihre Unterschiede sind Gegenstand des Versuchs.

Gefragt wird, ob der SRH-TLV das Netz besser oder schlechter übersteht, ob seine Verarbeitung gegenüber der Destination Option einen Gewinn oder eine Belastung darstellt, ob Gerätearchitekturen verschieden reagieren, ob normale SRv6-Programmierung und SID-Funktionssteuerung weiter funktionieren und wie Betreiber die erweiterten Felder gegenüber anderer On-Path-Telemetrie beurteilen.

Der Text erwartet, dass Ergebnisse gesammelt und dem Independent Submissions Editor oder SPRING als Internet-Drafts vorgelegt werden. Erste Ergebnisse sollen innerhalb von zwei Jahren nach Veröffentlichung verfügbar sein. Diese Erwartung ist noch nicht abgelaufen und darf nicht in eine Behauptung über fehlende Berichte umgedeutet werden.

Bemerkenswert ist die räumliche Spannung. Der Versuch soll voraussichtlich in einem einzigen Service-Provider-Netz stattfinden, sowohl wegen der SR-Domäne als auch wegen der begrenzten Möglichkeit, entlang von Paketpfaden erhobene Leistungsdaten zu teilen. Die Beobachtung entsteht also dort, wo sie geschützt werden muss, soll aber dort wirken, wo sie öffentlich geprüft wird.

Die technische Grenze ist präzise

Alternate Marking nach RFC 9947 darf nur in einer kontrollierten Domäne eingesetzt werden. Ein Betreiber entscheidet über Nutzung und Konfiguration, verwaltet die Knoten lokal und verhindert, dass Pakete mit AltMark TLV in die Domäne hinein- oder aus ihr herausgelangen.

Der TLV Type wird aus dem experimentellen Bereich 124 bis 126 gewählt. Alle teilnehmenden Implementierungen müssen denselben Wert koordinieren. Der Wert sollte konfigurierbar bleiben, damit mehrere Versuche im gleichen Netz einander nicht stören. Er ist ein lokaler Parameter, keine dauerhafte Registrierung und keine Einsatzgenehmigung.

Damit ist das Datenebenenrisiko klar eingegrenzt. Für den späteren Bericht reicht diese Grenze jedoch nicht. Ein Router kann einen TLV filtern. Er kann nicht entscheiden, ob eine Zeitreihe einen Kundenpfad erkennen lässt, ob eine kleine Geräteklasse einen Standort verrät oder ob ein Architekturvergleich eine vertrauliche Schwäche offenlegt.

Auch die Umkehrung ist möglich: Aus Vorsicht werden Last, Stichprobengröße, Ausfälle und ausgeschlossene Intervalle entfernt. Übrig bleibt eine sichere, aber wertlose Aussage. Paket-Containment beweist weder die Befugnis zur Veröffentlichung noch die Aussagekraft des veröffentlichten Rests.

Implementierungsumfang gehört in den Nenner

Der Basis-TLV enthält einen 20-Bit-FlowMonID sowie Markierungen für Verlust und Verzögerung. Erweiterte Felder können einen zusätzlichen FlowMonID, segmentweise oder Ende-zu-Ende-Messung, Fragmentierungsstatus, Flussrichtung, Zeitstempel, Steuerung einer Rückwärtsmessung und Sequenznummern tragen. Für die Rückrichtung können Präfixmasken, Protokoll, Ports, DSCP, Tunnelumfang und Messperiode relevant sein.

Diese Optionen verändern Messgegenstand und Verarbeitungskosten. Ebenso wichtig ist, welche SID-Funktion die TLV-Verarbeitung auslöst und welche Knoten die Funktion gar nicht unterstützen. Ein nicht unterstützender SRv6-Knoten darf den TLV nach den SRH-Regeln ignorieren; das ist nicht automatisch ein Fehler.

Ein Ergebnis muss daher den implementierten Ausschnitt nennen. Der Vergleich nach RFC 9343 benötigt äquivalente Paketgrößen, Last, Verkehrsklassen, Pfade und Messfunktionen. Andernfalls kann eine exakt gemessene Differenz vom Gerät, der Konfiguration oder der Stichprobe stammen statt vom Ort der Markierung.

Selbst der experimentelle Wert ist Provenienz. Erwartet ein Empfänger 126, während der Sender 124 verwendet, sieht eine Koordinationspanne wie fehlende Protokollunterstützung aus. Kollidiert ein zweiter Versuch, können Beobachtungen vermischt werden. Die Nummer im Bericht verleiht keinen Status; sie stellt die Verbindung zur wirklichen Versuchskonfiguration her.

Metadaten bleiben sensibel

RFC 9343 stellt klar, dass Alternate Marking keine Nutzdaten freigibt, seine Metadaten aber zur Netzaufklärung beitragen können. FlowMonID kann Flüsse nachverfolgbar machen. Mehrere Beobachtungspunkte können gemeinsam Pfad- und Leistungsinformationen erschließen. Meldekanäle zwischen Messpunkten und Managementsystem müssen gesichert sein.

RFC 9341 ergänzt Integritätsrisiken. Markierungen, Zeitsynchronisierung und Statistikübertragung können manipuliert werden; theoretisch ist auch ein sehr langsamer verdeckter Kanal denkbar. Deshalb muss ein Bericht Annahmen über Zähler, Uhren und Schutz nennen, bevor er ein Messergebnis dem Protokoll zuschreibt.

RFC 8799 beschreibt die Grenze einer Limited Domain als Schutz für Betriebsparameter, die ein Betreiber nicht veröffentlichen will. Davon zu unterscheiden ist die Privatsphäre einzelner Nutzer. Beide Ebenen können durch eine Veröffentlichung berührt werden. Entfernte Namen helfen wenig, wenn genaue Zeiten, seltene Verkehrsklassen und kleine Kohorten eine Aktivität wieder erkennbar machen.

„Anonymisiert“ ist somit kein ausreichender Nachweis. Die Transformation braucht eine Beschreibung. Welche Dimensionen wurden gruppiert? Welche unterdrückt? Welcher externe Test ist danach nicht mehr möglich? Welche Schlussfolgerung bleibt trotz dieser Lücke gerechtfertigt?

Der kleinste brauchbare Exportbeleg

Zuerst steht die Befugnis. Der Beleg nennt Betreiber oder Forschungsträger, die Rolle mit Freigaberecht, Ziel und Zeitpunkt der Einreichung sowie wesentliche Finanzierungs- oder Lieferbeziehungen. Eine Annahme durch den ISE oder Erörterung in SPRING ist weder Empfehlung noch IETF-Konsens.

Danach folgt die technische Identität: RFC- oder Draft-Revision, Implementierungs-Build, genutzter TLV-Wert, Basis- und Erweiterungsfelder, SID-Verhalten und RFC-9343-Vergleichsaufbau. Hashes können geschützte Artefakte an die öffentliche Version binden, ohne sie zu veröffentlichen.

Die Population wird in einer sicheren, aber erklärenden Auflösung beschrieben: Gerätearchitektur und Softwarekohorte, abstrakte Pfadform, Beobachtungsintervall, zugelassener und ausgeschlossener Verkehr, Stichprobenbehandlung, Zähler- und Uhrannahmen sowie Definitionen von Verlust, Verzögerung, Jitter, Überlebensfähigkeit und Verarbeitungskosten. Fehlwerte und Unsicherheit gehören neben den Mittelwert.

Schließlich werden positive, negative, uneindeutige und abgebrochene Ergebnisse gemeinsam erfasst. Der Beleg nennt Aggregation, Schwärzung und Unterdrückung von Fluss-, Pfad-, Zeit- und Herstellermerkmalen, die dadurch verlorene Reproduzierbarkeit, mögliche begrenzte Prüfung geschützter Artefakte und eine Korrekturhistorie.

Das ist ein redaktioneller Vorschlag von Daniel Kade, keine Vorschrift aus RFC 9947. Er fordert keinen Rohdatensatz. Er verlangt nur, dass sich der Weg von der geschützten Beobachtung zur öffentlichen Behauptung nachvollziehen lässt.

Running code hat einen Kontext

RFC 7942 zeigt eine verwandte Praxis. Ein freiwilliger Implementation-Status-Abschnitt kann verantwortliche Organisation, Implementierung, Reife und Abdeckung dokumentieren. Die Auflistung ist keine IETF-Billigung, und die Angaben sind zeitabhängig.

Für RFC 9947 ist das kein verbindliches Muster, denn RFC 7942 schließt Independent-Stream-Dokumente ausdrücklich aus. Übertragbar ist allein die Erkenntnis, dass Implementierungsevidenz einen Verantwortlichen, Umfang und Zeitpunkt braucht.

RFC 7841 hält die institutionelle Grenze fest. Selbst hervorragende Ergebnisse verwandeln einen Independent-Stream-RFC nicht rückwirkend in IETF-Konsens. Sie können neue Arbeit auslösen oder eine künftige Entscheidung beeinflussen. Der Evidenzbeleg muss Stärke der Beobachtung und Autorität des Publikationsstroms getrennt ausweisen.

Grenzen dieser Recherche

Die Quellen belegen Status, Felder, Domänenregel, Vergleichsfragen und die erwartete Weitergabe der Ergebnisse. Sie belegen auch die einschlägigen Datenschutz-, Integritäts- und SRv6-Rahmenbedingungen. Sie liefern keine Betreiberergebnisse, keine Einsatzliste und keinen öffentlichen Datensatz.

Dieser Text entscheidet deshalb nicht zwischen SRH TLV und RFC 9343. Er behauptet weder Verspätung noch verweigerte Veröffentlichung. Er verlangt keine Rohpakete, Kundenidentitäten, exakte Topologie oder Herstellergeheimnisse.

Seine Forderung ist enger: Wenn ein Ergebnis die Grenze passiert, müssen Befugnis, Versuch, Reduktion und Reichweite der Behauptung sichtbar bleiben. Die geschützten Beobachtungen dürfen im Netz bleiben. Eine versionierte, datenschutzbewusste und korrigierbare Evidenz kann es verlassen.

Quellen

  1. Heng Lu — The Policy Mirror
  2. Heng Lu — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
  3. Heng Lu — Why BTW Media Exists and Why Reality, Not Advocacy, Is the Product
  4. RFC-Editor-Eintrag zu RFC 9947
  5. RFC 9947 — Alternate-Marking Method im Segment Routing Header
  6. RFC 9341 — Alternate-Marking Method
  7. RFC 9342 — Clustered Alternate-Marking Method
  8. RFC 9343 — IPv6-Anwendung der Alternate-Marking Method
  9. RFC 8799 — Limited Domains and Internet Protocols
  10. RFC 8402 — Segment Routing Architecture
  11. RFC 8754 — IPv6 Segment Routing Header
  12. RFC 8986 — SRv6 Network Programming
  13. RFC 7841 — RFC Streams, Headers, and Boilerplates
  14. RFC 7942 — Improving Awareness of Running Code