Summary

  • draft-ietf-ippm-stamp-ext-hdr-15 lets a Session-Reflector copy a fixed or IPv6 extension header received on the forward test packet into a STAMP payload TLV. That is an observation of the forward packet at the reflector.
  • Bidirectional mode separately asks the reflector to add locally generated matching IPv6 extension headers to the reverse test packet. The draft says those headers need not be byte-for-byte copies; length and content are local decisions.
  • A returned reply therefore does not prove byte symmetry, route symmetry, midpoint behavior or a complete IOAM record. Data-plane access, matching, MTU, disclosure policy, integrity and rate limiting can each change the evidence.

The most misleading network diagram in a measurement review is often the neatest one. A probe travels from S1 through a midpoint to R1. A reply follows the arrow back. The same extension-header label appears above both arrows. The dashboard concludes that the header made a round trip.

Revision 15 of the STAMP header-reflection draft describes something more careful. The Session-Reflector can put a copy of the header it received into the STAMP payload. If the sender requests bidirectional measurement, the reflector can also put a locally generated matching header on the reverse packet. The first is evidence about an observed forward header. The second is a new act performed under local rules. They can coexist in the same reply without being the same bytes.

That distinction is not editorial nuance. It decides whether an operator has measured forward reception, reverse construction, reverse-path treatment, or only some of them.

One reply, two header surfaces

The base STAMP protocol supplies timestamps and packet exchange. STAMP optional extensions add TLVs. Revision 15 proposes two reflected-data TLVs: one for fixed IPv4 or IPv6 headers, and one for IPv6 extension headers.

The sender creates the request TLV and initializes its reflected-data area to zero. For an IPv6 extension header it provides the desired length and, when needed, the first eight octets as a discriminator. For a fixed header it uses the first four. The reflector matches a header that its data plane actually received, copies the rest into the TLV and returns the observation inside the STAMP payload.

The reverse header belongs to a different mechanism. An IPv6 Extension Header Control Sub-TLV asks the reflector to add locally generated matching headers to the reverse packet. The draft requires the same order of header types, but says the generated headers need not be byte-for-byte copies. Their length and content are decisions at R1. A sender-specific routing header need not be recreated at all.

The honest model is therefore:

Surface Who produces it What it can establish What it cannot establish
Forward packet header Session-Sender and forward data plane Intended probe input What R1 ultimately received
Reflected-data TLV Session-Reflector from received bytes Header visible to R1, subject to matching and access Header used on the reverse wire
Reverse packet header Session-Reflector under local policy R1's constructed reverse input Byte identity with the forward header
Received reply Reverse network and Session-Sender A reply reached S1 Same route, same midpoints or same treatment
IOAM record Participating nodes and option semantics Recorded observations that are actually present Completeness or truth of absent observations

Compressing this table to reflected=true converts a bounded receipt into a story about the whole path.

“Bidirectional” does not mean symmetric

The draft defines unidirectional and bidirectional measurement only by whether the reflector adds matching extension headers for the reverse direction. The word does not promise that the reply uses the same links or nodes. Its reference topology says the reverse packet may take the same path or a different one, and need not traverse the same midpoint.

In unidirectional mode, the reflector can omit corresponding reverse headers and still copy the forward received header into the payload. In bidirectional mode, it constructs new reverse headers. Even then, local content and length can differ. A successful round trip can therefore show all of the following at once:

  • R1 received the forward header;
  • R1 returned a copy of those bytes in a TLV;
  • R1 generated a different header of the matching class for its reply;
  • the reply crossed a different path;
  • S1 received the reply.

None of those statements contradicts another. The error appears only when a monitoring system merges them.

Matching is an assumption with failure states

When several headers have the same length, order alone may not identify the intended one. Revision 15 lets the request carry the first eight octets of an extension header or first four octets of a fixed header. It then assumes those discriminator bytes do not change before arrival at the reflector.

That assumption matters. A measurement intended to observe mutable data cannot quietly use mutable bytes as its lookup key. Operators must know which fields can change, which header instance was selected and whether the returned TLV corresponds to the intended one.

A zero discriminator selects the first matching-length header. Multiple headers are processed from the outer header inward. When fixed and extension-header TLVs are combined, their order must mirror the packet: fixed-header TLVs first, extension-header TLVs after them. A mismatch, inaccessible data plane, unsupported header, invalid header or incorrect ordering invokes the Conformant Reflected Packet C-flag procedure from RFC 10052; some cases return no copied data.

The counterintuitive flag name is another reason to store the actual outcome rather than a label. Record requested header identity, returned length, returned bytes or digest, C flag, matching branch and error reason. “Reply received” is not a substitute.

The data plane must hand the evidence upward

The reflector cannot copy bytes it never sees. Revision 15 requires the egress data plane to provide received extension headers to the reflector. For bidirectional measurement, the sender-side ingress data plane must likewise expose extension headers received on the reply.

This boundary separates forwarding support from measurement support. Midpoint equipment may process an IPv6 option correctly while the endpoint implementation fails to deliver the received header to the STAMP process. Conversely, the STAMP process may return a header without proving that every midpoint understood or updated the option.

RFC 9197 defines IOAM data fields; RFC 9486 maps relevant IOAM options into IPv6 Hop-by-Hop and Destination Options headers. Those standards define data and carriage. They do not make a returned record complete by magic. A missing node entry can mean nonparticipation, unsupported processing, unavailable space, packet selection, export behavior or a different path. The reflected header shows what arrived at R1, not why every possible field has or has not appeared.

RFC 8250 also matters: extension headers are not freely inserted or deleted in flight except through encapsulation. Revision 15 therefore excludes a use case in which their presence or length is rewritten along the path. The measurement must stay inside its declared model.

MTU and disclosure policy can intentionally narrow the record

Every reflected byte makes the reply larger. The complete packet—IP, UDP, STAMP and requested TLVs—must fit the applicable path MTU. If it does not, one or more reflected-data TLVs must be removed. A smaller evidence set can therefore be conformant behavior, not packet loss.

Local policy can narrow it further. The draft permits an operator to configure a reflector not to copy received fixed or extension headers, avoiding disclosure of collected network information. The same device may measure the packet and deliberately refuse to return the observation.

These are governance decisions in protocol clothing. The operator controls which internal path facts leave R1, which evidence is sacrificed under MTU pressure and whether the reverse packet receives matching headers. A central collector should not turn local withholding into “no header existed,” nor should it interpret TLV omission as a neutral sampling event.

Packet integrity is not implied by measurement syntax

Revision 15 contains a constrained exception for IPv6 UDP zero checksum. RFC 6936 and RFC 8085 normally impose strict conditions because a zero checksum removes a transport integrity check. The draft says checksum use remains the default. Zero checksum must be enabled only for specific STAMP ports, with address validation, inside one administrative domain, when the operator accepts the residual corruption risk. Authenticated STAMP mode is recommended when payload integrity is required.

That qualification belongs beside the result. A TLV parser can be correct while the packet carrying it was corrupted. The specification requires zero-checksum sessions to make no assumption that received test packets are correct and to behave safely under corruption. The credible receipt therefore records checksum mode, authentication mode, source and destination validation, session identifier, parser outcome and C-flag state.

RFC 8200 supplies the IPv6 baseline. RFC 9740 offers mechanisms an operator may use to verify received extension headers. These adjacent controls are evidence dependencies, not decorations in a standards matrix.

Apparent loss may be protection of the measurement plane

STAMP processing consumes CPU and memory. The draft requires rate limiting as denial-of-service protection and acknowledges a hard observability problem: punt-path policing is indistinguishable from actual network loss in the measurement result. It recommends correlating rate-limit evidence with failure notifications.

That makes a failed session a hypothesis, not a root cause. The useful funnel is:

sent / admitted-to-data-plane / delivered-to-reflector / parsed / matched / reflected / reverse-header-generated / emitted / admitted-at-sender / parsed-at-sender.

Keep denominators and reasons at every boundary. A jump in failed STAMP sessions during a control-plane attack may show a healthy protective policer, degraded network transport, or both. Without the local counter, the measurement system cannot decide.

Last Call is a standards event, not an operating result

The Datatracker record shows revision 15 as an IPPM Working Group document in IETF Last Call through 15 October 2026. The history records its 30 September posting and the IESG Last Call announcement. The email-trigger record explains the distribution machinery; it is not evidence of implementation.

The draft requests TBA values from the IANA STAMP registry. Until assignment and publication, codepoints and text can change. An early performance-metrics review recorded issues against an earlier revision. The revision diff shows that review and protocol development as a process, not a completed deployment guarantee.

The draft names an open-source implementation, and the referenced commit is running-code evidence for listed functions. It does not establish independent interoperability, production use, every error path or the local policies of a deployed network.

Preserve the receipt chain

For each test, retain the exact forward packet digest; header sequence; requested type, length and discriminator; forward egress interface; reflector receive time; data-plane handoff result; matched header ordinal; received-header digest; reflected TLV digest; C flag and reason; omitted TLVs and MTU budget; disclosure-policy decision; requested measurement type; reverse generated-header digest; reverse egress interface; checksum and authentication mode; rate-limit counters; reply receive time; actual reverse-path evidence; parsed IOAM fields; and the final analytic decision.

This is not bureaucratic excess. It is the minimum record needed to stop one reply from impersonating four receipts.

Running-Code Primacy directs attention to the actual bytes and transitions, not the protocol label. The Policy Mirror exposes the authority inside local disclosure, MTU and construction choices. Reality Layers keeps the symbolic “reflected header” separate from forward observation, reverse construction, path treatment and operational effect.

Sources