Zusammenfassung

  • draft-ietf-ippm-stamp-ext-hdr-15 lässt den Session-Reflector einen empfangenen festen oder IPv6-Erweiterungsheader in ein STAMP-TLV kopieren. Das ist eine Vorwärtsbeobachtung bei R1.
  • Der bidirektionale Modus verlangt separat lokal erzeugte passende Erweiterungsheader für das Antwortpaket. Bytegleichheit ist nicht gefordert; Länge und Inhalt sind lokale Entscheidungen.
  • Die Antwort beweist weder Byte- noch Routensymmetrie oder vollständige IOAM-Verarbeitung. Datenplane-Zugriff, Matching, MTU, Offenlegung, Integrität und Rate Limiting begrenzen die Aussage.

Ein symmetrisches Bild ist noch keine symmetrische Messung. Revision 15 definiert eine Kopie dessen, was R1 auf dem Hinweg sah, und eine neue Konstruktion für den Rückweg. Die Kopie liegt im STAMP-Payload. Die Konstruktion liegt im IP-Paket der Antwort.

Zwei Headerflächen

RFC 8762 definiert STAMP, RFC 8972 optionale TLVs. Für IPv6-Erweiterungen benennt die Anfrage Länge und bis zu acht Anfangsoctets; beim festen Header sind es vier. Der Reflektor sucht im tatsächlich empfangenen Paket und kopiert die übrigen Bytes.

Der IPv6 Extension Header Control Sub-TLV fordert dagegen neue passende Header für die Rückrichtung. Nur die Typreihenfolge wird gebunden. Ein sender-spezifischer Routing Header kann entfallen, und Inhalt sowie Länge bleiben lokal. Gesendeter Header, empfangener Header, TLV-Kopie, Rückwegkonstruktion und endgültige Antwort sind fünf Belege.

Bidirektional ist keine Topologieaussage

Der Klartext erlaubt gleiche oder andere Rückwege und verlangt nicht denselben Mittelpunkt. „Bidirektional“ bezeichnet nur, ob R1 passende Header auf die Antwort setzt.

Unidirektional kann R1 die Hinwegbeobachtung zurückgeben, ohne einen solchen Rückwegheader zu erzeugen. Bidirektional erzeugt es ein neues Objekt. Ein Dashboard darf daraus keine identische Route machen.

Matching braucht einen eigenen Nachweis

Bei mehreren gleich langen Headern dienen die Anfangsbytes als Diskriminator; sie müssen bis R1 stabil bleiben. Null wählt den ersten Header passender Länge. Protokolliert gehören Anfrage, Länge, Diskriminator, Position, empfangener Digest und Ergebnis.

Falsche Länge, falsche TLV-Reihenfolge, fehlende Unterstützung, ungültiger Header oder fehlender Datenplane-Zugriff lösen das C-Flag-Verfahren aus RFC 10052 aus. Eine vorhandene Antwort kann ohne kopierte Daten zurückkommen.

Forwarding-Sicht ist nicht Prozess-Sicht

Die Datenplane muss empfangene Header an STAMP übergeben. Ein Router kann eine Option weiterleiten, ohne sie dem Messprozess zugänglich zu machen. Umgekehrt beweist eine bei R1 sichtbare Option nicht die Verarbeitung durch jeden Mittelpunkt.

RFC 9197 definiert IOAM-Felder, RFC 9486 deren IPv6-Transport. Fehlende Einträge können fehlende Teilnahme, Platz, Unterstützung, Auswahl oder einen anderen Weg bedeuten. RFC 8250 begrenzt das Einfügen und Entfernen von Erweiterungsheadern; Änderungen von Präsenz oder Länge unterwegs sind außerhalb des Entwurfs.

MTU und Politik verkürzen den Bericht

Das Gesamtpaket muss in die Pfad-MTU passen. Andernfalls werden reflektierte TLVs entfernt. Zusätzlich darf eine lokale Richtlinie Headerdaten zurückhalten, um interne Informationen zu schützen.

Die Zustände müssen deshalb heißen: nicht beobachtet, beobachtet und zurückgegeben, beobachtet und zurückgehalten, wegen MTU entfernt oder nicht zugänglich. Ein leeres Feld reicht nicht.

Integrität ist konfigurierbar

IPv6 UDP Zero Checksum ist nur eine enge Ausnahme. RFC 6936 und RFC 8085 lassen die normale Prüfsumme Standard. Die Ausnahme verlangt freigegebene STAMP-Ports, Adressprüfung, eine Verwaltungsdomäne und akzeptiertes Restrisiko. Für Payload-Integrität wird authentifizierter Modus empfohlen.

RFC 8200 ist die IPv6-Basis; RFC 9740 kann die Prüfung empfangener Erweiterungsheader unterstützen. Ein erfolgreiches Parsing beweist keine unbeschädigte Übertragung.

Policing sieht wie Verlust aus

STAMP belastet CPU und Speicher. Das vorgeschriebene Rate Limiting schützt die Control Plane, doch ein Punt-Path-Drop ist im Messergebnis von Netzverlust nicht unterscheidbar. Lokale Policer-Zähler müssen mit Fehlermeldungen korreliert werden.

Der Trichter lautet gesendet / zugestellt / geparst / gematcht / kopiert / erzeugt / ausgesendet / empfangen. Nur die letzte Rate verschweigt die Ursache.

Standardsstatus ohne Übertreibung

Der Datatracker führt Revision 15 bis 15. Oktober 2026 im IETF Last Call. Die Historie datiert sie auf 30. September, der E-Mail-Eintrag dokumentiert Verteilung. Das ist kein RFC.

Diff, frühe Review und TBA-Werte im IANA-Register zeigen Änderbarkeit. Der Teaparty-Commit ist Running-Code-Evidenz, keine breite Deployment- oder Interoperabilitätsstudie.

Die Belegkette braucht Paket- und Header-Digests, Reihenfolge, Anfrage, Datenplane-Handoff, Match, C Flag, MTU-Kürzung, Offenlegungsentscheidung, Rückwegheader, Interfaces, Checksum, Authentifizierung, Policer, Route und Urteil.

Running-Code Primacy verlangt reale Bytes. The Policy Mirror zeigt die lokale Macht. Reality Layers trennt das Symbol „reflektiert“ von Beobachtung und Wirkung.

Quellen