Summary

  • Revision 14 of the IETF STAMP header-reflection draft adds a section requiring the egress data plane to supply received IP and IPv6 extension headers to its Session-Reflector. In two-way measurement, the reverse-direction ingress data plane must likewise supply received reply headers to the Session-Sender.
  • The draft is not an RFC or a deployment report. Its selector and C-flag behavior was substantially present in revision 13; the news is the now-explicit local delivery obligation, not the invention of a new mismatch signal.

Picture a test packet crossing a router boundary. An outside observer can see it arrive. The forwarding plane can process its IPv6 extension headers. Yet the STAMP reflector, housed elsewhere in that node's software, cannot echo a header it was never given. The difference between packet arrival and header availability is the operational blind spot at the centre of draft-ietf-ippm-stamp-ext-hdr-14.

The 18 September revision adds §3.3. When the egress node's data plane processes a Session-Sender test packet, it must provide the received IP header and IPv6 extension headers to the Session-Reflector on that node. For a two-way measurement, a parallel requirement applies at the ingress node: its reverse-direction data plane must pass the received headers from the Session-Reflector test packet to the Session-Sender. These are requirements in a working draft, not evidence that a named router already satisfies them.

The proposal uses STAMP TLVs to ask for portions of headers seen by the other end. A nonzero selector uses the requested length and the first eight octets of an IPv6 extension header, or the first four of a fixed IP header, to pick the intended input. A zero selector takes the first header of matching length. If the requested data and length find no match, the reflector returns the TLV with the C conformance flag set. Revision 14 puts these rules together in the procedures and sharpens their wording.

Revision 13 already described the disambiguation and C-flag failure case in its field definitions, including inability to access received headers. Calling the C flag a fresh invention would misread the version history.

What did change is the location of responsibility. A conformance flag can report that reflection could not be performed, but it cannot retroactively provide a missing header to the reflector. The new handoff language tells implementers where that evidence must cross a local component boundary. It also matters in the reverse direction: a received reply does not by itself tell the sender which received IP or extension headers its own data plane exposed for two-way analysis.

That distinction protects interpretation. A reflected TLV is evidence about a selected header made available under a particular request; it is not an inventory of every header on the path, proof that all IOAM data survived at every midpoint, or authentication of whoever produced those bytes. Conversely, C=1 does not identify one unique cause. A selector mismatch, unavailable local headers or another applicable conformance constraint must be separated with local implementation evidence before a performance conclusion is drawn.

The earlier BTW analysis of STAMP's C flag concerned MTU, rate and volume limits; this article concerns the newly mandated data-plane-to-measurement handoff.

The draft also now spells out that the complete resulting IP/UDP/STAMP/TLV packet must fit the applicable path MTU. Earlier text already had an MTU safeguard, so this is precision about what is counted, not the debut of size control. The Datatracker still lists revision 14 as active, under AD Evaluation and submitted to the IESG. A standards decision, interoperability outcome and production adoption remain open.

Sources