]> Cisco Systems, Inc.

Canada rgandhi@cisco.com

Huawei

China zhoutianran@huawei.com

China Mobile

China lizhenqiang@chinamobile.com

University of Cincinnati

USA hawkinsw@obs.cr

IPPM Working Group 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.

The Simple Two-Way Active Measurement Protocol (STAMP) provides capabilities for the measurement of various performance metrics in IP networks without the use of a control channel to pre-signal session parameters. 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. 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 . 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 . The HBH options processing procedures are further specified in . specifies IPv6 option types for HBH and destination options headers to carry the IOAM data fields defined in for an 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 using optional STAMP extensions defined in 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.

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 when, and only when, they appear in all capitals, as shown here.

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 STAMP: Simple Two-Way Active Measurement Protocol TLV: Type-Length-Value

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.

STAMP Reference Topology | | | S1 |=================| M1 |===================| R1 | | |<- - - - - - - - | | - - - - - - - - - | | +-------+ +-------+ Reply Test Packet +-------+ \ / T4 T3 STAMP Session-Sender STAMP Session-Reflector ]]>

defines optional extensions for STAMP. The optional extensions are added to the base STAMP test packet defined in in the form of TLVs. As specified in , 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 , 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 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, including one-way and two-way measurement types.

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 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.

Example Session-Sender and Session-Reflector Test Packet with Reflected IPv6 Extension Header Data TLVs

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 those of the IPv6 extension headers 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. 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 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. 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. When the Session-Reflector receives a STAMP test packet with an IPv6 extension header but without a "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. If the Session-Reflector receives Session-Sender test packets with non-zero values in the first 4 bytes of the "Requested IPv6 Extension Header Data" field (shown in Figure 6) of the "Reflected IPv6 Extension Header Data" TLV, it MUST match the values in the corresponding IPv6 extension header (starting from the Next Header field of the IPv6 extension header) before copying data into the STAMP TLV. This mechanism is employed in cases of 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 check is also used when not all IPv6 extension headers need to be reflected in STAMP TLVs and hence there are no corresponding "Reflected IPv6 Extension Header Data" TLVs added for them. 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. 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 , Performance and Diagnostic Metrics IPv6 options header defined in , Maximum Path MTU IPv6 options header defined in , Alternate Marking Method IPv6 options header defined in , Routing Header for IPv6 including Segment Routing Header defined in , and any new IPv6 extension header that is defined in the future.

This document defines two measurement types: one-way and two-way measurements. 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 of the new IPv6 extension headers added in the Session-Reflector test packets is a local decision on the Session-Reflector. The STAMP Session-Sender enables this by adding "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. The measurement type for a STAMP session is locally provisioned on the STAMP Session-Sender.

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.

Example Session-Sender and Session-Reflector Test Packet with "Reflected Fixed Header Data" TLV

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 those of the IP headers 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. 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 Session-Reflector that supports this TLV MUST copy the IP header into the "Reflected Fixed Header Data" TLV in the Session-Reflector test packet. 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. When the Session-Reflector receives a STAMP test packet with an IP header but without a "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. If the Session-Reflector receives Session-Sender test packets with non-zero values in the first 4 bytes of the "Requested Fixed Header Data" field (shown in Figure 7) of the "Reflected Fixed Header Data" TLV, it MUST match the values in the corresponding IP header before copying data into the STAMP TLV. This mechanism is employed in cases of 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 check is also used when not all IP headers need to be reflected in STAMP TLVs and hence there are no corresponding "Reflected Fixed Header Data" TLVs added for them. 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.

STAMP test packets can be used to reflect both IPv6 extension headers and IP headers by carrying the corresponding "Reflected IPv6 Extension Header Data" and "Reflected Fixed Header Data" TLVs as shown in Figure 4.

Example Session-Sender and Session-Reflector Test Packet with Reflected IPv6 Extension Header Data and Fixed Header Data TLVs

The "Reflected Fixed Header Data" TLV MUST be added before adding the "Reflected IPv6 Extension Header Data" TLVs to maintain the same order as the IP headers and extension headers in the STAMP test packets. If not, the Session-Reflector MUST return both STAMP TLVs with the C flag (Conformance) set to 1 in the STAMP TLV Flags using the procedure defined in .

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 . 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. defines types for HBH and destination options headers and is used to carry the IOAM option types defined in 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 . Note that using the IOAM option type "Incremental Trace Option-Type" is not supported by .

Example Session-Sender and Session-Reflector Test Packet for IOAM with Reflected IPv6 Extension Header Data TLV

IOAM Direct Exporting (DEX) is applicable with STAMP test packets for on-path telemetry use cases as described in . In this case, the Session-Reflector is not required to reflect 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.

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.

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 . Length: A two-octet field equal to the length of the Data in octets. If, due to some error, such as a mismatch in the length between the IPv6 extension header and the "Reflected IPv6 Extension Header Data" TLV, the Session-Reflector does not use the received "Reflected IPv6 Extension Header Data" TLV for reflecting the IPv6 extension header, the Session-Reflector MUST return the STAMP TLV with the U flag (Unrecognized TLV) set to 1 in the STAMP TLV Flags using the procedure defined in .

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.

Reflected Fixed Header Data TLV

The STAMP TLV fields are defined as follows: Type: STAMP TLV Type (value TBA2). STAMP TLV Flags: The STAMP TLV Flags follow the procedures described in . Length: A two-octet field equal to the length of the Data in octets. For an IPv4 header, the length is set to 20, and for an IPv6 header, the length is set to 40. If, due to some error, such as a mismatch in the length between the IP header and the "Reflected Fixed Header Data" TLV, the Session-Reflector does not use the received "Reflected Fixed Header Data" TLV for reflecting the IP header, the Session-Reflector MUST return the STAMP TLV with the U flag (Unrecognized TLV) set to 1 in the STAMP TLV Flags using the procedure defined in .

This document defines the "IPv6 Extension Header Control" Sub-TLV (Type TBA3) for the "Reflected Test Packet Control" TLV (Type 12) introduced in . The format of "IPv6 Extension Header Control" Sub-TLV is shown in 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 . Sub-TLV Length: A two-octet field equal to the length of the Data in octets. It is set to 0. When a Session-Sender test packet is received with the "IPv6 Extension Header Control" Sub-TLV, 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). In the absence of this 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. 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. If for any reason, the Session-Reflector cannot add a new matching IPv6 extension header in the Session-Reflector test packet, for example, if the Session-Reflector does not support the IPv6 extension header, the Session-Reflector MUST return the STAMP TLV with the C flag (Conformance) set to 1 in the Sub-TLV Flags of the Sub-TLV using the procedure defined in . STAMP test packets MUST NOT carry more than one "IPv6 Extension Header Control" Sub-TLV in a "Reflected Test Packet Control" TLV. If a Session-Sender test packet contains more than one "IPv6 Extension Header Control" Sub-TLV, the Session-Reflector MUST return the STAMP TLV with the U flag (Unrecognized TLV) set to 1 in the STAMP TLV Flags using the procedure defined in .

The operational considerations specified in and apply to the procedure and extensions defined in this document. In addition, the Management and Deployment Considerations specified in 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.

The security considerations specified in , , , and apply to the procedure and extensions defined in this document. In addition, the security considerations specified in and 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 in a predictable manner. In order to avoid predictability, implementations can leverage a Cryptographically Secure Pseudorandom Number Generator .

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 Email: hawkinsw@obs.cr

IANA has created the "STAMP TLV Types" registry for . 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. STAMP TLV Types

Value	Description	Reference
TBA1	Reflected IPv6 Extension Header Data	This document
TBA2	Reflected Fixed Header Data	This document

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 , from the "STAMP Sub-TLV Types" registry. Sub-TLV Type for Reflected Test Packet Control TLV

Value	Description	TLV Used	Reference
TBA3	IPv6 Extension Header Control	Reflected Test Packet Control	This document

&RFC2119; &RFC8174; &RFC8200; &RFC8762; &RFC8972; &RFC9673; &I-D.ietf-ippm-asymmetrical-pkts; &RFC8250; &RFC8754; &RFC9197; &RFC9268; &RFC9326; &RFC9343; &RFC9486; &I-D.ietf-ippm-on-path-active-measurements; NIST Special Publication 800-90A

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.