Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet IP Headers

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, STAMP-Test packet, symmetric and symmetrical.¶

This document uses terms defined in [RFC8972], specifically STAMP TLV Flags and Sub-TLVs.¶

The Conformant Reflected Packet STAMP TLV flag defined in [RFC10052] is re-used for communicating the error conditions for the STAMP TLVs defined in this document. The error conditions specified for the STAMP TLVs defined in [RFC10052] are not applicable to the extensions defined in this document.¶

2.3. Abbreviations

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

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, e.g., using PTPv2 [IEEE1588] or NTPv4 [RFC5905].¶

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 UDP port numbers as specified in Section 4.1 of [RFC8762].¶

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 NOT equal the local Session-Reflector's reflector port number.¶

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

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)                       ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

  The "Reflected IPv6 Extension Header Data" TLV applies to IPv6 extension headers that begin with a Next Header field and a length field, such as the Hop-by-Hop Options, Routing, and Destination Options headers.¶

• 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 identifies which IPv6 extension header in the received Session-Sender test packet is copied into the "Reflected IPv6 Extension Header Data" TLV when multiple IPv6 extension headers of the same length are present; the selection rules are in Section 4.2.¶

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

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

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

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

- The Session-Sender MUST set to zero each octet in the Requested IPv6 Extension Header Data field containing any part of a field that can change in transit (a mutable field), for example, the Segments Left octet of a Segment Routing Header [RFC8754]. Because zero is a wildcard, the Session-Sender MUST NOT rely on matching a zero-valued octet. For a non-zero value in the Requested IPv6 Extension Header Data field, the Session-Sender MUST request selective reflection only if exactly one IPv6 extension header matches.¶

- The Session-Reflector compares only the non-zero octets of the field. The Session-Reflector processes the "Reflected IPv6 Extension Header Data" TLVs in order and matches each TLV to the first IPv6 extension header, not already matched by an earlier TLV, that has the requested length and whose octets equal the non-zero octets of the field; an all-zero field therefore matches the next unmatched header of the requested length.¶

Before requesting reflection of IPv6 extension header data, the Session-Sender MUST be configured to request the applicable data from the Session-Reflector. The Session-Reflector MUST apply the local reflection policy specified in Section 9 before copying header data. When reflection is not permitted by policy, the Session-Reflector MUST NOT copy the requested IPv6 extension header data and MUST return the corresponding TLV with the Conformant Reflected Packet STAMP TLV flag set to 1, following the procedure specified in [RFC10052].¶

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 to requests permitted by the local reflection policy:¶

1. If the Requested IPv6 Extension Header Data field is not all zeros, the Session-Reflector MUST compare it with the first 8 octets of each IPv6 extension header of the requested length. A zero octet in the requested field MUST match any value; each non-zero octet MUST match the corresponding header octet exactly. The Session-Reflector MUST select the header if exactly one header matches.¶

   If no header or more than one header matches, 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 header data.¶

   If the Requested IPv6 Extension Header Data field is all zeros, the Session-Reflector MUST select the first IPv6 extension header of the requested length and copy its first 8 octets, beginning with its Next Header field, into that field.¶

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 topmost 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 related to STAMP 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

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, for the reverse direction, 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.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]. This Sub-TLV is used to force the Session-Reflector to generate and add matching IPv6 extension headers in the reply test packets. The format of the "IPv6 Extension Header Control" Sub-TLV is shown in Figure 4.¶

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

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. Otherwise, if the length is non-zero, the Session-Reflector MUST return the Sub-TLV with the Malformed flag set to 1 in the Sub-TLV Flags field as specified in [RFC8972].¶

When the "Reflected Test Packet Control" TLV is included only to carry the "IPv6 Extension Header Control" Sub-TLV, the Session-Sender MUST set the Number of the Reflected Packets field to 1, the Interval Between the Reflected Packets field to 0, and the Length of the Reflected Packet field to 0, so that a single Session-Reflector test packet is returned with the length given by Section 3 of [RFC10052]. The bidirectional measurement type requires that support for the "Reflected Test Packet Control" TLV is enabled on the Session-Reflector (Section 5 of [RFC10052]).¶

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 (headers of the same type carrying the same option types, for example, the same IOAM Option-Type and Namespace-ID) in the Session-Reflector test packets, subject to the relevant IPv6 data-plane specifications, in the same order in which the corresponding IPv6 extension headers 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 MUST omit adding locally generated matching IPv6 extension headers in the Session-Reflector test packet corresponding to the received IPv6 extension headers. 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.¶

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 for the IPv6 extension headers carried in a two-way STAMP session: unidirectional (forward direction only) and bidirectional (forward and reverse directions). These types relate only to whether the Session-Reflector adds locally generated new matching IPv6 extension headers in the Session-Reflector test packets 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.¶

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 MUST omit 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. 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.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)                       ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

• 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. As an example: for a 20-octet IPv4 header without any IPv4 option, the length is 20; and for a 40-octet IPv6 header without any IPv6 options, 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 identifies which IPv4/IPv6 header in the received Session-Sender test packet is copied into the "Reflected Fixed Header Data" TLV when multiple headers of the same length are present; the selection rules are in Section 6.2.¶

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

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)                        |
 +---------------------------------------------------------------+

When a Session-Sender test packet contains multiple IPv4/IPv6 headers (for example, IP in IP tunneling specified in [RFC1853]) 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.¶

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

- The Session-Sender MUST set to zero each octet in the Requested Fixed Header Data field containing any part of a field that can change in transit (a mutable field), for example, the 8-bit Type of Service (containing DSCP and ECN values) field in an IPv4 header [RFC791], or the 8-bit Traffic Class (containing DSCP and ECN values) field in an IPv6 header [RFC8200]. Because zero is a wildcard, the Session-Sender MUST NOT rely on matching a zero-valued octet. For a non-zero value in the Requested Fixed Header Data field, the Session-Sender MUST request selective reflection only if exactly one IPv4/IPv6 header of the requested length matches.¶

- The Session-Reflector compares only the non-zero octets of the field. It processes the "Reflected Fixed Header Data" TLVs in order and matches each TLV to the first IPv4/IPv6 header, not already matched by an earlier TLV, that has the requested length and whose octets equal the non-zero octets of the field; an all-zero field therefore matches the next unmatched header of the requested length.¶

Before requesting reflection of IPv4/IPv6 header data, the Session-Sender MUST be configured to request the applicable data from the Session-Reflector. The Session-Reflector MUST apply the local reflection policy specified in Section 9 before copying header data. When reflection is not permitted by policy, the Session-Reflector MUST NOT copy the requested IPv4/IPv6 header data and MUST return the corresponding TLV with the Conformant Reflected Packet STAMP TLV flag set to 1, following the procedure specified in [RFC10052].¶

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 to requests permitted by the local reflection policy:¶

1. If the Requested Fixed Header Data field is not all zeros, the Session-Reflector MUST compare it with the first 4 octets of each IPv4/IPv6 header of the requested length. A zero octet in the requested field MUST match any value; each non-zero octet MUST match the corresponding header octet exactly. The Session-Reflector MUST select the header if exactly one header matches.¶

   If no header or more than one header matches, 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 header data.¶

   If the Requested Fixed Header Data field is all zeros, the Session-Reflector MUST select the first IPv4/IPv6 header of the requested length and copy its first 4 octets into that field.¶

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

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

The "Reflected Fixed Header Data" TLVs MUST be added before adding the "Reflected IPv6 Extension Header Data" TLVs. Within each type, the TLVs follow the order of the corresponding headers in the Session-Sender test packet. 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.¶

7.2. MTU Considerations

Each Session-Sender and Session-Reflector needs to know 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, skipping the HMAC TLV (Type 8) [RFC8972] if present, one at a time, starting with the last TLV in the packet, until the packet fits within the path MTU. If an HMAC TLV was present and if any preceding TLV was removed, the HMAC digest MUST be updated as specified in Section 4.8 of [RFC8972]. 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.¶

9.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 excluding the mutable fields as identified by value 0 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 excluding the mutable fields as identified by value 0 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 to provide the received IPv6 extension headers to Session-Senders and Session-Reflectors hosted in the control plane as specified in Section 4.3.¶

For the reasons mentioned above, an operator should verify that the IPv6 extension headers are received correctly at both the Session-Reflector and the Session-Sender. An operator may use, for example, mechanisms defined in [RFC9740] to verify the received IPv6 extension headers.¶

9.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 MAY 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 reported as failed after the Session-Sender starts transmitting test packets but N consecutive Session-Reflector test packets are not received.¶
• 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.¶
• 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.¶

9.3. Rate Limiting

These rate limiting considerations apply to all STAMP sessions, including those not using the extensions specified in this document.¶

UDP provides no inherent congestion control. Implementations SHOULD provide configurable transmission rate and burst limits (for example, based on the UDP port numbers used for STAMP), to be able to protect other traffic sharing the path. Implementations SHOULD pace packet transmissions to avoid excessive bursts, consistent with Section 3.1.6 of [RFC8085].¶

Before provisioning a session, operators must account for the aggregate STAMP load and assess its impact on existing services, as required by Section 7 of [RFC8762]. Operators must account for packet sizes, including encapsulation overhead, extension headers, and TLVs to assess traffic along the path. Operators must configure transmission rate and burst limits consistent with the available STAMP capacity in each direction.¶

When relying on provisioned or reserved capacity for congestion control, operators must keep aggregate STAMP traffic within the allocated capacity. Operators must account for concurrent sessions, other traffic sharing the allocation, path and capacity changes, during STAMP session provisioning.¶

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 actual loss in the network and can therefore be reported as packet loss.¶

Operators must configure receive packet processing and reflection limits to accommodate aggregate STAMP traffic, including expected bursts, to avoid measurement artifacts. This configuration for 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. Implementations MAY discard test packets or suppress responses during overload to enforce resource-protection limits. Because this can appear as network loss, implementations SHOULD expose counters or notifications to distinguish local limiting from path loss and correlate limiting events with session failure notifications.¶