]> Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet IP Headers 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 IPv4/IPv6 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 (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 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 . The HBH Options processing procedures are further specified in . specifies IPv6 option types for HBH and Destination Options headers to carry the IOAM Option-Types specified in and 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. 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 the requirements for IPv6 STAMP using UDP zero checksum, which deviates from the integrity requirement in . Refer to for more details.
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.
This document uses terms defined in , specifically Session-Sender, Session-Reflector, Session-Test packet, and symmetric. This document uses terms defined in , specifically STAMP TLV Flags and Sub-TLVs.
Abbreviation Meaning Reference 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 TTL Time to Live
In the "STAMP Reference Topology" shown in , 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 ) 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.
STAMP Reference Topology | | | 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 using either PTPv2 or NTPv4.
As specified in , 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 , 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 .
The IPv4/IPv6 and UDP headers specified in this section is applicable to all STAMP sessions using an IP/UDP header and is not limited to STAMP 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 port, as specified in , or using a port number from the User Ports or Dynamic Ports ranges as defined in . The source port number is chosen as follows:
  • The source UDP port number SHOULD be chosen using a randomized allocation method as specified in to provide protection against off-path attacks, as recommended in .
  • The source UDP port number SHOULD be chosen from the Dynamic Ports range (49152-65535) 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.
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 TTL or IPv6 Hop Limit value of 255.
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 .
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 .
  • 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.
  • 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 . 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.
    • For each IPv6 extension 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 IPv6 Extension Header Data" TLV (see ) 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 .
    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 ) is less than the number of IPv6 extension headers (N in ). 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 ) 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. 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:
  • If the Requested IPv6 Extension Header Data field in the received TLV is non-zero, the Session-Reflector MUST select an IPv6 extension header whose length matches the requested length and whose first 8 octets, beginning with its Next Header field, match the Requested IPv6 Extension Header Data. 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 .
  • 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.
  • 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.
  • 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.
    • The Session-Sender and Session-Reflector MUST ensure that the complete STAMP-Test packet, including all applicable IP, UDP, STAMP, and "Reflected IPv6 Extension Header Data" TLV fields, does not exceed the applicable path MTU. If necessary, one or more "Reflected IPv6 Extension Header Data" TLVs, starting from the end of the test packet, MUST be removed to meet this limit. 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.
    When the received STAMP-Test packets are processed by the data plane on the egress node that has 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 ). Similarly, when the received STAMP-Test packets are processed by the data plane in the reverse direction on an ingress node that has 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 ).
    This document defines the "IPv6 Extension Header Control" Sub-TLV (Type TBA3) for the "Reflected Test Packet Control" TLV (Type 12) . The format of the "IPv6 Extension Header Control" Sub-TLV is shown in .
    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 . Flag values are taken from the "STAMP TLV Flags" registry .
    • 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:
  • The Session-Reflector MUST add locally generated matching IPv6 extension headers, subject to the relevant IPv6 data-plane specifications, in the same order as the IPv6 extension headers of the same or different types received in the 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.
  • 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.
  • 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.
  • 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) 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 . 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) . 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 .
    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 ) 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 ) for the "Reflected Test Packet Control" TLV (Type 12) 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.
    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 .
    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 .
  • 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. 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 . 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.
    • 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 .
    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. 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 ) 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. 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:
  • If the Requested Fixed Header Data field in the received TLV is non-zero, the Session-Reflector MUST select an IPv4/IPv6 header whose length matches the requested length and whose first 4 octets match the Requested Fixed Header Data. 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 .
  • 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.
  • 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.
  • 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.
    • The Session-Sender and Session-Reflector MUST ensure that the complete STAMP-Test packet, including all applicable IP, UDP, STAMP, and "Reflected Fixed Header Data" TLV fields, does not exceed the applicable path MTU. If necessary, one or more "Reflected Fixed Header Data" TLVs, starting from the end of the test packet, MUST be removed to meet this limit.
    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 ) and "Reflected IPv6 Extension Header Data" TLV (see ) is shown in .
    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 , but without copying any data in these STAMP TLVs.
    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 . 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. defines types for HBH and Destination Options headers and is used to carry the IOAM option types specified 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 .
    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 . Note that using the IOAM option type "Incremental Trace Option-Type" is not supported by . IOAM Direct Exporting is applicable to STAMP-Test packets for on-path telemetry use cases as described in . 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.
    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 , 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.
    • When the local processor cannot add a checksum complement after adding the timestamp in the STAMP-Test packet.
    Use of the UDP checksum with IPv4 MUST be the default configuration for all implementations. For IPv4, 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 can use this exception for the UDP ports specifically used in STAMP sessions to set the UDP checksum value to 0 with additional checks on the source IP address and destination IP address in the STAMP-Test packets.
    This document applies the exception in 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 , 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 and as described below, with one deviation. In this specification, the use of UDP zero checksum for IPv6 STAMP deviates from requirement 5 in . Requirement 5 of 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 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:
    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 corresponds to requirement 1 in .
    2. STAMP-Test packets in authenticated mode, as specified in and , are RECOMMENDED in networks where test packet payload integrity is required.This corresponds to requirement 2 in .
    3. Requirement 3 in does not apply to STAMP because test packets are not tunnel payloads and do not rely on an inner packet integrity check.
    4. UDP zero checksum is handled in STAMP so that corruption of header information is detected in STAMP and does not result in accumulation of incorrect state for the protocol.This corresponds to requirement 4 in .
    5. Requirements 6 and 7 in 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 .
    Additional specific guidance from that applies to IPv6 STAMP-Test packets that use UDP zero checksum is summarized below:
    1. Use of the UDP checksum with IPv6 MUST be the default configuration for all implementations.This corresponds to the first requirement in .
    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 corresponds to the second requirement in and also applies to and .
    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 corresponds to the third requirement in .
    4. STAMP sessions are restricted to networks under a single administrative domain (see ), where the operator is willing to take the risk of STAMP-Test packet corruption affecting measurements when using UDP zero checksum.This corresponds to the fourth requirement in .
    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 corresponds to the fifth requirement in .
    The operational considerations specified in and apply to the procedure and extensions specified in this document. In addition, the Management and Deployment Considerations specified in also apply when using the IOAM data fields specified in that document. An implementation MUST provide the ability to provision the measurement type as unidirectional or bidirectional as specified in . Additionally, an operator MAY provision a local policy on a Session-Reflector to not 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.
    The procedure specified requires that when there are multiple IPv6 extension headers with the same length added and not all of them need to be copied and reflected in the STAMP TLVs, the first 8 octets of each IPv6 extension header do not change before being received at the Session-Reflector as specified in . Similarly, when there are multiple IPv4/IPv6 headers with the same length added and not all of them need to be copied and reflected in the STAMP TLVs, the first 4 octets of each IPv4/IPv6 header do not change before being received at the Session-Reflector as specified in . 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 . 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 to verify the received IPv6 extension headers.
    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. The STAMP session state monitoring 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.
    • 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.
    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, as each STAMP-Test packet is processed by the control plane and consumes CPU and memory resources, it is 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.
    The security considerations specified in , , , and apply to the procedure and extensions specified in this document. In addition, the security considerations specified in and also apply when using IPv6 options for IOAM data fields. 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 forward and reverse direction paths 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 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 in a predictable manner to protect against off-path attacks. 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 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. 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 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 is requested to allocate the following TLVs from the IETF Review TLV range of the "STAMP TLV Types" registry under the Simple Two-way Active Measurement Protocol (STAMP) TLV Types registry group: 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 the following sub-TLV from the "STAMP Sub-TLV Types" Registry under the Simple Two-way Active Measurement Protocol (STAMP) TLV Types registry group: 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
    Note to the RFC Editor: Please replace all occurrences of TBA1, TBA2, and TBA3 with the values assigned by IANA.
    &RFC768; &RFC2119; &RFC6056; &RFC6335; &RFC6936; &RFC8085; &RFC8174; &RFC8200; &RFC8762; &RFC8972; &RFC9673; &RFC10052; Simple Two-way Active Measurement Protocol (STAMP) TLV Types IANA &RFC7820; &RFC8250; &RFC9197; &RFC9326; &RFC9486; &RFC9740; &I-D.ietf-ippm-on-path-active-measurements; &I-D.ietf-mpls-stamp-pw; Recommendation for Random Number Generation Using Deterministic Random Bit Generators 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 specified in this document in Teaparty. The authors would like to thank Vidhi Goel for the TSVART telechat review of , which resulted in the addition of the specifications for the IP/UDP header, UDP Checksum Handling, STAMP Session State, and Rate Limiting in this document. Thank you to Xiao Min for the PerfMetrdir review, Marcus Ihlar for the Shepherd's review, Mohamed Boucadair for the OPS Area AD review, Marc Blanchet for ArtArt review, which helped improve this document.