Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet IP Headers
draft-ietf-ippm-stamp-ext-hdr-17
| Document | Type | Active Internet-Draft (ippm WG) | |
|---|---|---|---|
| Authors | Rakesh Gandhi , Tianran Zhou , Zhenqiang Li , Will Hawkins | ||
| Last updated | 2026-10-15 (Latest revision 2026-10-14) | ||
| Replaces | draft-gandhi-ippm-stamp-ext-hdr | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Reviews |
INTDIR IETF Last Call review
(of
-16)
by Shwetha Bhandari
Ready w/issues
TSVART IETF Last Call review
(of
-16)
by Wesley Eddy
Ready w/issues
ARTART IETF Last Call review
(of
-15)
by Marc Blanchet
Ready w/issues
SECDIR IETF Last Call Review due 2026-10-15
Incomplete
OPSDIR IETF Last Call Review due 2026-10-15
Incomplete
GENART IETF Last Call Review due 2026-10-15
Incomplete
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Marcus Ihlar | ||
| Shepherd write-up | Show Last changed 2026-09-28 | ||
| IESG | IESG state | IESG Evaluation | |
| Action Holder | |||
| Consensus boilerplate | Yes | ||
| Telechat date |
On agenda of 2026-10-22 IESG telechat
Needs 8 more YES or NO OBJECTION positions to pass. |
||
| Responsible AD | Mohamed Boucadair | ||
| Send notices to | marcus.ihlar@ericsson.com | ||
| IANA | IANA review state | IANA OK - Actions Needed |
draft-ietf-ippm-stamp-ext-hdr-17
IPPM Working Group R. Gandhi, Ed.
Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track T. Zhou
Expires: 17 April 2027 Huawei
Z. Li
China Mobile
W. Hawkins
University of Cincinnati
14 October 2026
Simple Two-Way Active Measurement Protocol (STAMP) Extensions for
Reflecting STAMP Packet IP Headers
draft-ietf-ippm-stamp-ext-hdr-17
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 IPv4/IPv6 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 17 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Gandhi, et al. Expires 17 April 2027 [Page 1]
Internet-Draft STAMP for Reflecting IP Headers October 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
2.4. STAMP Reference Topology . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. IPv4/IPv6 and UDP Headers . . . . . . . . . . . . . . . . 6
4. Reflecting IPv6 Extension Headers . . . . . . . . . . . . . . 7
4.1. Reflected IPv6 Extension Header Data TLV . . . . . . . . 7
4.2. Procedure for Reflecting IPv6 Extension Headers . . . . . 9
4.3. Receiving IPv6 Extension Headers from the Data Plane . . 11
5. Unidirectional and Bidirectional Measurements . . . . . . . . 11
5.1. IPv6 Extension Header Control Sub-TLV . . . . . . . . . . 11
5.2. Procedure for IPv6 Extension Header Control . . . . . . . 13
6. Reflecting Fixed Headers . . . . . . . . . . . . . . . . . . 14
6.1. Reflected Fixed Header Data TLV . . . . . . . . . . . . . 14
6.2. Procedure for Reflecting Fixed Headers . . . . . . . . . 16
7. Additional Considerations . . . . . . . . . . . . . . . . . . 18
7.1. Reflecting Fixed Headers and IPv6 Extension Headers . . . 18
7.2. MTU Considerations . . . . . . . . . . . . . . . . . . . 19
8. Use Case of Reflecting IOAM Data Fields . . . . . . . . . . . 19
9. UDP Checksum Handling . . . . . . . . . . . . . . . . . . . . 20
9.1. IPv4 UDP Zero Checksum . . . . . . . . . . . . . . . . . 21
9.2. IPv6 UDP Zero Checksum . . . . . . . . . . . . . . . . . 21
10. Operational Considerations . . . . . . . . . . . . . . . . . 23
10.1. Verifying Received IPv6 Extension Headers . . . . . . . 24
10.2. STAMP Session State Notification . . . . . . . . . . . . 24
10.3. Rate Limiting . . . . . . . . . . . . . . . . . . . . . 25
11. Security Considerations . . . . . . . . . . . . . . . . . . . 25
12. Implementation Status . . . . . . . . . . . . . . . . . . . . 26
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
14.1. Normative References . . . . . . . . . . . . . . . . . . 28
14.2. Informative References . . . . . . . . . . . . . . . . . 29
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
Gandhi, et al. Expires 17 April 2027 [Page 2]
Internet-Draft STAMP for Reflecting IP Headers October 2026
1. Introduction
The Simple Two-Way Active Measurement Protocol (STAMP) [RFC8762]
provides capabilities for the measurement of various performance
metrics in IP networks 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 (E2E) performance metrics, such as delay, delay
variation, and packet loss along that path.
In Situ Operations, Administration, and Maintenance (IOAM) is used
for recording and collecting operational and telemetry information
while a packet traverses a path between two points in the network.
The information from the collected IOAM data fields [RFC9197] can be
used to support Hop-by-Hop (HBH) and E2E measurement use cases.
IPv6 packets may carry IPv6 extension headers, including Hop-by-Hop
Options headers and Destination Options headers, as specified 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 specified in [RFC9197] and
[RFC9326] for the IPv6 data plane.
It may be desirable in some contexts (e.g., diagnostics) 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 using optional STAMP extensions to reflect IPv4/IPv6
headers as well as IPv6 extension headers as specified in this
document. The procedure specified 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.
[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.
This document specifies requirements for IPv6 STAMP using UDP zero
checksum that deviate from the integrity requirement in [RFC6936].
Refer to Section 9.2 for more details.
Gandhi, et al. Expires 17 April 2027 [Page 3]
Internet-Draft STAMP for Reflecting IP Headers October 2026
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. Terminology
This document uses terms defined in [RFC8762], specifically Session-
Sender, Session-Reflector, Session-Test packet, and symmetric.
This document uses terms defined in [RFC8972], specifically STAMP TLV
Flags and Sub-TLVs.
2.3. Abbreviations
+==============+=================================+===========+
| Abbreviation | Meaning | Reference |
+==============+=================================+===========+
| E2E | Edge-to-Edge | [RFC9197] |
+--------------+---------------------------------+-----------+
| HBH | Hop-by-Hop | [RFC8200] |
+--------------+---------------------------------+-----------+
| IOAM | In Situ Operations, | [RFC9197] |
| | Administration, and Maintenance | |
+--------------+---------------------------------+-----------+
| MTU | Maximum Transmission Unit | [RFC8200] |
+--------------+---------------------------------+-----------+
| STAMP | Simple Two-Way Active | [RFC8762] |
| | Measurement Protocol | |
+--------------+---------------------------------+-----------+
| TLV | Type-Length-Value | [RFC8972] |
+--------------+---------------------------------+-----------+
| TTL | Time to Live | [RFC8200] |
+--------------+---------------------------------+-----------+
Table 1: Abbreviations
Gandhi, et al. Expires 17 April 2027 [Page 4]
Internet-Draft STAMP for Reflecting IP Headers October 2026
2.4. 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. The Session-Reflector test packets are transmitted to the
Session-Sender S1 on the same path (i.e., the same set of links and
nodes as shown in Figure 1) or on a different path in the reverse
direction from the path taken towards the Session-Reflector R1. Node
M1 is a midpoint node along the path that does not perform any STAMP
processing. A STAMP-Test packet is not required to transit through
the same midpoint node M1 in both directions.
T1 T2
/ \
+-------+ Test Packet +-------+ +-------+
| | - - - - - - - - | | - - - - - - - - ->| |
| S1 |=================| M1 |===================| R1 |
| |<- - - - - - - - | | - - - - - - - - - | |
+-------+ +-------+ Reply Test Packet +-------+
\ /
T4 T3
STAMP Session-Sender STAMP Session-Reflector
Figure 1: STAMP Reference Topology
T1 is a transmit timestamp and T4 is a receive timestamp added by
node S1. T2 is a receive timestamp and T3 is a transmit timestamp
added by node R1.
All four timestamps are used by the Session-Sender to measure the
two-way delay metric as ((T4 - T1) - (T3 - T2)). The "two-way delay"
is the sum of the one-way delays in each direction and reflects the
delay of the bidirectional path, irrespective of processing delays
within the Session-Reflector.
Timestamps T1 and T2 are used by the Session-Sender to measure the
one-way delay metric as (T2 - T1), also referred to as the near-end
(forward direction) delay metric. Note that the delay value (T4 -
T3), measured by the Session-Sender, is referred to as the far-end
(backward direction) one-way delay metric. The computation of the
one-way delay metric requires the clocks on the Session-Sender and
Session-Reflector to be synchronized using either PTPv2 or NTPv4.
Gandhi, et al. Expires 17 April 2027 [Page 5]
Internet-Draft STAMP for Reflecting IP Headers October 2026
3. Overview
As specified in [RFC8972], the Session-Sender test packets and the
Session-Reflector test packets are symmetric in size when including
all optional TLVs (but excluding transport and network headers). A
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.
STAMP-Test packets may carry IPv4/IPv6 headers and IPv6 extension
headers. This document defines procedures and STAMP extensions for a
Session-Reflector to reflect the received IPv4/IPv6 headers and IPv6
extension headers back to the Session-Sender for both unidirectional
and bidirectional measurement types, as specified in Section 5.
3.1. IPv4/IPv6 and UDP Headers
The IPv4/IPv6 and UDP headers specified in this section apply to all
STAMP sessions using an IP/UDP header and are not limited to sessions
using the extensions specified in this document.
The STAMP Session-Sender and Session-Reflector IP addresses for a
STAMP session are provisioned on both ends of the STAMP session. How
this provisioning is achieved is outside the scope of this document.
The base STAMP-Test packet payloads can be transported using a UDP
header with destination UDP port number 862 as the default
destination UDP port, as specified in Section 4.1 of [RFC8762], or
using a UDP port number from the User Ports or Dynamic Ports ranges
as defined in Section 6 of [RFC6335].
The source UDP port number is chosen as follows:
* The source UDP port number SHOULD be chosen using a randomized
allocation method as specified in [RFC6056] to provide protection
against off-path attacks, as recommended in [RFC8085].
* The source UDP port number SHOULD be chosen from the Dynamic Ports
range (49152-65535) [RFC6335] to avoid conflicts with well-known
and registered service ports.
* The source UDP port number MUST distinguish between the received
Session-Reflector test packets and the Session-Sender test packets
from the reverse direction.
Gandhi, et al. Expires 17 April 2027 [Page 6]
Internet-Draft STAMP for Reflecting IP Headers October 2026
The IPv4 TTL and IPv6 Hop Limit MUST be set to 255 in both Session-
Sender and Session-Reflector test packets, which allows determination
of the number of hops that forwarded a test packet. Both the
Session-Sender and the Session-Reflector MUST NOT discard the
received Session-Sender STAMP-Test packet only because it contains a
TTL or IPv6 Hop Limit value of 255.
4. Reflecting IPv6 Extension Headers
4.1. Reflected IPv6 Extension Header Data TLV
This document defines the "Reflected IPv6 Extension Header Data" TLV
for STAMP (Type TBA1). A Session-Sender uses this TLV to request
reflection of an IPv6 extension header received in its test packet.
The TLV is carried in Session-Sender and Session-Reflector test
packets, and a STAMP-Test packet MAY carry one or more TLVs of this
type. The same TLV type is used for different IPv6 extension
headers, including Hop-by-Hop Options and Destination Options
headers. The format of the TLV is shown in Figure 2.
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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Received IPv6 Extension Header Data |
~ (Length - 8 octets) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Reflected IPv6 Extension Header Data TLV
The "Reflected IPv6 Extension Header Data" TLV fields are defined as
follows:
* STAMP TLV Flags: The STAMP TLV Flags follow the procedures
specified in Section 4 of [RFC8972].
* Type: MUST be set to TBA1.
* Length: A two-octet field containing the total length, in octets,
of the IPv6 extension header to be reflected, beginning with its
Next Header field. It includes the lengths of the Requested IPv6
Extension Header Data field and the Received IPv6 Extension Header
Data field.
Gandhi, et al. Expires 17 April 2027 [Page 7]
Internet-Draft STAMP for Reflecting IP Headers October 2026
* Requested IPv6 Extension Header Data: A fixed 8-octet field
containing the first 8 octets of the target IPv6 extension header
to be reflected, beginning with its Next Header field.
This field disambiguates which IPv6 extension header in the
received Session-Sender test packet the Session-Reflector MUST
copy into the "Reflected IPv6 Extension Header Data" TLV when
multiple IPv6 extension headers of the same length are present.
If all octets in this field are zero, the Session-Reflector MUST
match the first IPv6 extension header in the Session-Sender test
packet with the matching length.
* Received IPv6 Extension Header Data: A variable-length field
containing the remaining (Length - 8) octets of the IPv6 extension
header after its first 8 octets, copied from the received Session-
Sender test packet by the Session-Reflector.
In Session-Sender test packets, the data in this field MUST be
initialized to all zeros.
When a Session-Reflector recognizes the received "Reflected IPv6
Extension Header Data" TLV but cannot use it to reflect a received
IPv6 extension header, it MUST return the "Reflected IPv6 Extension
Header Data" TLV with the Conformant Reflected Packet STAMP TLV flag
set to 1, following the procedure specified in [RFC10052]. This can
occur, for example, if:
* The requested length does not match the length of the received
IPv6 extension header.
* The Session-Reflector cannot access the received IPv6 extension
headers from the data plane, or the data plane does not support
the IPv6 extension header.
* No IPv6 extension header matches the requested data and length, or
the IPv6 extension header is invalid.
* More than one IPv6 extension header of the requested length
matches a non-zero Requested IPv6 Extension Header Data field.
Gandhi, et al. Expires 17 April 2027 [Page 8]
Internet-Draft STAMP for Reflecting IP Headers October 2026
4.2. Procedure for Reflecting IPv6 Extension Headers
For each IPv6 extension header [RFC8200] in a Session-Sender test
packet that the Session-Sender requires the Session-Reflector to
reflect, the Session-Sender MUST add a corresponding "Reflected IPv6
Extension Header Data" TLV (see Section 4.1) to the test packet. The
Session-Sender requests a copy of that IPv6 extension header in the
corresponding TLV in the Session-Reflector test packet.
An example of a STAMP-Test packet carrying an IPv6 header, IPv6
extension headers, and their corresponding "Reflected IPv6 Extension
Header Data" TLVs is shown in Figure 3.
+---------------------------------------------------------------+
| IPv6 Header |
+---------------------------------------------------------------+
| IPv6 Extension Header-1 [RFC8200] |
+---------------------------------------------------------------+
~ ... ~
+---------------------------------------------------------------+
| IPv6 Extension Header-N [RFC8200] |
+---------------------------------------------------------------+
| UDP Header |
+---------------------------------------------------------------+
| STAMP Packet [RFC8972] |
+---------------------------------------------------------------+
| Reflected IPv6 Extension Header-1 Data TLV (TBA1) |
+---------------------------------------------------------------+
~ ... ~
+---------------------------------------------------------------+
| Reflected IPv6 Extension Header-M Data TLV (TBA1) |
+---------------------------------------------------------------+
Note: Value of M <= N
Figure 3: Example Session-Sender and Session-Reflector Test
Packet with Reflected IPv6 Extension Header Data TLVs
When a Session-Sender test packet contains multiple IPv6 extension
headers that the Session-Sender requires the Session-Reflector to
reflect, the corresponding "Reflected IPv6 Extension Header Data"
TLVs MUST appear in the same order as those headers in the test
packet. When the Session-Sender does not require the Session-
Reflector to reflect an IPv6 extension header in the Session-
Reflector test packet, the Session-Sender MUST NOT add a
corresponding "Reflected IPv6 Extension Header Data" TLV to its test
packet. In this case, the number of TLVs (M in Figure 3) is less
than the number of IPv6 extension headers (N in Figure 3).
Gandhi, et al. Expires 17 April 2027 [Page 9]
Internet-Draft STAMP for Reflecting IP Headers October 2026
The number of "Reflected IPv6 Extension Header Data" TLVs MUST NOT
exceed the number of IPv6 extension headers in the Session-Sender
test packet.
If multiple IPv6 extension headers of the same length are present and
the Session-Sender requires the Session-Reflector to reflect only
some of them, the Session-Sender MUST populate the Requested IPv6
Extension Header Data field (see Figure 2) with the first 8 octets of
the IPv6 extension header to be reflected, beginning with its Next
Header field. This procedure assumes that these octets do not change
before the IPv6 extension header reaches the Session-Reflector. A
non-zero value in this field MUST match exactly one IPv6 extension
header of the requested length. An all-zero value continues to
select the first IPv6 extension header of the matching length. If
the requested header cannot be uniquely selected under these rules,
the Session-Sender MUST NOT request selective reflection of that
header.
When a Session-Reflector supports the "Reflected IPv6 Extension
Header Data" TLV and receives a Session-Sender test packet containing
a valid IPv6 extension header and a corresponding TLV, the following
rules apply:
1. If the Requested IPv6 Extension Header Data field in the received
TLV is non-zero and exactly one IPv6 extension header of the
requested length matches the field, the Session-Reflector MUST
select that header.
If a non-zero Requested IPv6 Extension Header Data field matches
more than one IPv6 extension header of the requested length, the
Session-Reflector MUST return the TLV with the Conformant
Reflected Packet STAMP TLV flag set to 1, following the procedure
specified in [RFC10052], and MUST NOT copy data from any of the
matching headers.
If the Requested IPv6 Extension Header Data field is all zeros,
the Session-Reflector MUST select the first IPv6 extension header
with the matching length and copy its first 8 octets, beginning
with its Next Header field, into the Requested IPv6 Extension
Header Data field of the TLV.
If no IPv6 extension header matches the requested data and
length, the Session-Reflector MUST return the "Reflected IPv6
Extension Header Data" TLV with the Conformant Reflected Packet
STAMP TLV flag set to 1, following the procedure specified in
[RFC10052].
Gandhi, et al. Expires 17 April 2027 [Page 10]
Internet-Draft STAMP for Reflecting IP Headers October 2026
2. The Session-Reflector MUST copy the portion of the IPv6 extension
header after its first 8 octets into the Received IPv6 Extension
Header Data field in the Session-Reflector test packet.
3. When the received Session-Sender test packet contains multiple
IPv6 extension headers, the Session-Reflector MUST process them
in order, starting with the outermost header, and copy each
header into its corresponding "Reflected IPv6 Extension Header
Data" TLV in the Session-Reflector test packet, if such a TLV is
present.
4. When a Session-Reflector receives a Session-Sender test packet
containing an IPv6 extension header without a corresponding
"Reflected IPv6 Extension Header Data" TLV, it cannot copy that
header into the Session-Reflector test packet.
Because this procedure leverages existing IPv6 extension header
implementations at midpoint nodes, no additional requirements are
imposed when these headers are carried in STAMP-Test packets. IPv6
extension headers are processed by midpoint nodes using the
procedures specified in their defining documents.
4.3. Receiving IPv6 Extension Headers from the Data Plane
When the received STAMP-Test packets are processed by the data plane
on the egress node hosting the Session-Reflector, the data plane MUST
provide the received IPv6 extension headers from the Session-Sender
test packets to the Session-Reflector for both unidirectional and
bidirectional measurement types (see Section 5).
Similarly, when the received STAMP-Test packets are processed by the
data plane in the reverse direction on an ingress node hosting the
Session-Sender, the data plane MUST provide the received IPv6
extension headers from the Session-Reflector test packets to the
Session-Sender for the bidirectional measurement type (see
Section 5).
5. Unidirectional and Bidirectional Measurements
5.1. 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)
[RFC10052]. The format of the "IPv6 Extension Header Control" Sub-
TLV is shown in Figure 4.
Gandhi, et al. Expires 17 April 2027 [Page 11]
Internet-Draft STAMP for Reflecting IP Headers October 2026
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IPv6 Extension Header Control Sub-TLV
The IPv6 Extension Header Control Sub-TLV fields are defined as
follows:
* Sub-TLV Flags: An eight-bit field. The format, values, and
interpretation of flags are as defined for STAMP TLV Flags
[RFC8972]. Flag values are taken from the "STAMP TLV Flags"
registry [IANA-STAMP].
* Type: MUST be set to TBA3.
* Sub-TLV Length: A two-octet field equal to the length of the Data
field in octets. It MUST be set to 0.
When a Session-Reflector receives a Session-Sender test packet with
the "IPv6 Extension Header Control" Sub-TLV and the Session-Reflector
supports this Sub-TLV, the following rules apply:
1. The Session-Reflector MUST add locally generated matching IPv6
extension headers, subject to the relevant IPv6 data-plane
specifications, in the same order in which the corresponding IPv6
extension headers, whether of the same or different types, appear
in the received Session-Sender test packet. The generated
headers need not be byte-for-byte copies of the received headers,
and routing headers specific to the Session-Sender are excluded
from this requirement.
2. In the absence of the "IPv6 Extension Header Control" Sub-TLV in
the received Session-Sender test packet, a Session-Reflector
omits adding locally generated matching IPv6 extension headers in
the Session-Reflector test packet corresponding to the received
IPv6 extension headers, based on its local policy. This does not
preclude the Session-Reflector from adding IPv6 extension headers
independently of the received IPv6 extension headers.
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 the "IPv6 Extension Header Control" Sub-TLV
is present.
Gandhi, et al. Expires 17 April 2027 [Page 12]
Internet-Draft STAMP for Reflecting IP Headers October 2026
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
(Type 12) [RFC10052] with the Conformant Reflected Packet STAMP
TLV flag set to 1 in the Sub-TLV Flags of the "IPv6 Extension
Header Control" Sub-TLV using the procedure specified in
[RFC10052]. 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
(Type 12) [RFC10052]. If the "Reflected Test Packet Control" TLV
(Type 12) 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 Control" TLV (Type 12) with the
Conformant Reflected Packet STAMP TLV flag set to 1 in the Sub-TLV
Flags of each "IPv6 Extension Header Control" Sub-TLV, using the
procedure specified in [RFC10052].
5.2. Procedure for IPv6 Extension Header Control
This document defines two measurement types: unidirectional and
bidirectional measurements. These types relate only to whether the
Session-Reflector adds new matching IPv6 extension headers for the
reverse path. The Session-Reflector still copies the received IPv6
extension headers into the corresponding "Reflected IPv6 Extension
Header Data" TLVs (see Section 4.1) in both measurement types.
The measurement type for a STAMP session is locally provisioned on
the STAMP Session-Sender.
In the bidirectional measurement type:
A Session-Reflector adds locally generated matching IPv6 extension
headers to the Session-Reflector test packets, subject to the
relevant IPv6 data-plane specifications, in the same order as the
IPv6 extension headers received in the Session-Sender test packets
for the reverse-direction measurement. These headers need not be
byte-for-byte copies of the received headers; their length and
content are local decisions at the Session-Reflector. Routing
extension headers specific to the Session-Sender are not requested to
be inserted into the reverse-direction Session-Reflector test packet.
Gandhi, et al. Expires 17 April 2027 [Page 13]
Internet-Draft STAMP for Reflecting IP Headers October 2026
The STAMP Session-Sender enables this type by adding the "IPv6
Extension Header Control" Sub-TLV (see Section 5.1) for the
"Reflected Test Packet Control" TLV (Type 12) [RFC10052] to the
Session-Sender test packets.
In the unidirectional measurement type:
A Session-Reflector omits adding new matching IPv6 extension headers
to the Session-Reflector test packets in response to the IPv6
extension headers received in the Session-Sender test packets, based
on its local policy. This does not preclude the Session-Reflector
from adding IPv6 extension headers independently.
This type is the default if the "IPv6 Extension Header Control" Sub-
TLV is absent from the Session-Sender test packet.
6. Reflecting Fixed Headers
6.1. Reflected Fixed Header Data TLV
This document defines the "Reflected Fixed Header Data" TLV for STAMP
(Type TBA2). A Session-Sender uses this TLV to request reflection of
an IPv4/IPv6 header received in its test packet. The TLV is carried
in Session-Sender and Session-Reflector test packets, and a STAMP-
Test packet MAY carry one or more TLVs of this type. It reflects
received IPv4/IPv6 headers only; it does not request or control the
addition of matching IPv4/IPv6 headers in the Session-Reflector test
packet. The format of the TLV is shown in Figure 5.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Received Fixed Header Data |
~ (Length - 4 octets) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Reflected Fixed Header Data TLV
The Reflected Fixed Header Data TLV fields are defined as follows:
* STAMP TLV Flags: The STAMP TLV Flags follow the procedures
specified in Section 4 of [RFC8972].
Gandhi, et al. Expires 17 April 2027 [Page 14]
Internet-Draft STAMP for Reflecting IP Headers October 2026
* Type: MUST be set to TBA2.
* Length: A two-octet field containing the total length, in octets,
of the IPv4/IPv6 header to be reflected. It includes the lengths
of the Requested Fixed Header Data field and the Received Fixed
Header Data field. For a 20-octet IPv4 header, the length is 20;
for a 40-octet IPv6 header, it is 40.
* Requested Fixed Header Data: A fixed 4-octet field containing the
first 4 octets of the target IPv4/IPv6 header to be reflected.
This field disambiguates which IPv4/IPv6 header in the received
Session-Sender test packet the Session-Reflector MUST copy into
the Reflected Fixed Header Data TLV when multiple headers of the
same length are present.
If all octets in this field are zero, the Session-Reflector MUST
match the first IPv4/IPv6 header in the Session-Sender test packet
with the matching length.
* Received Fixed Header Data: A variable-length field containing the
remaining (Length - 4) octets of the IPv4/IPv6 header after its
first 4 octets, copied from the received Session-Sender test
packet by the Session-Reflector.
In Session-Sender test packets, the data in this field MUST be
initialized to all zeros.
When a Session-Reflector recognizes the received "Reflected Fixed
Header Data" TLV but cannot use it to reflect a received IPv4/IPv6
header, it MUST return the "Reflected Fixed Header Data" TLV with the
Conformant Reflected Packet STAMP TLV flag set to 1, following the
procedure specified in [RFC10052]. This can occur, for example, if:
* The requested length does not match the length of the received
IPv4/IPv6 header.
* The Session-Reflector cannot access the received IPv4/IPv6 headers
from the data plane, or the data plane does not support the IPv4/
IPv6 header.
* No IPv4/IPv6 header matches the requested data and length, or the
IPv4/IPv6 header is invalid.
* More than one IPv4/IPv6 header of the requested length matches a
non-zero Requested Fixed Header Data field.
Gandhi, et al. Expires 17 April 2027 [Page 15]
Internet-Draft STAMP for Reflecting IP Headers October 2026
6.2. Procedure for Reflecting Fixed Headers
For each IPv4/IPv6 header in a Session-Sender test packet that the
Session-Sender requires the Session-Reflector to reflect, the
Session-Sender MUST add a corresponding "Reflected Fixed Header Data"
TLV to the test packet. The Session-Sender requests a copy of that
header in the corresponding TLV in the Session-Reflector test packet.
An example of a STAMP-Test packet carrying an IPv4/IPv6 header and
its corresponding "Reflected Fixed Header Data" TLV is shown in
Figure 6.
+---------------------------------------------------------------+
| IP Header |
+---------------------------------------------------------------+
| UDP Header |
+---------------------------------------------------------------+
| STAMP Packet [RFC8972] |
+---------------------------------------------------------------+
| Reflected Fixed Header Data TLV (TBA2) |
+---------------------------------------------------------------+
Figure 6: Example Session-Sender and Session-Reflector Test
Packet with "Reflected Fixed Header Data" TLV
When a Session-Sender test packet contains multiple IPv4/IPv6 headers
that the Session-Sender requires the Session-Reflector to reflect,
the corresponding "Reflected Fixed Header Data" TLVs MUST appear in
the same order as those headers in the test packet. When the
Session-Sender does not require the Session-Reflector to reflect an
IPv4/IPv6 header in the Session-Reflector test packet, the Session-
Sender MUST NOT add a corresponding "Reflected Fixed Header Data" TLV
to its test packet. In this case, the number of TLVs is less than
the number of IPv4/IPv6 headers in the packet.
The number of "Reflected Fixed Header Data" TLVs MUST NOT exceed the
number of IPv4/IPv6 headers in the Session-Sender test packet.
Gandhi, et al. Expires 17 April 2027 [Page 16]
Internet-Draft STAMP for Reflecting IP Headers October 2026
If multiple IPv4/IPv6 headers of the same length are present and the
Session-Sender requires the Session-Reflector to reflect only some of
them, the Session-Sender MUST populate the Requested Fixed Header
Data field (see Figure 5) with the first 4 octets of the header to be
reflected. This procedure assumes that these octets do not change
before the IPv4/IPv6 header reaches the Session-Reflector. A non-
zero value in this field MUST match exactly one IPv4/IPv6 header of
the requested length. An all-zero value continues to select the
first IPv4/IPv6 header of the matching length. If the requested
header cannot be uniquely selected under these rules, the Session-
Sender MUST NOT request selective reflection of that header.
When a Session-Reflector supports the "Reflected Fixed Header Data"
TLV and receives a Session-Sender test packet containing a valid
IPv4/IPv6 header and a corresponding TLV, the following rules apply:
1. If the Requested Fixed Header Data field in the received TLV is
non-zero and exactly one IPv4/IPv6 header of the requested length
matches the field, the Session-Reflector MUST select that header.
If a non-zero Requested Fixed Header Data field matches more than
one IPv4/IPv6 header of the requested length, the Session-
Reflector MUST return the TLV with the Conformant Reflected
Packet STAMP TLV flag set to 1, following the procedure specified
in [RFC10052], and MUST NOT copy data from any of the matching
headers.
If the Requested Fixed Header Data field is all zeros, the
Session-Reflector MUST select the first IPv4/IPv6 header with the
matching length and copy its first 4 octets into the Requested
Fixed Header Data field of the TLV.
If no IPv4/IPv6 header matches the requested data and length, the
Session-Reflector MUST return the "Reflected Fixed Header Data"
TLV with the Conformant Reflected Packet STAMP TLV flag set to 1,
following the procedure specified in [RFC10052].
2. The Session-Reflector MUST copy the portion of the IPv4/IPv6
header after its first 4 octets into the Received Fixed Header
Data field in the Session-Reflector test packet.
3. When the received Session-Sender test packet contains multiple
IPv4/IPv6 headers, the Session-Reflector MUST process them in
order, starting with the outermost header, and copy each header
into its corresponding "Reflected Fixed Header Data" TLV in the
Session-Reflector test packet, if such a TLV is present.
Gandhi, et al. Expires 17 April 2027 [Page 17]
Internet-Draft STAMP for Reflecting IP Headers October 2026
4. When a Session-Reflector receives a Session-Sender test packet
containing an IPv4/IPv6 header without a corresponding "Reflected
Fixed Header Data" TLV, it cannot copy that header into the
Session-Reflector test packet.
7. Additional Considerations
7.1. Reflecting Fixed Headers and IPv6 Extension Headers
STAMP-Test packets can be used to reflect both IPv4/IPv6 headers and
IPv6 extension headers by carrying the corresponding "Reflected Fixed
Header Data" and "Reflected IPv6 Extension Header Data" TLVs. An
example of a STAMP-Test packet carrying an IPv6 header and an IPv6
extension header along with their corresponding "Reflected Fixed
Header Data" TLV (see Section 6.1) and "Reflected IPv6 Extension
Header Data" TLV (see Section 4.1) is shown in Figure 7.
+---------------------------------------------------------------+
| IPv6 Header |
+---------------------------------------------------------------+
| IPv6 Extension Header [RFC8200] |
+---------------------------------------------------------------+
| UDP Header |
+---------------------------------------------------------------+
| STAMP Packet [RFC8972] |
+---------------------------------------------------------------+
| Reflected Fixed Header Data TLV (TBA2) |
+---------------------------------------------------------------+
| Reflected IPv6 Extension Header Data TLV (TBA1) |
+---------------------------------------------------------------+
Figure 7: 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 ordered sequence of IPv4/IPv6 headers and IPv6 extension
headers of the same or different types in the Session-Sender test
packets. This ordering requirement and its validation apply
independently of whether the corresponding headers are added to the
reverse Session-Reflector test packet. 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 "Reflected Fixed Header Data" TLVs and the "Reflected IPv6
Extension Header Data" TLVs with the Conformant Reflected Packet
STAMP TLV flag set to 1 using the procedure specified in [RFC10052],
but without copying any data in these STAMP TLVs.
Gandhi, et al. Expires 17 April 2027 [Page 18]
Internet-Draft STAMP for Reflecting IP Headers October 2026
7.2. MTU Considerations
Each Session-Sender and Session-Reflector MUST determine the
applicable path MTU for the direction in which it transmits STAMP-
Test packets. This information may be provisioned, collected through
management protocols, learned through a path-MTU-discovery mechanism
such as Path MTU Discovery for IPv6 [RFC8201], or distributed by a
control protocol. The mechanisms for obtaining this information are
outside the scope of this document.
The transmitting node MUST ensure that the complete STAMP-Test
packet, including all applicable IP, UDP, STAMP, "Reflected Fixed
Header Data", and "Reflected IPv6 Extension Header Data" TLV fields,
does not exceed the applicable path MTU. If the packet exceeds this
limit, the node MUST remove complete reflected header data TLVs one
at a time, starting with the last TLV in the packet, until the packet
fits within the MTU. When both types of reflected header data TLVs
are present, their ordering in Section 7.1 determines the removal
order. The remaining TLVs MUST retain their relative order. If
removing all reflected header data TLVs does not bring the packet
within the path MTU, the node MUST NOT transmit it.
The Session-Reflector MUST return requested TLVs that it can process
in the order received. The Session-Sender can identify the MTU-
driven removal by comparing the ordered TLV sequence it sent with the
sequence returned by the Session-Reflector; an intentionally
unrequested header has no corresponding TLV in the Session-Sender
packet. The Conformant Reflected Packet STAMP TLV flag does not
indicate MTU-driven removal.
8. Use Case of Reflecting IOAM Data Fields
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 specified in [RFC9197].
Examples of data recorded by IOAM Trace Options include per-hop
information, such as node ID, timestamp, queue depth, interface
identifier, and interface load. The information collected can be
used for monitoring 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
specified 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 specified in [RFC9197] for the
IPv6 data plane. The STAMP Session-Sender and Session-Reflector test
Gandhi, et al. Expires 17 April 2027 [Page 19]
Internet-Draft STAMP for Reflecting IP Headers October 2026
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 8.
+---------------------------------------------------------------+
| IPv6 Header |
+---------------------------------------------------------------+
| HBH IOAM IPv6 Options Header [RFC9486] |
+---------------------------------------------------------------+
| UDP Header |
+---------------------------------------------------------------+
| STAMP Packet [RFC8972] |
+---------------------------------------------------------------+
| Reflected IPv6 Extension Header Data TLV (TBA1) |
+---------------------------------------------------------------+
Figure 8: Example Session-Sender and Session-Reflector Test
Packet for IOAM with Reflected IPv6 Extension Header Data TLV
The Session-Sender node, midpoint nodes, and the Session-Reflector
node process the IOAM data fields, as specified in [RFC9197]. Note
that using the IOAM option type "Incremental Trace Option-Type" is
not supported by [RFC9486].
IOAM Direct Exporting [RFC9326] is applicable to 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 omits a corresponding "Reflected
IPv6 Extension Header Data" TLV in Session-Sender test packets for
the IOAM Direct Exporting option type.
9. UDP Checksum Handling
The UDP checksum handling specified in this section is applicable to
all STAMP sessions using IPv4/UDP and IPv6/UDP and is not limited to
STAMP sessions using the extensions specified in this document.
As specified in [RFC8085], the UDP checksum provides a statistical
guarantee that the payload was not corrupted in transit, truncated,
or padded.
The following limitations of STAMP timestamping necessitate
exceptions to permit the use of UDP zero checksum for IPv4 and IPv6:
* When the local processor cannot recompute the UDP checksum after
adding the timestamp in the STAMP-Test packet.
Gandhi, et al. Expires 17 April 2027 [Page 20]
Internet-Draft STAMP for Reflecting IP Headers October 2026
* When the local processor cannot add a checksum complement
[RFC7820] after adding the timestamp in the STAMP-Test packet.
9.1. IPv4 UDP Zero Checksum
Use of the UDP checksum with IPv4 MUST be the default configuration
for all implementations.
For IPv4, [RFC768] permits an option to disable UDP checksum
processing by setting the checksum value to zero.
For IPv4 STAMP-Test packets, the Session-Sender and Session-Reflector
MAY disable UDP checksum processing by setting the checksum value to
0 for the UDP ports specifically used in STAMP sessions, provided
that both endpoints are compatibly configured to do so and perform
additional checks on the source and destination IP addresses in the
STAMP-Test packets.
9.2. IPv6 UDP Zero Checksum
This document applies the exception in Section 8.1 of [RFC8200] to
IPv6 STAMP even though STAMP is not a tunnel protocol, because the
STAMP payload is the innermost protocol payload and has no inner
packet whose integrity would be protected by a UDP checksum. The UDP
zero checksum requirements of [RFC6936], therefore, apply directly to
the STAMP payload rather than to a tunnel encapsulation carrying an
inner packet.
For IPv6, any node that implements UDP zero checksum mode MUST follow
the requirements specified in [RFC6936] and [RFC8085] as described
below, with one deviation.
In this specification, the use of UDP zero checksum for IPv6 STAMP
deviates from requirement 5 in Section 5 of [RFC6936].
Requirement 5 of Section 5 of [RFC6936] cannot be satisfied because
STAMP is not a tunnel protocol and does not include an inner packet
with a CRC or other mechanism for checking packet integrity.
This deviation from the [RFC6936] requirement is limited to the IPv6
STAMP sessions that MUST operate under the constraints listed below.
IPv6 UDP zero checksum can be enabled only when the following
requirements, recommendations, and constraints are satisfied and the
residual risk due to STAMP-Test packet corruption is acceptable to
the network operator:
Gandhi, et al. Expires 17 April 2027 [Page 21]
Internet-Draft STAMP for Reflecting IP Headers October 2026
1. UDP zero checksum is enabled only for the specific UDP port
number or port range used by a STAMP session, at both the
Session-Sender and Session-Reflector.
This constraint corresponds to requirement 1 in Section 5 of
[RFC6936].
2. STAMP-Test packets in authenticated mode, as specified in
Section 3 of [RFC8972] and Section 4 of [RFC8972], are
RECOMMENDED in networks where test packet payload integrity is
required. When optional TLVs are present, the HMAC TLV is used
as specified in Section 4.8 of [RFC8972] for test packet payload
integrity.
This recommendation corresponds to requirement 2 in Section 5 of
[RFC6936].
3. Requirement 3 in Section 5 of [RFC6936] does not apply to STAMP
because test packets are not tunnel payloads and do not rely on
an inner packet integrity check.
4. When the IPv6 UDP checksum is zero, the UDP layer does not detect
corruption of the STAMP-Test payload. Implementations MUST
perform the specified STAMP packet and session validation,
including checks of packet format, session identification,
sequence number field, timestamp fields (as specified in
Section 11), and TLV structure and length, and MUST discard
packets that fail those checks. These checks detect some invalid
packets but do not provide general integrity protection:
corruption that leaves a packet valid, including changes to
measurement fields or TLV values, may go undetected and affect
the measurement. Thus, a session using a zero UDP checksum
without authenticated STAMP has no general assurance that its
measurement information is intact.
This recommendation corresponds to requirement 4 in Section 5 of
[RFC6936].
5. Requirements 6 and 7 in Section 5 of [RFC6936] are not applicable
to STAMP as they are related to keep alive messages.
6. Middleboxes within the controlled domain that process IPv6 STAMP-
Test packets MUST comply with requirements 8 through 10 of
Section 5 of [RFC6936].
Additional specific guidance from Section 3.4.1 of [RFC8085] that
applies to IPv6 STAMP-Test packets that use UDP zero checksum is
summarized below:
Gandhi, et al. Expires 17 April 2027 [Page 22]
Internet-Draft STAMP for Reflecting IP Headers October 2026
1. Use of the UDP checksum with IPv6 MUST be the default
configuration for all implementations.
This guidance corresponds to the first requirement in
Section 3.4.1 of [RFC8085].
2. The receiving endpoint MUST verify a test packet with a non-zero
UDP checksum and MUST discard it if checksum verification fails;
it MUST NOT treat the test packet as a valid measurement result.
This guidance corresponds to the second requirement in
Section 3.4.1 of [RFC8085] and also applies to Section 4 of
[RFC6936] and Section 5 of [RFC6936].
3. The receiving endpoint MUST only permit the use of UDP zero
checksum for IPv6 on a UDP destination port number that is
specifically enabled for STAMP and MUST check that the source and
destination IPv6 addresses are valid and discard any test packet
for which this check fails.
This guidance corresponds to the third requirement in
Section 3.4.1 of [RFC8085].
4. STAMP sessions are restricted to networks under a single
administrative domain (see Section 11), where the operator is
willing to take the risk of STAMP-Test packet corruption
affecting measurements when using UDP zero checksum.
This guidance corresponds to the fourth requirement in
Section 3.4.1 of [RFC8085].
5. STAMP sessions that choose to use a UDP zero checksum MUST NOT
make assumptions regarding the correctness of received test
packets and MUST behave correctly when a UDP datagram is
corrupted.
This guidance corresponds to the fifth requirement in
Section 3.4.1 of [RFC8085].
10. Operational Considerations
The operational considerations specified in [RFC8762] and [RFC10052]
apply to the procedure and extensions specified in this document.
In addition, the Management and Deployment Considerations specified
in [RFC9197] also apply when using the IOAM data fields specified in
that document.
Gandhi, et al. Expires 17 April 2027 [Page 23]
Internet-Draft STAMP for Reflecting IP Headers October 2026
An implementation MUST provide the ability to provision the
measurement type as unidirectional or bidirectional as specified in
Section 5.
Additionally, an operator MAY provision a local policy on a Session-
Reflector not to copy and reflect the received IPv6 extension headers
and IPv4/IPv6 headers in the Session-Reflector test packets to avoid
exposing the collected network information to Session-Senders.
10.1. Verifying Received IPv6 Extension Headers
The procedure in Section 4.2 requires the first 8 octets of each IPv6
extension header to remain unchanged in transit when multiple headers
of the same length are present and only some are to be copied into
STAMP TLVs. Similarly, the procedure in Section 6.2 requires the
first 4 octets of each IPv4/IPv6 header to remain unchanged in
transit when multiple headers of the same length are present and only
some are to be copied into STAMP TLVs.
Additionally, the procedure specified requires the data plane on
ingress and egress nodes to provide the received IPv6 extension
headers to Session-Senders and Session-Reflectors as specified in
Section 4.3.
For the reasons mentioned above, an operator should verify that the
IPv6 extension headers are received correctly at Session-Reflectors
and Session-Senders. An operator may use, for example, mechanisms
defined in [RFC9740] to verify the received IPv6 extension headers.
10.2. STAMP Session State Notification
The STAMP session state change notifications specified in this
section are applicable to all STAMP sessions and are not limited to
STAMP sessions using the extensions specified in this document.
Monitoring the STAMP session state allows the Session-Sender to
determine whether the STAMP test is idle, active, or failed and
generate state-change notifications as follows:
* The STAMP session state is reported as idle when the Session-
Sender is not transmitting test packets.
* The STAMP session state is initially reported as active when the
Session-Sender is transmitting test packets and at least one
Session-Reflector test packet is received.
Gandhi, et al. Expires 17 April 2027 [Page 24]
Internet-Draft STAMP for Reflecting IP Headers October 2026
* The STAMP session state is reported as failed when N consecutive
Session-Reflector test packets are not received after the STAMP
session state is reported as active, where N (the consecutive
packet loss count) is a locally provisioned value.
* The STAMP session state transitions from failed back to active
when the Session-Sender is transmitting test packets and at least
one Session-Reflector test packet is again received.
Because STAMP-Test packets are transmitted over the path being
measured, a connectivity failure of that path typically manifests as
the continuous packet loss specified above, resulting in the STAMP
session state being reported as failed.
10.3. Rate Limiting
The rate limiting considerations specified in this section are
applicable to all STAMP sessions and are not limited to STAMP
sessions using the extensions specified in this document.
On both Session-Sender and Session-Reflector nodes, each STAMP-Test
packet processed by the control plane consumes CPU and memory
resources and is therefore subject to rate limiting as a protection
against denial-of-service attacks. Such rate limiting on the punt
path is indistinguishable from the actual loss in the network and can
therefore be reported as packet loss.
It is useful for an operator to know that rate limiting was applied
to STAMP-Test packets (for example, based on the UDP ports used for
STAMP), so that the alerting system can correlate STAMP packets being
rate-limited with failure notifications.
This throttling or policing of incoming STAMP-Test packets MUST NOT
be more stringent than the transmit rate of the STAMP-Test packets to
prevent invalid measurement results.
11. Security Considerations
The security considerations specified in [RFC8762], [RFC8972],
[RFC8200], and [RFC10052] apply to the procedure and extensions
specified in this document. In addition, the security considerations
specified in [RFC9197] and [RFC9486] also apply when using IPv6
options for IOAM data fields.
Gandhi, et al. Expires 17 April 2027 [Page 25]
Internet-Draft STAMP for Reflecting IP Headers October 2026
The procedures specified 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 paths in the forward and
reverse directions used to transmit STAMP-Test packets so that
collected network information is not exposed to an undesired node.
If desired, attacks can be mitigated by performing basic validation
checks of the timestamp fields in received reply test packets at the
Session-Sender. For example, verifying that T2 is later than T1 in
the STAMP Reference Topology shown in Figure 1 requires clock
synchronization between the Session-Sender and Session-Reflector. In
contrast, checking that T3 is greater than or equal to T2, or that T4
is later than T1, compares timestamps generated at the same node and
does not require clock synchronization. The minimal state associated
with this protocol 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 MUST NOT assign STAMP Session-IDs
[RFC8972] in a predictable manner to protect against off-path
attacks. To avoid predictability, implementations can leverage a
Cryptographically Secure Pseudorandom Number Generator [NIST-CSPRNG].
12. 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 IPv4/IPv6 header of the
reflected STAMP-Test packet.
Gandhi, et al. Expires 17 April 2027 [Page 26]
Internet-Draft STAMP for Reflecting IP Headers October 2026
4. Support for multiple IPv6 extension headers.
5. Reflection of the fixed IPv4/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
Tools for testing the reflected IPv6 extension header TLV data are
also available:
https://github.com/cerfcast/teaparty/tree/main/testing_data#testing-
reflected-ipv6-extension-header-data
Contact:
William Hawkins
University of Cincinnati
Email: hawkinsw@obs.cr
13. IANA Considerations
IANA is requested to allocate the following TLVs from the IETF Review
range of the "STAMP TLV Types" registry under the Simple Two-Way
Active Measurement Protocol (STAMP) TLV Types registry group:
+=======+======================================+===============+
| Value | Description | Reference |
+=======+======================================+===============+
| TBA1 | Reflected IPv6 Extension Header Data | This document |
+-------+--------------------------------------+---------------+
| TBA2 | Reflected Fixed Header Data | This document |
+-------+--------------------------------------+---------------+
Table 2: STAMP TLV Types
IANA is requested to allocate the following sub-TLV from the IETF
review range of the "STAMP Sub-TLV Types" registry under the Simple
Two-way Active Measurement Protocol (STAMP) TLV Types registry group:
Gandhi, et al. Expires 17 April 2027 [Page 27]
Internet-Draft STAMP for Reflecting IP Headers October 2026
+=======+================+================+===========+
| Value | Description | TLV Used | Reference |
+=======+================+================+===========+
| TBA3 | IPv6 Extension | Reflected Test | This |
| | Header Control | Packet Control | document |
+-------+----------------+----------------+-----------+
Table 3: Sub-TLV Type for Reflected Test Packet
Control TLV
Note to the RFC Editor: Please replace all occurrences of TBA1, TBA2,
and TBA3 with the values assigned by IANA.
14. References
14.1. Normative References
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.
[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>.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization", BCP 156, RFC 6056,
DOI 10.17487/RFC6056, January 2011,
<https://www.rfc-editor.org/info/rfc6056>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011,
<https://www.rfc-editor.org/info/rfc6335>.
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement
for the Use of IPv6 UDP Datagrams with Zero Checksums",
RFC 6936, DOI 10.17487/RFC6936, April 2013,
<https://www.rfc-editor.org/info/rfc6936>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
Gandhi, et al. Expires 17 April 2027 [Page 28]
Internet-Draft STAMP for Reflecting IP Headers October 2026
[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>.
[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>.
[RFC10052] Mirsky, G., Ruffini, E., Nydell, H., Foote, R., and W.
Hawkins, "Performance Measurement with Asymmetrical
Traffic Using the Simple Two-Way Active Measurement
Protocol (STAMP)", RFC 10052, DOI 10.17487/RFC10052,
September 2026,
<https://www.rfc-editor.org/info/rfc10052>.
[IANA-STAMP]
IANA, "Simple Two-way Active Measurement Protocol (STAMP)
TLV Types",
<https://www.iana.org/assignments/stamp-tlv-types>.
14.2. Informative References
[RFC7820] Mizrahi, T., "UDP Checksum Complement in the One-Way
Active Measurement Protocol (OWAMP) and Two-Way Active
Measurement Protocol (TWAMP)", RFC 7820,
DOI 10.17487/RFC7820, March 2016,
<https://www.rfc-editor.org/info/rfc7820>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>.
Gandhi, et al. Expires 17 April 2027 [Page 29]
Internet-Draft STAMP for Reflecting IP Headers October 2026
[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>.
[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>.
[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>.
[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>.
[RFC9740] Boucadair, M. and B. Claise, "New IPFIX Information
Elements for TCP Options and IPv6 Extension Headers",
RFC 9740, DOI 10.17487/RFC9740, March 2025,
<https://www.rfc-editor.org/info/rfc9740>.
[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-03, 28 August 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-on-
path-active-measurements-03>.
[I-D.ietf-mpls-stamp-pw]
Gandhi, R., Brissette, P., Leyton, E., and X. Min,
"Encapsulation of Simple Two-Way Active Measurement
Protocol for LSPs and Pseudowires in MPLS Networks", Work
in Progress, Internet-Draft, draft-ietf-mpls-stamp-pw-21,
10 September 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-mpls-stamp-pw-21>.
[NIST-CSPRNG]
NIST Special Publication 800-90A, "Recommendation for
Random Number Generation Using Deterministic Random Bit
Generators", January 2012.
Gandhi, et al. Expires 17 April 2027 [Page 30]
Internet-Draft STAMP for Reflecting IP Headers October 2026
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 specified in this document in Teaparty. The authors
would also like to thank Vidhi Goel for the TSVART telechat review of
[I-D.ietf-mpls-stamp-pw]; that review led to the addition of
specifications for the IP/UDP header, UDP Checksum Handling, STAMP
Session State, and Rate Limiting in this document. The authors also
thank Xiao Min for the PerfMetrdir review, Marcus Ihlar for the
Shepherd's review, Mohamed Boucadair for the OPS Area AD review, Marc
Blanchet for the ArtArt review, Wesley Eddy for the TSVART review,
and Shwetha Bhandari for the Intdir review. These reviews helped
improve this document.
Authors' Addresses
Rakesh Gandhi (editor)
Cisco Systems, Inc.
Canada
Email: rgandhi@cisco.com
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 17 April 2027 [Page 31]