Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet IP Headers
draft-ietf-ippm-stamp-ext-hdr-11
| Document | Type | Active Internet-Draft (ippm WG) | |
|---|---|---|---|
| Authors | Rakesh Gandhi , Tianran Zhou , Zhenqiang Li , Will Hawkins | ||
| Last updated | 2026-07-04 | ||
| Replaces | draft-gandhi-ippm-stamp-ext-hdr | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | In WG Last Call | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-ippm-stamp-ext-hdr-11
IPPM Working Group R. Gandhi, Ed.
Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track T. Zhou
Expires: 5 January 2027 Huawei
Z. Li
China Mobile
W. Hawkins
University of Cincinnati
4 July 2026
Simple Two-Way Active Measurement Protocol (STAMP) Extensions for
Reflecting STAMP Packet IP Headers
draft-ietf-ippm-stamp-ext-hdr-11
Abstract
The Simple Two-Way Active Measurement Protocol (STAMP) and its
optional extensions can be used for Edge-to-Edge (E2E) active
measurements. In Situ Operations, Administration, and Maintenance
(IOAM) data fields can be used for recording and collecting Hop-by-
Hop (HBH) and E2E operational and telemetry information. This
document extends STAMP to reflect IP headers as well as IPv6
extension headers for HBH and E2E active measurements, for example,
using the IOAM data fields.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 5 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Gandhi, et al. Expires 5 January 2027 [Page 1]
Internet-Draft STAMP for Reflecting IP Headers July 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
2.3. STAMP Reference Topology . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Procedure for Reflecting IPv6 Extension Headers . . . . . 5
3.1.1. One-Way and Two-Way Measurement Types . . . . . . . . 7
3.2. Procedure for Reflecting Fixed Headers . . . . . . . . . 8
3.3. Reflecting Fixed Headers and IPv6 Extension Headers . . . 10
4. Use Case of Reflecting IOAM Data Fields . . . . . . . . . . . 11
5. STAMP Extensions . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Reflected IPv6 Extension Header Data TLV . . . . . . . . 12
5.2. Reflected Fixed Header Data TLV . . . . . . . . . . . . . 13
5.3. IPv6 Extension Header Control Sub-TLV . . . . . . . . . . 14
6. Operational Considerations . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
The Simple Two-Way Active Measurement Protocol (STAMP) provides
capabilities for the measurement of various performance metrics in IP
networks [RFC8762] without the use of a control channel to pre-signal
session parameters. [RFC8972] defines optional extensions in the
form of TLVs for STAMP. STAMP test packets are transmitted along a
path between a Session-Sender and a Session-Reflector to measure
Edge-to-Edge performance metrics, like delay, delay variation, and
packet loss along that path.
Gandhi, et al. Expires 5 January 2027 [Page 2]
Internet-Draft STAMP for Reflecting IP Headers July 2026
In Situ Operations, Administration, and Maintenance (IOAM) is used
for recording and collecting operational and telemetry information
while the packet traverses a path between two points in the network.
The IOAM data fields are defined in [RFC9197]. The information from
the collected IOAM data fields can be used to support Hop-by-Hop
(HBH) and Edge-to-Edge (E2E) measurement use cases.
IPv6 packets may carry IPv6 extension headers containing IPv6 options
headers for HBH and Destination types, as defined in [RFC8200]. The
HBH options processing procedures are further specified in [RFC9673].
[RFC9486] specifies IPv6 option types for HBH and destination options
headers to carry the IOAM Option-Types defined in [RFC9197] and
[RFC9326] for the IPv6 data plane.
It may be desirable to record and collect HBH and E2E operational and
telemetry information using active measurement packets between two
nodes in a network. This is achieved by augmenting STAMP [RFC8762]
using optional STAMP extensions defined in [RFC8972] to reflect IP
headers as well as IPv6 extension headers as specified in this
document. The procedure defined in this document leverages existing
implementations at midpoint nodes with an IPv6 data plane that
supports the IPv6 extension headers used, without any additional
requirements.
2. Conventions Used in This Document
2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2.2. Abbreviations
DEX: Direct Export
ECMP: Equal Cost Multi-Path
E2E: Edge-to-Edge
HBH: Hop-by-Hop
IOAM: In Situ Operations, Administration, and Maintenance
MTU: Maximum Transmission Unit
Gandhi, et al. Expires 5 January 2027 [Page 3]
Internet-Draft STAMP for Reflecting IP Headers July 2026
STAMP: Simple Two-Way Active Measurement Protocol
TLV: Type-Length-Value
2.3. STAMP Reference Topology
In the "STAMP Reference Topology" shown in Figure 1, the STAMP
Session-Sender S1 initiates a Session-Sender test packet, and the
STAMP Session-Reflector R1 transmits a reply Session-Reflector test
packet. Node M1 is a midpoint node that does not perform any STAMP
processing.
T1 is a transmit timestamp, and T4 is a receive timestamp added by
node S1 in a STAMP test packet payload. T2 is a receive timestamp,
and T3 is a transmit timestamp added by node R1 in a STAMP test
packet payload.
T1 T2
/ \
+-------+ Test Packet +-------+ +-------+
| | - - - - - - - - | | - - - - - - - - ->| |
| S1 |=================| M1 |===================| R1 |
| |<- - - - - - - - | | - - - - - - - - - | |
+-------+ +-------+ Reply Test Packet +-------+
\ /
T4 T3
STAMP Session-Sender STAMP Session-Reflector
Figure 1: STAMP Reference Topology
3. Overview
[RFC8972] defines optional extensions for STAMP. The optional
extensions are added to the base STAMP test packet defined in
[RFC8762] in the form of TLVs. As specified in [RFC8972], both
Session-Sender and Session-Reflector test packets are symmetric in
size when including all optional TLVs (but excluding headers). The
Session-Reflector reflects all received STAMP TLVs from the Session-
Sender test packet.
As specified in [RFC8762], STAMP test packets are transmitted with
IP/UDP headers. Since midpoint nodes do not process the UDP headers
in the packets, they are agnostic to the STAMP test packets in the
payload.
Gandhi, et al. Expires 5 January 2027 [Page 4]
Internet-Draft STAMP for Reflecting IP Headers July 2026
STAMP test packets may carry IP headers and IPv6 extension headers.
This document defines procedures and STAMP extensions for a Session-
Reflector to reflect the received IP headers and IPv6 extension
headers back to the Session-Sender for both one-way and two-way
measurement types.
3.1. Procedure for Reflecting IPv6 Extension Headers
This document defines a new TLV option for STAMP, called "Reflected
IPv6 Extension Header Data" (value TBA1). When a STAMP Session-
Sender adds an IPv6 extension header, such as an IPv6 Hop-by-Hop
options header and a Destination options header [RFC8200] in the
Session-Sender test packet, the Session-Sender MUST add a
corresponding "Reflected IPv6 Extension Header Data" TLV in the
Session-Sender test packet with the length set to the IPv6 extension
header length (starting from the Next Header field of the IPv6
extension header) to receive a copy of that IPv6 extension header
back in the STAMP TLV.
An example STAMP test packet for carrying an IPv6 header, IPv6
extension headers, and reflected data in the "Reflected IPv6
Extension Header Data" TLVs is shown in Figure 2.
+---------------------------------------------------------------+
| IPv6 Header |
+---------------------------------------------------------------+
| IPv6 Extension Header-1 RFC 8200 |
+---------------------------------------------------------------+
~ ... ~
+---------------------------------------------------------------+
| IPv6 Extension Header-N RFC 8200 |
+---------------------------------------------------------------+
| UDP Header |
+---------------------------------------------------------------+
| STAMP Packet RFC 8972 |
+---------------------------------------------------------------+
| Reflected IPv6 Extension Header-1 Data STAMP TLV (TBA1) |
+---------------------------------------------------------------+
~ ... ~
+---------------------------------------------------------------+
| Reflected IPv6 Extension Header-M Data STAMP TLV (TBA1) |
+---------------------------------------------------------------+
Note: Value of M <= N
Figure 2: Example Session-Sender and Session-Reflector Test
Packet with Reflected IPv6 Extension Header Data TLVs
Gandhi, et al. Expires 5 January 2027 [Page 5]
Internet-Draft STAMP for Reflecting IP Headers July 2026
When adding multiple IPv6 extension headers in a Session-Sender test
packet, the corresponding "Reflected IPv6 Extension Header Data" TLVs
MUST be added, with lengths matching the corresponding IPv6 extension
header lengths and in the same order, to receive copies of those IPv6
extension headers. When the Session-Sender test packets carry an
IPv6 extension header that the Session-Sender does not require the
Session-Reflector to reflect in Session-Reflector test packets, the
Session-Sender MUST NOT add a corresponding "Reflected IPv6 Extension
Header Data" TLV in the Session-Sender test packets. In this case,
the number of "Reflected IPv6 Extension Header Data" TLVs (value of M
in Figure 2) in the Session-Sender test packet would be less than the
number of IPv6 extension headers (value of N in Figure 2).
The number of "Reflected IPv6 Extension Header Data" TLVs MUST be
less than or equal to the number of IPv6 extension headers in a
Session-Sender test packet.
When the Session-Reflector receives a STAMP test packet with an IPv6
extension header and a "Reflected IPv6 Extension Header Data" TLV,
the following rules apply:
1. The Session-Reflector that supports this STAMP TLV MUST copy the
entire IPv6 extension header into the "Reflected IPv6 Extension
Header Data" TLV in the Session-Reflector test packet.
2. When there are multiple IPv6 extension headers in the received
Session-Sender test packet, each IPv6 extension header MUST be
processed in order, starting from the outer header, and copied into
the corresponding "Reflected IPv6 Extension Header Data" TLV in the
Session-Reflector test packet, if that STAMP TLV exists.
3. When the Session-Reflector receives a STAMP test packet with an
IPv6 extension header but without a corresponding "Reflected IPv6
Extension Header Data" TLV, the Session-Reflector does not copy the
IPv6 extension header into the Session-Reflector test packet.
The value field in the "Reflected IPv6 Extension Header Data" TLV in
Session-Sender test packets can be initialized to zeros. The
Session-Sender MUST copy the "Requested IPv6 Extension Header Data"
field (shown in Figure 6) using the first 4 octets from the IPv6
extension header (starting from the Next Header field of the IPv6
extension header) if there is an ambiguity when there are multiple
IPv6 extension headers with the same length present and not all need
to be copied and reflected in the STAMP TLVs. This method assumes
that the first 4 octets of the IPv6 extension header do not change
before being received at the Session-Reflector. If the Session-
Reflector receives Session-Sender test packets with non-zero values
in the "Requested IPv6 Extension Header Data" field of the "Reflected
Gandhi, et al. Expires 5 January 2027 [Page 6]
Internet-Draft STAMP for Reflecting IP Headers July 2026
IPv6 Extension Header Data" TLV, the Session-Reflector MUST match the
first 4 octets in the corresponding IPv6 extension header (starting
from the Next Header field of the IPv6 extension header) before
copying data into the STAMP TLV.
The Session-Sender and Session-Reflector MUST ensure that the
resulting test packets do not exceed the IPv6 MTU after adding
"Reflected IPv6 Extension Header Data" TLVs. If necessary, one or
more "Reflected IPv6 Extension Header Data" TLVs MUST be removed to
avoid violating the IPv6 MTU limit.
As the procedure defined in this document leverages existing
implementations at midpoint nodes for the IPv6 extension headers, no
additional requirements are specified when carrying these IPv6
extension headers in STAMP test packets. The IPv6 extension header
is processed by the nodes using the same procedures specified in the
document that defined the IPv6 extension header.
[RFC8250] precludes the insertion and deletion of IPv6 extension
headers along the path (except by encapsulating the original packet
in another IPv6 header); therefore, the use case where the IPv6
extension headers of the Session-Sender test packets are added,
removed, or adjusted in length along the path is outside the scope of
this document.
Examples of IPv6 extension headers include: the IOAM data fields in
an IPv6 options header defined in [RFC9486], Performance and
Diagnostic Metrics IPv6 options header defined in [RFC8250], Maximum
Path MTU IPv6 options header defined in [RFC9268], Alternate Marking
Method IPv6 options header defined in [RFC9343], Routing Header for
IPv6 including Segment Routing Header defined in [RFC8754], and any
new IPv6 extension header that is defined in the future.
3.1.1. One-Way and Two-Way Measurement Types
This document defines two measurement types: one-way and two-way
measurements. These types relate only to whether the Session-
Reflector adds new matching IPv6 extension headers for the reverse
path.
Gandhi, et al. Expires 5 January 2027 [Page 7]
Internet-Draft STAMP for Reflecting IP Headers July 2026
In the two-way measurement type, the Session-Reflector adds new
matching IPv6 extension headers in the Session-Reflector test packets
in the same order as received in the Session-Sender test packets for
the reverse direction measurement. The length and content of the new
IPv6 extension headers added in the Session-Reflector test packets is
a local decision at the Session-Reflector. The STAMP Session-Sender
enables this type by adding the "IPv6 Extension Header Control" Sub-
TLV for the "Reflected Test Packet Control" TLV in the Session-Sender
test packets.
In the one-way measurement type, the Session-Reflector does not add
new matching IPv6 extension headers in the Session-Reflector test
packets corresponding to the received IPv6 extension headers in the
Session-Sender test packets. However, the Session-Reflector still
copies received IPv6 extension headers into the "Reflected IPv6
Extension Header Data" TLVs as specified in Section 3.1. This type
is the default if the "IPv6 Extension Header Control" Sub-TLV is
absent in the Session-Sender test packet.
The measurement type for a STAMP session is locally provisioned on
the STAMP Session-Sender.
3.2. Procedure for Reflecting Fixed Headers
This document defines a new TLV option for STAMP, called "Reflected
Fixed Header Data" (value TBA2). The STAMP TLV can be used to
reflect any fixed-size header received in a Session-Sender test
packet, including IPv4 and IPv6 headers. When a STAMP Session-Sender
adds an IP header, the Session-Sender also adds a "Reflected Fixed
Header Data" TLV in the Session-Sender test packet with the length
set to the IP header length to receive a copy of that IP header back
in the STAMP TLV.
An example STAMP test packet carrying an IP header and reflected data
in the "Reflected Fixed Header Data" TLV is shown in Figure 3.
+---------------------------------------------------------------+
| IP Header |
+---------------------------------------------------------------+
| UDP Header |
+---------------------------------------------------------------+
| STAMP Packet RFC 8972 |
+---------------------------------------------------------------+
| Reflected Fixed Header Data STAMP TLV (TBA2) |
+---------------------------------------------------------------+
Figure 3: Example Session-Sender and Session-Reflector Test
Packet with "Reflected Fixed Header Data" TLV
Gandhi, et al. Expires 5 January 2027 [Page 8]
Internet-Draft STAMP for Reflecting IP Headers July 2026
When adding multiple IP headers in a Session-Sender test packet, the
corresponding "Reflected Fixed Header Data" TLVs MUST also be added,
with lengths matching the corresponding IP header lengths and in the
same order, to receive copies of those IP headers. When the Session-
Sender test packets carry an IP header that the Session-Sender does
not require the Session-Reflector to reflect in Session-Reflector
test packets, the Session-Sender MUST NOT add a corresponding
"Reflected Fixed Header Data" TLV in the Session-Sender test packets.
In this case, the number of "Reflected Fixed Header Data" TLVs in the
Session-Sender test packet would be less than the number of IP
headers in the packet.
The number of "Reflected Fixed Header Data" TLVs MUST be less than or
equal to the number of IP headers in the Session-Sender test packet.
When the Session-Reflector receives a STAMP test packet with an IP
header and a "Reflected Fixed Header Data" TLV, the following rules
apply:
1. The Session-Reflector that supports this TLV MUST copy the IP
header into the "Reflected Fixed Header Data" TLV in the Session-
Reflector test packet.
2. When there are multiple IP headers in the received Session-Sender
test packet, each IP header MUST be processed in order, starting from
the outer header, and copied into the corresponding "Reflected Fixed
Header Data" TLV in the Session-Reflector test packet, if that STAMP
TLV exists.
3. When the Session-Reflector receives a STAMP test packet with an
IP header but without a corresponding "Reflected Fixed Header Data"
TLV, the Session-Reflector does not copy the IP header into the
Session-Reflector test packet.
The value field in the "Reflected Fixed Header Data" TLV in Session-
Sender test packets can be initialized to zeros. The Session-Sender
MUST copy the "Requested Fixed Header Data" field (shown in Figure 7)
using the first 4 octets from the IP header if there is an ambiguity
when there are multiple IP headers with the same length present and
not all need to be copied and reflected in the STAMP TLVs. This
method assumes that the first 4 octets in the IP header do not change
before being received at the Session-Reflector. If the Session-
Reflector receives Session-Sender test packets with non-zero values
in the "Requested Fixed Header Data" field of the "Reflected Fixed
Header Data" TLV, it MUST match the first 4 octets in the
corresponding IP header before copying data into the STAMP TLV.
Gandhi, et al. Expires 5 January 2027 [Page 9]
Internet-Draft STAMP for Reflecting IP Headers July 2026
The Session-Sender and Session-Reflector MUST ensure that the
resulting test packets do not exceed the IP MTU after adding
"Reflected Fixed Header Data" TLVs. If necessary, one or more
"Reflected Fixed Header Data" TLVs MUST be removed to avoid violating
the IP MTU limit.
3.3. Reflecting Fixed Headers and IPv6 Extension Headers
STAMP test packets can be used to reflect both IP headers and IPv6
extension headers by carrying the corresponding "Reflected Fixed
Header Data" and "Reflected IPv6 Extension Header Data" TLVs. A
STAMP test packet carrying an IPv6 header and an IPv6 extension
header along with their corresponding "Reflected Fixed Header Data"
and "Reflected IPv6 Extension Header Data" TLV is shown in Figure 4.
+---------------------------------------------------------------+
| IPv6 Header |
+---------------------------------------------------------------+
| IPv6 Extension Header RFC 8200 |
+---------------------------------------------------------------+
| UDP Header |
+---------------------------------------------------------------+
| STAMP Packet RFC 8972 |
+---------------------------------------------------------------+
| Reflected Fixed Header Data STAMP TLV (TBA2) |
+---------------------------------------------------------------+
| Reflected IPv6 Extension Header Data STAMP TLV (TBA1) |
+---------------------------------------------------------------+
Figure 4: Example Session-Sender and Session-Reflector Test
Packet with "Reflected Fixed Header Data" and "Reflected IPv6
Extension Header Data" TLVs
The "Reflected Fixed Header Data" TLVs MUST be added before adding
the "Reflected IPv6 Extension Header Data" TLVs to maintain the same
order as the IP headers and IPv6 extension headers in the Session-
Sender test packets. If the "Reflected Fixed Header Data" TLVs and
the "Reflected IPv6 Extension Header Data" TLVs are not received in
this order, the Session-Reflector MUST return these TLVs with the C
flag (Conformance) set to 1 in the STAMP TLV Flags using the
procedure defined in [I-D.ietf-ippm-asymmetrical-pkts], but without
copying any data in these STAMP TLVs.
Gandhi, et al. Expires 5 January 2027 [Page 10]
Internet-Draft STAMP for Reflecting IP Headers July 2026
4. Use Case of Reflecting IOAM Data Fields
In Situ Operations, Administration, and Maintenance (IOAM) is used
for recording and collecting operational and telemetry information
while the packet traverses a path between two points in the network.
The IOAM data fields are defined in [RFC9197]. Examples of data
recorded by IOAM Trace Options include per-hop information, such as
node ID, timestamp, queue depth, interface ID, and interface load.
The information collected can be used for monitoring ECMP paths,
proof-of-transit, and troubleshooting failures in the network. IOAM
can be used with STAMP test packets for active measurements. The
procedure and STAMP extensions defined in this document can be used
to reflect the collected IOAM data fields back to the Session-Sender,
where the Session-Sender can use this information to support HBH and
E2E measurement use cases.
[RFC9486] defines types for HBH and destination options headers and
is used to carry the IOAM option types defined in [RFC9197] for the
IPv6 data plane. The STAMP Session-Sender and Session-Reflector test
packets carry the IPv6 options headers with IOAM option types for
recording and collecting HBH and E2E operational and telemetry
information for active measurements, as shown in Figure 5. The
Session-Sender node, midpoint nodes, and the Session-Reflector node
process the IOAM data fields, as defined in [RFC9197]. Note that
using the IOAM option type "Incremental Trace Option-Type" is not
supported by [RFC9486].
+---------------------------------------------------------------+
| IPv6 Header |
+---------------------------------------------------------------+
| HBH IOAM IPv6 Options Header RFC 9486 |
+---------------------------------------------------------------+
| UDP Header |
+---------------------------------------------------------------+
| STAMP Packet RFC 8972 |
+---------------------------------------------------------------+
| Reflected IPv6 Extension Header Data STAMP TLV (TBA1) |
+---------------------------------------------------------------+
Figure 5: Example Session-Sender and Session-Reflector Test
Packet for IOAM with Reflected IPv6 Extension Header Data TLV
Gandhi, et al. Expires 5 January 2027 [Page 11]
Internet-Draft STAMP for Reflecting IP Headers July 2026
IOAM Direct Exporting (DEX) [RFC9326] is applicable with STAMP test
packets for on-path telemetry use cases as described in
[I-D.ietf-ippm-on-path-active-measurements]. In this case, the
Session-Reflector is not required to reflect the IOAM option type,
since no IOAM data fields would be recorded in the STAMP test
packets. Hence, the Session-Sender MAY not include a corresponding
"Reflected IPv6 Extension Header Data" TLV in Session-Sender test
packets for the IOAM DEX option type.
5. STAMP Extensions
5.1. Reflected IPv6 Extension Header Data TLV
The "Reflected IPv6 Extension Header Data" TLV is carried by Session-
Sender and Session-Reflector test packets. STAMP test packets MAY
carry one or more STAMP TLVs of this type. The same "Reflected IPv6
Extension Header Data" TLV Type is used for reflecting different IPv6
extension headers, including HBH and Destination IPv6 options
headers. The format of the "Reflected IPv6 Extension Header Data"
TLV is shown in Figure 6.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type=TBA1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested IPv6 Extension Header Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reflected IPv6 Extension Header Data |
~ (Length - 4 octets) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Reflected IPv6 Extension Header Data TLV
The STAMP TLV fields are defined as follows:
Type: STAMP TLV Type (value TBA1).
STAMP TLV Flags: The STAMP TLV Flags follow the procedures described
in [RFC8972].
Length: A two-octet field equal to the total length of the Requested
and Reflected IPv6 Extension Header Data fields combined, in octets.
Requested IPv6 Extension Header Data: A fixed 4-octet field
containing the first 4 octets of the target IPv6 extension header to
be reflected (starting from the Next Header field). This field is
Gandhi, et al. Expires 5 January 2027 [Page 12]
Internet-Draft STAMP for Reflecting IP Headers July 2026
used to disambiguate which IPv6 extension header in the received
Session-Sender test packet MUST be copied into the Reflected field
when multiple IPv6 extension headers of the same length are present.
When this field is set to all zeros, the Session-Reflector MUST match
the first IPv6 extension header in the Session-Sender test packet
with the matching length.
Reflected IPv6 Extension Header Data: A variable-length field of
(Length - 4) octets containing the reflected IPv6 extension header
copied from the received Session-Sender test packet by the Session-
Reflector. In Session-Sender test packets, this field MUST be
initialized to zero.
When the Session-Reflector recognizes the received "Reflected IPv6
Extension Header Data" TLV but could not use it for reflecting any
IPv6 extension header received, the Session-Reflector MUST return the
"Reflected IPv6 Extension Header Data" TLV with the C flag
(Conformance TLV) set to 1 in the STAMP TLV Flags using the procedure
defined in [I-D.ietf-ippm-asymmetrical-pkts]. This can occur, for
example if: (a) there is a mismatch between the expected length in
"Reflected IPv6 Extension Header Data" TLVs and the received IPv6
extension headers, (b) the Session-Reflector cannot access the
received IPv6 extension headers from the data plane, (c) no IPv6
extension header matches the "Requested IPv6 Extension Header Data"
field, etc.
5.2. Reflected Fixed Header Data TLV
The "Reflected Fixed Header Data" TLV is carried by Session-Sender
and Session-Reflector test packets. STAMP test packets MAY carry one
or more STAMP TLVs of this type. The format of the "Reflected Fixed
Header Data" TLV is shown in Figure 7.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type=TBA2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Fixed Header Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reflected Fixed Header Data |
~ (Length - 4 octets) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Reflected Fixed Header Data TLV
The STAMP TLV fields are defined as follows:
Gandhi, et al. Expires 5 January 2027 [Page 13]
Internet-Draft STAMP for Reflecting IP Headers July 2026
Type: STAMP TLV Type (value TBA2).
STAMP TLV Flags: The STAMP TLV Flags follow the procedures described
in [RFC8972].
Length: A two-octet field equal to the total length of the Requested
and Reflected Fixed Header Data fields combined, in octets. For an
IPv4 header, the length is set to 20, and for an IPv6 header, the
length is set to 40.
Requested Fixed Header Data: A fixed 4-octet field containing the
first 4 octets of the target IP header to be reflected. This field
is used to disambiguate which IP header in the received Session-
Sender test packet MUST be copied into the Reflected field when
multiple IP headers of the same length are present in the Session-
Sender test packet. When this field is set to all zeros, the
Session-Reflector MUST match the first IP header in the Session-
Sender test packet with the matching length.
Reflected Fixed Header Data: A variable-length field of (Length - 4)
octets containing the reflected IP header copied from the received
Session-Sender test packet by the Session-Reflector. In Session-
Sender test packets, this field MUST be initialized to zero.
When the Session-Reflector recognizes the received "Reflected Fixed
Header Data" TLV but could not use it for reflecting any IP header
received, the Session-Reflector MUST return the "Reflected Fixed
Header Data" TLV with the C flag (Conformance TLV) set to 1 in the
STAMP TLV Flags using the procedure defined in
[I-D.ietf-ippm-asymmetrical-pkts]. This can occur, for example if:
(a) there is a mismatch between the expected length in "Reflected
Fixed Header Data" TLVs and the received IP headers, (b) the Session-
Reflector cannot access the received IP headers from the data plane,
(c) no IP header matches the "Requested Fixed Header Data" field,
etc.
5.3. IPv6 Extension Header Control Sub-TLV
This document defines the "IPv6 Extension Header Control" Sub-TLV
(Type TBA3) for the "Reflected Test Packet Control" TLV (Type 12)
introduced in [I-D.ietf-ippm-asymmetrical-pkts]. The format of "IPv6
Extension Header Control" Sub-TLV is shown in Figure 8.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Flags | Type = TBA3 | Sub-TLV Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Gandhi, et al. Expires 5 January 2027 [Page 14]
Internet-Draft STAMP for Reflecting IP Headers July 2026
Figure 8: IPv6 Extension Header Control Sub-TLV
The Sub-TLV fields are defined as follows:
Type: Sub-TLV Type (value TBA3).
Sub-TLV Flags: The Sub-TLV Flags follow the procedure for STAMP TLV
Flags described in [RFC8972].
Sub-TLV Length: A two-octet field equal to the length of the Data in
octets. It is set to 0.
When the Session-Reflector receives a STAMP test packet with the
"IPv6 Extension Header Control" Sub-TLV, the following rules apply:
1. The Session-Reflector MUST add new matching IPv6 extension
headers in the Session-Reflector STAMP test packet in the same order
corresponding to the received IPv6 extension headers (except the
routing extension headers specific to the Session-Sender test
packet).
2. In the absence of the "IPv6 Extension Header Control" Sub-TLV in
the received Session-Sender test packet, the Session-Reflector MAY
not add new matching IPv6 extension headers corresponding to the
received IPv6 extension headers in the Session-Reflector test packet.
This behaviour can be based on a local policy on the Session-
Reflector.
3. The IPv6 extension headers received in the Session-Sender test
packets MUST be copied and reflected in the corresponding "Reflected
IPv6 Extension Header Data" TLVs to the Session-Sender regardless of
whether "IPv6 Extension Header Control" Sub-TLV is present or not.
4. If the Session-Reflector cannot add a new matching IPv6 extension
header in the Session-Reflector test packet, the Session-Reflector
MUST return the "Reflected Test Packet Control" TLV with the C flag
(Conformance) set to 1 in the Sub-TLV Flags of the "IPv6 Extension
Header Control" Sub-TLV using the procedure defined in
[I-D.ietf-ippm-asymmetrical-pkts]. This can occur, for example, when
the Session-Reflector does not support the IPv6 extension header, or
when the Session-Reflector cannot access the received IPv6 extension
headers from the data plane.
STAMP test packets MUST NOT carry more than one "IPv6 Extension
Header Control" Sub-TLV in a "Reflected Test Packet Control" TLV. If
the "Reflected Test Packet Control" TLV in the Session-Sender test
packet contains more than one "IPv6 Extension Header Control" Sub-
TLV, the Session-Reflector MUST return the "Reflected Test Packet
Gandhi, et al. Expires 5 January 2027 [Page 15]
Internet-Draft STAMP for Reflecting IP Headers July 2026
Control" TLV with the C flag (Conformance TLV) set to 1 in the Sub-
TLV Flags of all "IPv6 Extension Header Control" Sub-TLVs, using the
procedure defined in [I-D.ietf-ippm-asymmetrical-pkts].
6. Operational Considerations
The operational considerations specified in [RFC8762] and
[I-D.ietf-ippm-asymmetrical-pkts] apply to the procedure and
extensions defined in this document.
In addition, the Management and Deployment Considerations specified
in [RFC9197] also apply when using the IOAM data fields defined in
that document.
An operator MAY provision a local policy on a Session-Reflector to
not copy and reflect the received IPv6 extension headers and IP
headers in the Session-Reflector test packets to avoid exposing the
collected network information to the Session-Sender.
7. Security Considerations
The security considerations specified in [RFC8762], [RFC8972],
[RFC8200], and [I-D.ietf-ippm-asymmetrical-pkts] apply to the
procedure and extensions defined in this document. In addition, the
security considerations specified in [RFC9197] and [RFC9486] also
apply when using IPv6 options for IOAM data fields.
The procedures defined in this document are intended for deployment
in a single network administrative domain. It is assumed that the
operator has verified the integrity of the forward and return paths
used to transmit STAMP test packets so that collected network
information is not exposed on an undesired node.
If desired, attacks can be mitigated by performing basic validation
checks of the timestamp fields (such as verifying that T2 is later
than T1 in the STAMP Reference Topology shown in Figure 1) in
received reply test packets at the Session-Sender. The minimal state
associated with these protocols also limits the extent of measurement
disruption that can be caused by a corrupt or invalid test packet to
a single test cycle.
Furthermore, implementations SHOULD NOT assign STAMP Session-IDs
[RFC8972] in a predictable manner. In order to avoid predictability,
implementations can leverage a Cryptographically Secure Pseudorandom
Number Generator [NIST-CSPRNG].
Gandhi, et al. Expires 5 January 2027 [Page 16]
Internet-Draft STAMP for Reflecting IP Headers July 2026
8. Implementation Status
Editorial note: Please remove this section prior to publication.
An open-source implementation of the Simple Two-Way Active
Measurement Protocol [RFC8762] is available in Teaparty.
https://github.com/cerfcast/teaparty
An implementation of the solution in this document is available at
the following location:
https://github.com/cerfcast/teaparty/
commit/393abf9357a6c2439877d9bcf2dc426dd89c7158
The implemented features are as follows:
1. Extraction of the extension headers from the IPv6 headers of the
received STAMP test packet.
2. Reflection of the extension headers in the reflected STAMP TLV
data (with checks for matching length).
3. Adding the extension headers to the IP header of the reflected
STAMP test packet.
4. Support for multiple IPv6 extension headers.
5. Reflection of the fixed IPv6 header in the reflected STAMP TLV
data.
There is also support for the reflected IPv6 extension header TLV
data in the Wireshark dissector:
https://github.com/cerfcast/teaparty/commit/
fb74e2e02396e9bb3ead017e8d9a0c187e3573e2
There is also support for tools to test the reflected IPv6 extension
header TLV data:
https://github.com/cerfcast/teaparty/tree/main/testing_data#testing-
reflected-ipv6-extension-header-data
Contact:
William Hawkins
University of Cincinnati
Gandhi, et al. Expires 5 January 2027 [Page 17]
Internet-Draft STAMP for Reflecting IP Headers July 2026
Email: hawkinsw@obs.cr
9. IANA Considerations
IANA has created the "STAMP TLV Types" registry for [RFC8972]. IANA
is requested to allocate a value for the "Reflected IPv6 Extension
Header Data" TLV Type and a value for the "Reflected Fixed Header
Data" TLV Type from the IETF Review TLV range of the same registry.
+=======+======================================+===============+
| Value | Description | Reference |
+=======+======================================+===============+
| TBA1 | Reflected IPv6 Extension Header Data | This document |
+-------+--------------------------------------+---------------+
| TBA2 | Reflected Fixed Header Data | This document |
+-------+--------------------------------------+---------------+
Table 1: STAMP TLV Types
IANA is requested to allocate a value for the Sub-TLV Type "IPv6
Extension Header Control" (Type TBA3) for the STAMP TLV Type
"Reflected Test Packet Control" (Type 12) defined in
[I-D.ietf-ippm-asymmetrical-pkts], from the "STAMP Sub-TLV Types"
registry.
+=======+================+================+===========+
| Value | Description | TLV Used | Reference |
+=======+================+================+===========+
| TBA3 | IPv6 Extension | Reflected Test | This |
| | Header Control | Packet Control | document |
+-------+----------------+----------------+-----------+
Table 2: Sub-TLV Type for Reflected Test Packet
Control TLV
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Gandhi, et al. Expires 5 January 2027 [Page 18]
Internet-Draft STAMP for Reflecting IP Headers July 2026
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple
Two-Way Active Measurement Protocol", RFC 8762,
DOI 10.17487/RFC8762, March 2020,
<https://www.rfc-editor.org/info/rfc8762>.
[RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A.,
and E. Ruffini, "Simple Two-Way Active Measurement
Protocol Optional Extensions", RFC 8972,
DOI 10.17487/RFC8972, January 2021,
<https://www.rfc-editor.org/info/rfc8972>.
[RFC9673] Hinden, R. and G. Fairhurst, "IPv6 Hop-by-Hop Options
Processing Procedures", RFC 9673, DOI 10.17487/RFC9673,
October 2024, <https://www.rfc-editor.org/info/rfc9673>.
[I-D.ietf-ippm-asymmetrical-pkts]
Mirsky, G., Ruffini, E., Nydell, H., Foote, R. F., and W.
Hawkins, "Performance Measurement with Asymmetrical
Traffic Using Simple Two-Way Active Measurement Protocol
(STAMP)", Work in Progress, Internet-Draft, draft-ietf-
ippm-asymmetrical-pkts-14, 16 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-
asymmetrical-pkts-14>.
10.2. Informative References
[RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6
Performance and Diagnostic Metrics (PDM) Destination
Option", RFC 8250, DOI 10.17487/RFC8250, September 2017,
<https://www.rfc-editor.org/info/rfc8250>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi,
Ed., "Data Fields for In Situ Operations, Administration,
and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197,
May 2022, <https://www.rfc-editor.org/info/rfc9197>.
Gandhi, et al. Expires 5 January 2027 [Page 19]
Internet-Draft STAMP for Reflecting IP Headers July 2026
[RFC9268] Hinden, R. and G. Fairhurst, "IPv6 Minimum Path MTU Hop-
by-Hop Option", RFC 9268, DOI 10.17487/RFC9268, August
2022, <https://www.rfc-editor.org/info/rfc9268>.
[RFC9326] Song, H., Gafni, B., Brockners, F., Bhandari, S., and T.
Mizrahi, "In Situ Operations, Administration, and
Maintenance (IOAM) Direct Exporting", RFC 9326,
DOI 10.17487/RFC9326, November 2022,
<https://www.rfc-editor.org/info/rfc9326>.
[RFC9343] Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R.
Pang, "IPv6 Application of the Alternate-Marking Method",
RFC 9343, DOI 10.17487/RFC9343, December 2022,
<https://www.rfc-editor.org/info/rfc9343>.
[RFC9486] Bhandari, S., Ed. and F. Brockners, Ed., "IPv6 Options for
In Situ Operations, Administration, and Maintenance
(IOAM)", RFC 9486, DOI 10.17487/RFC9486, September 2023,
<https://www.rfc-editor.org/info/rfc9486>.
[I-D.ietf-ippm-on-path-active-measurements]
Fioccola, G., Zhu, K., Zhou, T., Zhu, Y., and X. Min, "On-
Path Telemetry for Active Performance Measurements", Work
in Progress, Internet-Draft, draft-ietf-ippm-on-path-
active-measurements-02, 26 February 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-on-
path-active-measurements-02>.
[NIST-CSPRNG]
NIST Special Publication 800-90A, "Recommendation for
Random Number Generation Using Deterministic Random Bit
Generators", January 2012.
Acknowledgments
The authors would like to thank Greg Mirsky, Xiao Min, Tal Mizrahi,
Cheng Li, Giuseppe Fioccola, Richard "Footer" Foote, and Jie Dong for
reviewing this document and providing many useful comments and
suggestions. The authors also thank William Hawkins for implementing
the solution defined in this document in Teaparty. Thank you to Xiao
Min for the PerfMetrdir review which helped improve this document.
Authors' Addresses
Rakesh Gandhi (editor)
Cisco Systems, Inc.
Canada
Email: rgandhi@cisco.com
Gandhi, et al. Expires 5 January 2027 [Page 20]
Internet-Draft STAMP for Reflecting IP Headers July 2026
Tianran Zhou
Huawei
China
Email: zhoutianran@huawei.com
Zhenqiang Li
China Mobile
China
Email: lizhenqiang@chinamobile.com
William Hawkins
University of Cincinnati
United States of America
Email: hawkinsw@obs.cr
Gandhi, et al. Expires 5 January 2027 [Page 21]