| Internet-Draft | STAMP over UDP-Lite | October 2026 |
| Gandhi | Expires 3 May 2027 | [Page] |
This document specifies the Simple Two-Way Active Measurement Protocol (STAMP) as defined in RFC 8762 and extended in RFC 8972, over the Lightweight User Datagram Protocol (UDP-Lite) for IPv4 and IPv6. Partial checksum coverage accommodates timestamp insertion after the checksum computation while protecting the integrity of transport header and IP pseudo-header.¶
This document updates RFC 8762 to permit an explicitly selected UDP-Lite transport with the existing UDP port number rules.¶
This document also updates RFC 8972 for transport-aware session identification, payload length determination, UDP port number reporting in the Location TLV, and replacing the use of the UDP Length field for detecting optional STAMP TLVs. STAMP payload formats and existing UDP-based sessions are unchanged.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 3 May 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The Simple Two-Way Active Measurement Protocol (STAMP) [RFC8762] enables active measurement of delay, delay variation, and packet loss in IP networks without a control channel to signal session parameters. A Session-Sender transmits test packets to a Session-Reflector, which returns test packets containing measurement information. [RFC8972] defines optional extensions encoded as Type-Length-Value (TLV) objects.¶
STAMP uses UDP [RFC0768] over IPv4 or IPv6. A nonzero UDP checksum covers the UDP header, complete payload, and IP pseudo-header. Late insertion of a hardware transmit timestamp invalidates a previously calculated checksum unless it is updated or a suitable checksum complement is applied. [RFC7820] describes a checksum-complement mechanism for OWAMP and TWAMP.¶
Processors may be unable to perform either of these operations after timestamp insertion, motivating UDP zero-checksum operation. However, disabling the checksum also removes transport header and pseudo-header integrity protection that can lead to packets being forwarded to another node or a different application. IPv4 UDP permits a zero checksum [RFC0768]; IPv6 UDP requires a nonzero checksum [RFC8200] except under specified exceptions as specified in [RFC6936]. STAMP is not covered by these exceptions.¶
The Lightweight User Datagram Protocol (UDP-Lite) [RFC3828] provides a mandatory checksum with configurable coverage. Its eight-octet header replaces the UDP Length field with a Checksum Coverage field. Header-only coverage permits timestamp insertion after checksum computation without updating the transport checksum, while retaining transport header and IP pseudo-header protection. Excluded measurement data such as timestamps remains unprotected by that checksum; STAMP authentication requirements are unchanged by the procedures in this document.¶
This document updates [RFC8762] to permit an explicitly selected UDP-Lite transport with the existing UDP port number rules.¶
This document also updates [RFC8972] for transport-aware session identification, payload length determination, UDP port number reporting in the Location TLV, and replacing the use of the UDP Length field for detecting optional STAMP TLVs. These updates apply only to UDP-Lite sessions; existing UDP behavior is unchanged.¶
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.¶
This document uses the terms Session-Sender, Session-Reflector, STAMP-Test packet, stateful, and stateless as defined in [RFC8762], and SSID, STAMP TLV Flags, and sub-TLV as defined in [RFC8972].¶
This document uses the term IPv4 pseudo-header defined in [RFC0768] and IPv6 pseudo-header defined in [RFC8200].¶
The length, in octets, of the complete UDP-Lite header and payload, as determined by the IP layer. Preceding IP headers and extension headers are excluded.¶
The number of octets protected starting at the first octet of the UDP-Lite header. C equals L when the Checksum Coverage field is zero; otherwise, C equals that field's value.¶
A Checksum Coverage field value of 8, protecting the integrity of UDP-Lite header and IP pseudo-header but no STAMP payload octets.¶
Complete checksum coverage of the UDP-Lite header and STAMP payload octets, in addition to the mandatory IP pseudo-header.¶
| Abbreviation | Meaning | Reference |
|---|---|---|
| HMAC | Hashed Message Authentication Code | [RFC8762] |
| MTU | Maximum Transmission Unit | [RFC8200] |
| SSID | STAMP Session Identifier | [RFC8972] |
| STAMP | Simple Two-Way Active Measurement Protocol | [RFC8762] |
| TLV | Type-Length-Value | [RFC8972] |
| UDP | User Datagram Protocol | [RFC0768] |
| UDP-Lite | Lightweight User Datagram Protocol | [RFC3828] |
In Figure 1, S1 sends a Session-Sender test packet and R1 returns a Session-Reflector test packet. M1 is a midpoint node that performs IP forwarding without STAMP processing. The return packet need not traverse M1 or follow the same links as the forward packet.¶
T1 T2
/ \
+-------+ Test Packet +-------+ +-------+
| | - - - - - - - - | | - - - - - - - - ->| |
| S1 |=================| M1 |===================| R1 |
| |<- - - - - - - - | | - - - - - - - - - | |
+-------+ +-------+ Reply Test Packet +-------+
\ /
T4 T3
Session-Sender 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.¶
The solution replaces the UDP header with a UDP-Lite header and sets the IPv4 Protocol field, or the IPv6 Next Header field that identifies the transport, to 136 (UDPLite). It retains the payload formats in Section 3 of [RFC8972], including optional TLVs, both authentication modes, and stateful or stateless reflector operation.¶
Endpoints explicitly select UDP-Lite and compatible checksum coverage policies before transmission. Full checksum coverage is the default; partial checksum coverage requires explicit configuration. Each direction has an independent transmit coverage and receive policy.¶
The existing STAMP UDP port number selection rules apply, including default destination UDP port number 862. A UDP session and a UDP-Lite session can use the same UDP port numbers because IP protocol numbers 17 (for UDP) and 136 (for UDP-Lite) distinguish the transports.¶
UDP-Lite MUST be explicitly enabled for the applicable session on both endpoints before STAMP-test packets are sent. Provisioning MUST identify the endpoint addresses, transport protocol, UDP port numbers, authentication mode, applicable SSID information, transmit checksum coverage, and receive coverage policy. Provisioning MAY be local or use a control-plane mechanism; the mechanism is outside the scope of this document.¶
An implementation MUST include the transport protocol in the session demultiplexing context, in addition to the identifying elements required by Section 3 of [RFC8972]. UDP-Lite packets MUST NOT be delivered to a UDP STAMP session or used to create one implicitly. SSID generation, uniqueness, presence, copying, and matching rules in [RFC8972] are unchanged. Non-matching STAMP-Test packets MUST be discarded.¶
A response to a UDP test packet does not demonstrate UDP-Lite support. Implementations MUST NOT switch an active session between UDP and UDP-Lite based solely on packet loss or an ICMP error. A transport change requires explicit reprovisioning, and measurements from the different transports MUST be distinguishable.¶
For UDP-Lite sessions, the UDP port number selection and configuration rules in Section 4.1 of [RFC8762] MUST apply to the source and destination UDP port number fields in the UDP-Lite header. The default destination UDP port number for Session-Sender test packets MUST be 862, and an enabled UDP-Lite Session-Reflector MUST support receiving test packets on that UDP port number. Implementations MUST support configured destination UDP port numbers from the User Ports and Dynamic Ports ranges defined in [RFC6335]. Before using User Ports, the possible network impact MUST be studied and agreed upon by the users of the affected network domain.¶
The Session-Sender source UDP port number SHOULD be selected from the Dynamic Ports range (49152-65535) using a randomized allocation method as described in [RFC6056]. The source UDP port number MUST NOT equal the local Session-Reflector listening UDP port number.¶
For a reply, the Session-Reflector MUST use the received source UDP port number as its destination UDP port number and the received destination UDP port number as its source UDP port number. UDP-Lite uses the UDP port number assignments specified in Section 3.1 of [RFC3828].¶
The following encapsulations apply to both Session-Sender and Session-Reflector packets. The Session-Sender uses its provisioned source address and the Session-Reflector destination address. The reply uses the Session-Reflector source address and the received Session-Sender source address as its destination, subject to the provisioned session's address validation policy.¶
A STAMP-Test packet carried over UDP-Lite MUST NOT be fragmented and MUST fit within the path MTU. This requirement applies to both Session-Sender test packets and Session-Reflector replies over IPv4 and IPv6. The complete IP packet size, including all IP headers, extension headers, the UDP-Lite header, and the STAMP payload (including any TLVs and padding), MUST NOT exceed the path MTU in the direction of transmission.¶
+-------------------------------------------------------------+ | IPv4 Header (including options, if present) | | Protocol = 136 (UDPLite) | | Total Length = IPv4 header length + L | +-------------------------------------------------------------+-- | UDP-Lite Header (8 octets) | | | Source UDP Port Number | Destination UDP Port Number | | | Checksum Coverage Size | Checksum | +-------------------------------------------------------------+ L | STAMP payload: RFC 8972, Section 3 | | Sender: Figure 1 or 3; Reflector: Figure 2 or 4 | | | Optional TLVs follow the base STAMP packet | | +-------------------------------------------------------------+--
The IPv4 Protocol field MUST be 136 (for UDP-Lite), not 17 (for UDP).¶
The IPv4 Total Length field MUST describe the complete IPv4 packet. L MUST be determined by subtracting the IPv4 header length, obtained from IHL in units of four octets, from the IPv4 Total Length.¶
The IPv4 header checksum MUST be generated and verified according to [RFC0791]; it is separate from the mandatory UDP-Lite checksum.¶
+-------------------------------------------------------------+ | IPv6 Header | | Next Header = 136 if UDP-Lite immediately follows | | Otherwise, identifies the first extension header | +-------------------------------------------------------------+ | Optional IPv6 extension headers | | Last preceding Next Header = 136 (UDPLite) | +-------------------------------------------------------------+-- | UDP-Lite Header (8 octets) | | | Source UDP Port Number | Destination UDP Port Number | | | Checksum Coverage Size | Checksum | +-------------------------------------------------------------+ L | STAMP payload: RFC 8972, Section 3 | | Sender: Figure 1 or 3; Reflector: Figure 2 or 4 | | | Optional TLVs follow the base STAMP packet | | +-------------------------------------------------------------+--
The Next Header field immediately identifying UDP-Lite MUST be 136. When extension headers [RFC8200] precede UDP-Lite, the IPv6 base header MUST identify the first such header, and the preceding header chain MUST identify UDP-Lite as specified in [RFC8200].¶
L MUST be obtained from the IPv6 Payload Length after subtracting the lengths of all extension headers preceding UDP-Lite.¶
UDP-Lite jumbogram handling is described in Section 3.5 of [RFC3828], and the IPv6 Jumbo Payload option is specified in [RFC2675]. These procedures are not applicable to STAMP over UDP-Lite as specified in this document; STAMP-Test packets MUST NOT use IPv6 jumbograms. The IPv6 fragmentation and reassembly procedures in Section 4.5 of [RFC8200] are also not applicable to these STAMP-Test packets, which MUST NOT be fragmented and MUST fit within the path MTU.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source UDP Port Number | Destination UDP Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum Coverage | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All fields are 16 bits in network byte order. The header MUST conform to [RFC3828]. Checksum Coverage is defined in Section 2.2; zero means full checksum coverage, not a disabled checksum. Values 1 through 7 are invalid, and a nonzero value MUST NOT exceed L.¶
Figure 5 illustrates partial checksum coverage with 8 < C < L. L includes the UDP-Lite header and the complete STAMP payload; C includes the UDP-Lite header and the covered prefix of that payload.¶
IP headers and extension headers are outside both lengths. The IP pseudo-header is also covered by the checksum but is not included in L or C.¶
+-------------------------------+ | IP header + extension headers | +-------------------------------+-- -- | UDP-Lite header (8 octets) | | | +-------------------------------+ C | STAMP payload: covered prefix | L | +-------------------------------+ -- | STAMP payload: uncovered rest | | +-------------------------------+--
Both endpoints MUST generate a nonzero UDP-Lite checksum for every transmitted packet, for both IPv4 and IPv6, following Sections 3.1 and 3.2 of [RFC3828]. The checksum MUST cover the IP pseudo-header and the first C octets of the UDP-Lite packet. The Checksum field MUST be treated as zero during calculation. An odd number of covered octets MUST be virtually padded by one zero octet for calculation only; this padding MUST NOT be transmitted. A calculated value of zero MUST be transmitted as 0xffff.¶
The pseudo-header MUST contain protocol number 136 and the complete UDP-Lite packet length L, not C and not the Checksum Coverage field. For IPv4, it contains the source and destination IPv4 addresses, a zero octet, protocol 136, and the 16-bit L. For IPv6, it contains the source and destination IPv6 addresses, the 32-bit upper-layer packet length L, three zero octets, and Next Header 136. Pseudo-header address selection when IP routing headers or source routing are present MUST follow the applicable IP specifications.¶
When a timestamp or other payload field is changed after checksum calculation, every changed octet MUST lie outside C, or the checksum MUST be updated before transmission. Partial checksum coverage is a contiguous prefix and cannot skip a timestamp to protect a later TLV. Any change to a covered transport field, an address used in the pseudo-header, or L requires a valid checksum for the resulting packet, even with header-only coverage.¶
Full checksum coverage for transmission and a receive policy MUST be the defaults. A Session-Sender using full checksum coverage SHOULD encode it with Checksum Coverage equal to zero. A receiver MUST also recognize a nonzero field equal to L as full checksum coverage.¶
Transmission with partial checksum coverage and acceptance of partial checksum coverage for reception MUST require explicit configuration for the applicable STAMP session.¶
An implementation MAY transmit with Checksum Coverage equal to 8 when the receiving endpoint is configured to accept header-only coverage. An implementation MAY use a partial checksum coverage when supported by both endpoints. A receive policy MUST specify full checksum coverage that includes base STAMP packet of 44 octets in the unauthenticated mode or 112 octets in the authenticated mode [RFC8972] or a minimum effective coverage that includes the first 4 bytes for STAMP packet, and MUST reject packets below that requirement.¶
A policy allowing partial checksum coverage MUST also accept full checksum coverage; coverage field zero MUST be evaluated as L for this comparison.¶
Section 3.4 of [RFC3828] specifies: "As for UDP, the IP module must provide the pseudo header to the UDP-Lite protocol module (known as the UDPLite module)." The receiver MUST validate the UDP-Lite header and checksum before using any STAMP measurement data or generating a STAMP-Test packet reply. The receiver MUST discard a packet if any of the following holds:¶
Malformed TLVs MUST follow the existing STAMP error processing rules in [RFC8972].¶
+-------------------------------+ | IP header + extension headers | +-------------------------------+---- | UDP-Lite header (8 octets) | 8 | +-------------------------------+-- | -- | STAMP payload: base | | L B +-------------------------------+ P | -- | STAMP payload: TLVs | | | +-------------------------------+----
The STAMP payload length P MUST be calculated as P = L - 8, as shown in Figure 6, independently of the Checksum Coverage field. This rule updates use of the UDP Length field for detecting optional TLVs in Section 4 of [RFC8972] when UDP-Lite is used.¶
Let B be 44 octets for unauthenticated packets or 112 octets for authenticated packets. If P is less than B, the packet MUST be discarded. If P equals B, it contains no optional TLVs. If P is greater than B, the remaining P - B octets MUST be processed as optional TLVs using [RFC8972].¶
A receiver MUST bound all payload accesses by P, validate TLV headers and lengths, and apply the U, M, and I flag handling and HMAC verification procedures in [RFC8972].¶
The Session-Sender MUST construct the applicable payload from Figure 1 or Figure 3 of [RFC8972], append any optional TLVs, and encapsulate it as specified above. The Session-Reflector MUST validate it under Section 4.7 before constructing the reply using Figure 2 or Figure 4 of [RFC8972].¶
The Session-Reflector MUST send its reply using UDP-Lite, not UDP, and MUST generate its checksum under Section 4.4 rather than copy the received checksum. Reply coverage MUST follow the reflector's provisioned transmit policy and the Session-Sender's receive policy.¶
For a UDP-Lite session, the source and destination UDP port number fields of the Location TLV in Section 4.2 of [RFC8972] MUST report the UDP port numbers from the received UDP-Lite header rather than a UDP header.¶
The Session-Sender MUST validate the received reply according to Section 4.6 and the existing STAMP rules before accepting a measurement.¶
The operation and management considerations in [RFC8762] apply. This specification is intended for deployment in a controlled administrative domain.¶
Operators MUST verify support for IP protocol 136 in both directions before enabling a session. Firewalls, access lists, policers, packet classifiers, NATs, and hardware checksum offloads configured only for UDP protocol 17 do not necessarily support UDP-Lite, even when the UDP port numbers match.¶
Management interfaces SHOULD expose the selected transport, transmit coverage, receive coverage policy, endpoint addresses, UDP port numbers, authentication mode, and session identifiers.¶
Implementations SHOULD expose separate counters for checksum errors, invalid coverage, coverage-policy rejection, session mismatch, authentication failure, malformed packets, and local rate limiting to distinguish local failures from path loss.¶
Implementations MUST select STAMP-Test packet sizes so that the complete IP packet fits within the path MTU in each direction, as required in Section 4.3. STAMP-Test packets MUST NOT be fragmented to accommodate a smaller path MTU. IPv6 Path MTU Discovery is specified in [RFC8201].¶
UDP-Lite can receive different ECMP or traffic class treatment from UDP, even with identical addresses and UDP port numbers. Operators SHOULD verify that treatment before interpreting measurements as representative of the monitored service.¶
UDP-Lite provides neither congestion control nor reliability. The traffic load analysis required by [RFC8762] and the applicable guidance in [RFC8085] apply to both directions. Implementations SHOULD provide configurable transmission rates, pacing, burst limits, and receive and reflection resource limits. Operators MUST account for aggregate traffic from concurrent sessions and reflected packets. When relying on provisioned capacity, offered measurement traffic MUST remain within that capacity; traffic MUST be reduced or stopped when that assumption no longer holds.¶
Receive and reflection limits SHOULD accommodate authorized traffic while protecting device resources. Local drops, unsupported transport, checksum coverage-policy mismatch, and checksum-offload errors can appear as path loss and SHOULD be distinguishable operationally. Implementations SHOULD correlate local limiting with session failure indications.¶
Links carrying these sessions MUST retain full-frame integrity checking and MUST NOT enable UDP-Lite-specific delivery of partially damaged frames for this traffic. Link checking does not replace end-to-end payload integrity.¶
UDP-only STAMP implementation require a separately provisioned UDP session for interoperability under Section 4.6 of [RFC8762].¶
Partial checksum coverage accommodates timestamp insertion after checksum computation, not delivery of damaged measurement data. A STAMP-Test packet carried in unauthenticated mode provides no STAMP authentication-based detection of packet corruption. When partial checksum coverage is used with UDP-Lite, corruption in STAMP payload octets outside that coverage is not detected by the transport checksum. Implementations MUST perform the specified STAMP packet and session validation, including checks of packet format, session identification, the timestamp fields (the two timestamps taken at the same node are in the expected order; see Section 6), and TLV structure and length, and MUST discard packets that fail those checks. These checks detect some invalid packets but do not provide general integrity protection: corruption that leaves a packet valid, including changes to measurement fields or TLV values, may go undetected and affect the measurement. Thus, a session using partial checksum coverage with UDP-Lite but without authenticated STAMP has no general assurance that its measurement information is intact.¶
The security considerations of [RFC8762], [RFC8972], and [RFC3828] apply. UDP-Lite's checksum is an error-detection mechanism, not a cryptographic integrity or peer-authentication mechanism. An attacker can construct a packet with a valid checksum.¶
The residual corruption risks and mandatory packet checks for partial checksum coverage are described in Section 5. Before enabling partial checksum coverage, operators MUST assess and accept those risks. Full checksum coverage SHOULD be used whenever the implementation can update the checksum after timestamp insertion. When protection of measurement data against undetected alteration is required with partial checksum coverage, authenticated STAMP MUST be used, together with the HMAC TLV where required by Section 4.8 of [RFC8972]. The base HMAC and HMAC TLV retain their specified coverage and limitations, including the lack of replay protection provided by the HMAC TLV alone.¶
Implementations MUST treat uncovered bytes as untrusted input. Checks must account for reordering, timestamp representation, clock accuracy, and synchronization state. Checking T3 >= T2 or T4 > T1 compares timestamps from the same node and it does not require clock synchronization; whereas comparing T2 with T1 from two different nodes requires synchronized clocks.¶
Operators MUST restrict UDP-Lite STAMP traffic to authorized endpoints and UDP port numbers with appropriate administrative-boundary filtering and local policy. A UDP-Lite listener MUST NOT enable unrestricted reflection based on a matching UDP port number. Source address validation, randomized Session-Sender UDP port number selection, session matching, and resource limits mitigate spoofing, reflection, amplification, and denial-of-service risks but do not authenticate peers or prevent on-path attacks.¶
Control and management of STAMP sessions MUST use secured transport as required by [RFC8762]. Capability, coverage policy, and checksum validation MUST NOT be relaxed in response to unauthenticated traffic or apparent loss.¶
UDP-Lite provides no confidentiality. When confidentiality is needed, the secured-transport requirements in Section 4.5 of [RFC8762] apply; partial checksum coverage for UDP-Lite does not bypass the processing requirements of protection such as IPsec.¶
This document requests no IANA actions.¶