Internet Engineering Task Force N. Elkins Internet-Draft Inside Products, Inc. Intended status: Standards Track M. Ackermann Expires: 14 February 2027 BCBS Michigan A. Deshpande NITK Surathkal/Google T. Pecorella University of Florence A. Rashid Politecnico di Bari L. Fedi University of Florence 13 August 2026 IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination Option draft-ietf-ippm-encrypted-pdmv2-15 Abstract RFC 8250 defines an IPv6 Destination Option that carries Performance and Diagnostic Metrics (PDM) such as sequence numbers and timing information. While useful for measurement and troubleshooting, clear-text PDM data may expose operational characteristics of endpoints and networks. This document defines PDMv2, a revised version of PDM that introduces a registration-based security model. Instead of specifying cryptographic algorithms or inline key negotiation, PDMv2 relies on a prior registration process to authenticate entities, authorize participation, and establish shared secrets. These secrets are then used by endpoints and authorized analyzers to protect and interpret PDMv2 data according to local policy. This document specifies the PDMv2 semantics, header structure, and operational model. The selection of specific cryptographic algorithms and key derivation functions, and the definition of any cipher-negotiation mechanism, are outside the scope of this document. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://ameyand.github.io/PDMv2/draft-elkins-ippm-encrypted- pdmv2.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-ippm-encrypted-pdmv2/. Elkins, et al. Expires 14 February 2027 [Page 1] Internet-Draft draft-ietf-ippm-encrypted-pdmv2 August 2026 Discussion of this document takes place on the IP Performance Measurement Working Group mailing list (mailto:ippm@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ippm/. Subscribe at https://www.ietf.org/mailman/listinfo/ippm/. Source for this draft and an issue tracker can be found at https://github.com/ameyand/PDMv2. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 14 February 2027. Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 4. PDMv2 Foundational Principles . . . . . . . . . . . . . . . . 4 5. Registration Framework Overview . . . . . . . . . . . . . . . 5 5.1. Registration Objectives . . . . . . . . . . . . . . . . . 5 5.2. Registration Participants . . . . . . . . . . . . . . . . 6 Elkins, et al. Expires 14 February 2027 [Page 2] Internet-Draft draft-ietf-ippm-encrypted-pdmv2 August 2026 5.3. Registration Transport . . . . . . . . . . . . . . . . . 6 5.4. Registration Output and SessionTemporaryKey . . . . . . . 6 6. PDMv2 Destination Options . . . . . . . . . . . . . . . . . . 8 6.1. Use of IPv6 Destination Options . . . . . . . . . . . . . 8 6.2. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.3. Global Pointer . . . . . . . . . . . . . . . . . . . . . 8 7. PDMv2 Destination Option . . . . . . . . . . . . . . . . . . 8 7.1. Unprotected PDMv2 Format . . . . . . . . . . . . . . . . 9 7.2. Protected PDMv2 Format . . . . . . . . . . . . . . . . . 10 7.3. Option Type . . . . . . . . . . . . . . . . . . . . . . . 12 7.4. Version . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.5. Epoch . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.6. PDMv2 Flow Identification . . . . . . . . . . . . . . . . 13 7.7. Packet Sequence Number This Packet . . . . . . . . . . . 14 7.8. Packet Sequence Number Last Received . . . . . . . . . . 15 7.9. Global Pointer . . . . . . . . . . . . . . . . . . . . . 15 7.10. Scale Fields and Delta Times . . . . . . . . . . . . . . 15 7.11. Reserved Field . . . . . . . . . . . . . . . . . . . . . 16 7.12. Segmentation and Aggregation Offload . . . . . . . . . . 16 7.13. Protected Options and Repeated PSNTP Values . . . . . . . 17 7.14. Receiver Validation and Exception Handling . . . . . . . 17 8. Operational Model . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Registration Phase . . . . . . . . . . . . . . . . . . . 19 8.2. Measurement Phase . . . . . . . . . . . . . . . . . . . . 19 8.3. Analysis Phase . . . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 11.1. PDMv2 Destination Option . . . . . . . . . . . . . . . . 21 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 13. Normative References . . . . . . . . . . . . . . . . . . . . 21 Appendix A. Example: RADIUS / EAP-Based Registration . . . . . . 22 A.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 22 A.2. Participants . . . . . . . . . . . . . . . . . . . . . . 22 A.3. Registration Flow (Example) . . . . . . . . . . . . . . . 23 A.4. Registration Flow (Illustrative ASCII Diagram) . . . . . 24 A.5. Use with PDMv2 Traffic . . . . . . . . . . . . . . . . . 24 A.6. Key Lifecycle Considerations . . . . . . . . . . . . . . 24 A.7. Example Deployment: Federated Environments (eduroam-Style) . . . . . . . . . . . . . . . . . . . . . 25 A.8. Why TLS Session Keys Are Not Reused (Informative) . . . . 25 A.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 26 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 26 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Elkins, et al. Expires 14 February 2027 [Page 3] Internet-Draft draft-ietf-ippm-encrypted-pdmv2 August 2026 1. Introduction The Performance and Diagnostic Metrics (PDM) Destination Option defined in [RFC8250] provides packet sequence numbers and timing information to support performance measurement and diagnostics. While effective, transmitting such information in clear text can reveal details about endpoint behavior, processing capability, and network characteristics. PDMv2 enhances PDM by enabling secure operation through a registration-first architecture. Security-sensitive material is established out of band, prior to data transmission, and is not negotiated inline with PDMv2 traffic. This approach preserves the lightweight nature of PDM while avoiding tight coupling to transport- layer security protocols. PDMv2 operates entirely at the IPv6 layer and applies uniformly to TCP, UDP, ICMP, QUIC, and other upper-layer protocols. Intermediate devices are not required to decrypt or interpret PDMv2 contents. 2. Conventions used in this document 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. 3. Design Goals PDMv2 is designed with the following goals: * Maintain compatibility with the operational model of [RFC8250] * Avoid inline cryptographic handshakes at the IP layer * Support heterogeneous transport protocols and non-transport flows * Enable offline analysis by authorized entities * Integrate cleanly with existing authentication and authorization infrastructures 4. PDMv2 Foundational Principles PDMv2 adheres to the following foundational principles: Elkins, et al. Expires 14 February 2027 [Page 4] Internet-Draft draft-ietf-ippm-encrypted-pdmv2 August 2026 * Registration-First Security: All security context used by PDMv2 is established during a prior registration phase. No cryptographic negotiation occurs during PDMv2 packet exchange. * IP-Layer Independence: PDMv2 security does not depend on TCP, TLS, QUIC, or any specific transport protocol. * Minimal On-Path Impact: Routers and intermediate nodes forward PDMv2 packets without decryption or inspection. * Offline Decryption and Analysis: PDMv2 data MAY be collected and analyzed after transmission. Real-time interpretation is optional and deployment-specific. * Separation of Specification Scope: This document defines protocol behavior and data formats, not cryptographic algorithms. * Explicit Authorization: Only registered and authorized entities may emit, receive, or analyze protected PDMv2 data. 5. Registration Framework Overview PDMv2 relies on an external registration system to establish trust and shared context between participating entities. 5.1. Registration Objectives A PDMv2 registration mechanism establishes the context required for authorized endpoints and measurement systems to generate, receive, interpret, and, when applicable, decrypt PDMv2 information. A registration mechanism is expected to provide: * identification and authorization of participating endpoints or measurement domains; * authorization to generate, receive, or analyze PDMv2 data; * selection of the PDMv2 protection suite; * establishment or provisioning of the keying material required by that suite; * assignment of an Epoch value; * definition of the scope and lifetime of the resulting security context; Elkins, et al. Expires 14 February 2027 [Page 5] Internet-Draft draft-ietf-ippm-encrypted-pdmv2 August 2026 * delivery of the context required to construct nonces and associated data; and * procedures for expiration, replacement, and revocation of the security context. This document does not require a particular registration protocol. Appendix A describes one possible mechanism. 5.2. Registration Participants The following logical roles are assumed: * Client : An endpoint that initiates communication and emits PDMv2 data * Server : An endpoint that receives communication and emits PDMv2 data * Authentication Server (AS) : A trusted entity that performs authentication and authorization * Analyzer : An authorized entity that interprets collected PDMv2 data An implementation MAY combine roles within a single system. 5.3. Registration Transport The registration exchange MUST be protected by a secure channel. The choice of transport and security protocol is out of scope for this document. 5.4. Registration Output and SessionTemporaryKey A successful registration produces a PDMv2 security context containing, at minimum: * the identities or measurement domains to which the context applies; * the authorization granted to each participant; * the selected PDMv2 protection suite; * an Epoch value; * keying material or a directly provisioned SessionTemporaryKey; Elkins, et al. Expires 14 February 2027 [Page 6] Internet-Draft draft-ietf-ippm-encrypted-pdmv2 August 2026 * the scope and lifetime of the keying material; and * the information required to construct nonces and associated data. A SessionTemporaryKey is cryptographic keying material used to protect PDMv2 metric blocks during a bounded key epoch. It is derived or provisioned from keying material established by the applicable registration mechanism. The registration mechanism or protection-suite specification MUST define: * how the SessionTemporaryKey is derived or provisioned; * the cryptographic algorithm and key length; * the endpoints, flows, or measurement domain to which the key applies; * the Epoch value associated with the key; * the lifetime of the key; * the rekey procedure; * how authorized measurement systems obtain the required security context; and * how expiration and revocation are handled. When a SessionTemporaryKey is derived from a master secret, the derivation MUST use a cryptographically secure key-derivation function and a PDMv2-specific purpose label. The derivation MUST provide cryptographic separation between PDMv2 keys and keys used by other protocols or for other purposes. A PDMv2 SessionTemporaryKey MUST NOT be a TLS, QUIC, IPsec, or other application or transport traffic key. The specific registration protocol and key-derivation function are outside the scope of this document. This document specifies the PDMv2 on-wire formats and the processing and exception-handling requirements for those formats. A registration mechanism supplies the security context described in this section but does not redefine receiver behavior for malformed, unauthenticated, or unauthorized PDMv2 options. Elkins, et al. Expires 14 February 2027 [Page 7] Internet-Draft draft-ietf-ippm-encrypted-pdmv2 August 2026 6. PDMv2 Destination Options 6.1. Use of IPv6 Destination Options PDMv2 is carried as an IPv6 Destination Option within the Destination Options Header as defined in [RFC8200]. Processing rules from [RFC8250] continue to apply unless explicitly updated by this document. 6.2. Metrics PDMv2 supports the following metrics: * Packet Sequence Number (This Packet) * Packet Sequence Number (Last Received) * Delta Time Last Received * Delta Time Last Sent * Global Pointer These metrics have the same semantics as in [RFC8250], with the addition of the Global Pointer. 6.3. Global Pointer The Global Pointer provides a coarse indicator of packet transmission activity by an endpoint. Separate counters are maintained for link- local and global unicast source addresses. 7. PDMv2 Destination Option PDMv2 defines an unprotected wire format and a protected wire format. Both formats use the PDMv2 Option Type assigned by IANA. PDMv2 does not reuse the PDM Option Type 0x0F assigned by [RFC8250]. References in this document to fields adopted from [RFC8250] describe their semantics and do not indicate reuse of the RFC 8250 Option Type. The Option Length distinguishes the unprotected and protected formats. A receiver can therefore determine from the PDMv2 option itself whether the metric block is protected. Registration context is required to decrypt and interpret a protected metric block, but it is not required merely to identify the format. Elkins, et al. Expires 14 February 2027 [Page 8] Internet-Draft draft-ietf-ippm-encrypted-pdmv2 August 2026 An implementation MUST NOT determine whether a received PDMv2 option is protected solely from local policy or registration context. 7.1. Unprotected PDMv2 Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Len=22 | Version | Epoch | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Sequence Number This Packet | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Sequence Number Last Received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ScaleDTLR | ScaleDTLS | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delta Time Last Received | Delta Time Last Sent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Option Length is 22 decimal (0x16). As specified for IPv6 options, the Option Length excludes the Option Type and Option Length octets. The complete unprotected PDMv2 option occupies 24 octets. The fields following the Option Length are: Elkins, et al. Expires 14 February 2027 [Page 9] Internet-Draft draft-ietf-ippm-encrypted-pdmv2 August 2026 +========+==========+==========================+ | Offset | Length | Field | +========+==========+==========================+ | 2 | 4 bits | Version | +--------+----------+--------------------------+ | 2 | 12 bits | Epoch | +--------+----------+--------------------------+ | 4 | 4 octets | PSNTP | +--------+----------+--------------------------+ | 8 | 4 octets | PSNLR | +--------+----------+--------------------------+ | 12 | 4 octets | Global Pointer | +--------+----------+--------------------------+ | 16 | 1 octet | ScaleDTLR | +--------+----------+--------------------------+ | 17 | 1 octet | ScaleDTLS | +--------+----------+--------------------------+ | 18 | 2 octets | Reserved | +--------+----------+--------------------------+ | 20 | 2 octets | Delta Time Last Received | +--------+----------+--------------------------+ | 22 | 2 octets | Delta Time Last Sent | +--------+----------+--------------------------+ Table 1 7.2. Protected PDMv2 Format The protected format uses an authenticated-encryption protection suite that produces a 16-octet authentication tag. Elkins, et al. Expires 14 February 2027 [Page 10] Internet-Draft draft-ietf-ippm-encrypted-pdmv2 August 2026 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Len=38 | Version | Epoch | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Sequence Number This Packet | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Protected Metric Block + | (16 octets) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Authentication Tag + | (16 octets) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Option Length is 38 decimal (0x26). It excludes the Option Type and Option Length octets. The complete protected PDMv2 option occupies 40 octets. The plaintext protected metric block is: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Sequence Number Last Received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ScaleDTLR | ScaleDTLS | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delta Time Last Received | Delta Time Last Sent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The protected format has the following organization: Elkins, et al. Expires 14 February 2027 [Page 11] Internet-Draft draft-ietf-ippm-encrypted-pdmv2 August 2026 +========+===========+================+=========================+ | Offset | Length | Field | Protection | +========+===========+================+=========================+ | 0 | 1 octet | Option Type | Clear and authenticated | +--------+-----------+----------------+-------------------------+ | 1 | 1 octet | Option Length | Clear and authenticated | +--------+-----------+----------------+-------------------------+ | 2 | 4 bits | Version | Clear and authenticated | +--------+-----------+----------------+-------------------------+ | 2 | 12 bits | Epoch | Clear and authenticated | +--------+-----------+----------------+-------------------------+ | 4 | 4 octets | PSNTP | Clear and authenticated | +--------+-----------+----------------+-------------------------+ | 8 | 16 octets | Protected | Encrypted and | | | | Metric Block | authenticated | +--------+-----------+----------------+-------------------------+ | 24 | 16 octets | Authentication | AEAD output | | | | Tag | | +--------+-----------+----------------+-------------------------+ Table 2 The Option Type, Option Length, Version, Epoch, and PSNTP fields MUST be cryptographically bound to the protected metric block as associated data. This specification requires a 16-octet authentication tag. A future protection suite using a different tag length must define an unambiguous on-wire indication of its format and length. 7.3. Option Type The Option Type is the 8-bit value assigned by IANA for PDMv2: TBD1 TBD1 is distinct from the PDM Option Type 0x0F assigned by [RFC8250]. The required IPv6 option action and change-en-route bits are reflected in the value assigned by IANA. The hexadecimal value remains TBD1 until the allocation is made. 7.4. Version The Version field is a 4-bit unsigned integer. This document defines Version 2. Elkins, et al. Expires 14 February 2027 [Page 12] Internet-Draft draft-ietf-ippm-encrypted-pdmv2 August 2026 A receiver that does not support the indicated version MUST process the option according to the action bits in the PDMv2 Option Type. The receiver MUST NOT interpret the remaining fields using the Version 2 format. 7.5. Epoch The Epoch field is a 12-bit unsigned integer identifying the PDMv2 security context and SessionTemporaryKey applicable to the protected option. The Epoch value is a key selector. It is not secret keying material. The registration mechanism or protection-suite specification MUST define how an Epoch is assigned, how long it remains valid, and how a receiver maps the Epoch to the applicable security context. A sender MUST NOT independently protect different PDMv2 plaintext values using the same SessionTemporaryKey and nonce. Before PSNTP reuse could cause nonce reuse with the same SessionTemporaryKey, the sender MUST establish a new key epoch or otherwise follow a nonce construction defined by the selected protection suite that prevents nonce reuse. 7.6. PDMv2 Flow Identification The term "PDMv2 flow" identifies the packet sequence and associated PDMv2 state. It is not limited to protocols that provide transport- layer port numbers. For TCP and UDP, a PDMv2 flow is identified by: * IPv6 source address; * IPv6 destination address; * upper-layer protocol number; * source port; and * destination port. For ICMPv6, where transport-layer ports do not exist, a PDMv2 flow is identified by: * IPv6 source address; Elkins, et al. Expires 14 February 2027 [Page 13] Internet-Draft draft-ietf-ippm-encrypted-pdmv2 August 2026 * IPv6 destination address; * ICMPv6 Next Header value; * ICMPv6 Type; and * ICMPv6 Code. For ICMPv6 message types containing an Identifier field, such as Echo Request and Echo Reply, an implementation SHOULD also use that Identifier to distinguish concurrent exchanges. An ICMPv6 error message is classified using its outer IPv6 and ICMPv6 headers. The quoted packet carried inside the ICMPv6 error message does not identify the flow carrying the PDMv2 option. For another upper-layer protocol without port numbers, the protocol specification or registration context SHOULD define an equivalent stable flow identifier. If no protocol-specific discriminator is available, packets having the same IPv6 source address, IPv6 destination address, and upper-layer protocol number are treated as one PDMv2 flow. For TCP and UDP, the corresponding reverse-direction flow is identified by exchanging the source and destination IPv6 addresses and exchanging the source and destination ports. For ICMPv6 request-and-reply message pairs, the corresponding reverse-direction flow exchanges the source and destination IPv6 addresses and associates the applicable request Type with its corresponding reply Type. When an Identifier field is present, the same Identifier is used for the association. A registration or protocol specification defining another request-and-reply relationship MUST define its reverse-direction mapping. If no corresponding reverse-direction flow can be identified, PSNLR is initialized as specified by this document. 7.7. Packet Sequence Number This Packet The Packet Sequence Number This Packet field, abbreviated PSNTP, is a 32-bit unsigned integer. PSNTP is initialized to a pseudorandom value when PDMv2 state is created for a flow. It is incremented modulo (2^{32}) for each packet processed as a new transmission at the PDMv2 sender's processing point. Elkins, et al. Expires 14 February 2027 [Page 14] Internet-Draft draft-ietf-ippm-encrypted-pdmv2 August 2026 PSNTP counts packet-processing events visible to the PDMv2 module. It does not count application data units, TCP sequence space, or unique transport payloads. A TCP retransmission presented to the PDMv2 module as a new packet is a new transmission and receives a new PSNTP value. Packets produced below the PDMv2 processing point by segmentation offload can retain the PSNTP value of the packet from which they were produced, as described in Section 7.12. 7.8. Packet Sequence Number Last Received The Packet Sequence Number Last Received field, abbreviated PSNLR, contains the PSNTP value from the most recently received PDMv2 observation associated with the corresponding reverse-direction flow. Because segmentation, aggregation, packet duplication, reordering, or differences in processing location can affect the observations available to an implementation, PSNLR describes the most recent PDMv2 observation at the implementation's processing point. It does not necessarily identify the last physical packet received by an interface. Before a PDMv2 option has been received for the corresponding reverse-direction flow, PSNLR is initialized to zero. 7.9. Global Pointer The Global Pointer identifies the applicable registration or measurement context. Its interpretation and allocation are defined by the registration mechanism. The Global Pointer is not secret. A protected PDMv2 implementation MUST NOT treat possession of a Global Pointer as proof of authorization. 7.10. Scale Fields and Delta Times ScaleDTLR specifies the scale applied to Delta Time Last Received. ScaleDTLS specifies the scale applied to Delta Time Last Sent. Delta Time Last Received and Delta Time Last Sent are 16-bit unsigned values interpreted using their respective scale fields. The existing scale and delta-time calculations inherited from the PDM model remain unchanged unless otherwise specified by this document. Elkins, et al. Expires 14 February 2027 [Page 15] Internet-Draft draft-ietf-ippm-encrypted-pdmv2 August 2026 7.11. Reserved Field The Reserved field is 16 bits. A sender MUST set the Reserved field to zero. A receiver MUST ignore a nonzero Reserved value for protocol processing but MAY record the condition as an anomaly. In the protected format, the Reserved field is part of the protected metric block. 7.12. Segmentation and Aggregation Offload PDMv2 can be implemented at a processing point preceding transmit segmentation or following receive aggregation. Consequently, the packets observed by a PDMv2 implementation do not necessarily have a one-to-one relationship with the IPv6 packets transmitted or received by a physical interface. When a packet carrying PDMv2 is divided into multiple packets by TCP Segmentation Offload, Generic Segmentation Offload, or an equivalent mechanism below the PDMv2 processing point, the resulting packets MAY carry identical PDMv2 field values, including the same PSNTP. Repeated PSNTP values resulting from such processing do not, by themselves, indicate packet loss, retransmission, malformed PDMv2 data, or nonconforming sender behavior. Similarly, Generic Receive Offload, Large Receive Offload, or another receive-side aggregation mechanism can combine multiple received packets before they become visible to a PDMv2 implementation. PDMv2 does not require an implementation to: * disable segmentation or aggregation offload; * inspect an outgoing interface's Maximum Transmission Unit solely for PDMv2 processing; * update a PDMv2 option separately in each packet produced below the PDMv2 processing point; or * reconstruct an exact one-to-one correspondence between PDMv2 observations and packets appearing on a physical interface. A measurement or reconstruction system observing repeated PSNTP values SHOULD use other available information, including TCP sequence-number ranges, payload lengths, timestamps, IPv6 Elkins, et al. Expires 14 February 2027 [Page 16] Internet-Draft draft-ietf-ippm-encrypted-pdmv2 August 2026 fragmentation information, and surrounding PDMv2 observations, to distinguish likely segmentation, duplication, retransmission, and reordering. If the available information is insufficient to distinguish among these conditions, the system SHOULD report the result as ambiguous. It MUST NOT classify a repeated PSNTP as a protocol error solely because the value was repeated. PDMv2 alone cannot always determine the exact number of IPv6 packets transmitted or received at a physical interface when segmentation or aggregation occurs outside the PDMv2 processing point. 7.13. Protected Options and Repeated PSNTP Values Multiple packets can contain the same protected PDMv2 value because of packet duplication or segmentation below the PDMv2 processing point. Replication of an already protected PDMv2 option is not a new invocation of the authenticated-encryption algorithm. Repetition of an identical ciphertext and authentication tag therefore does not, by itself, constitute cryptographic nonce reuse. A sender MUST NOT independently encrypt different PDMv2 plaintext values using the same SessionTemporaryKey and nonce. A receiver or analyzer MAY recognize identical protected values as repeated observations. It MUST authenticate a protected value before using its contents, regardless of whether an identical value was previously observed. 7.14. Receiver Validation and Exception Handling A receiver MUST validate the PDMv2 Option Type, Option Length, Version, and identified format before interpreting dependent PDMv2 fields. A receiver MUST treat a protected PDMv2 option as invalid for PDMv2 processing if: * authentication fails; * the indicated Epoch is unknown or expired; * the indicated Epoch cannot be mapped to an applicable security context; Elkins, et al. Expires 14 February 2027 [Page 17] Internet-Draft draft-ietf-ippm-encrypted-pdmv2 August 2026 * the required security context is unavailable; * the sender is not authorized by that security context; or * the option is malformed or inconsistent with its declared format. An invalid, unauthenticated, or unauthorized PDMv2 option MUST NOT be used for measurement, reconstruction, or updating PDMv2 state. Failure of a registration service or inability to obtain an applicable security context MUST fail closed with respect to protected PDMv2 content. The protected content MUST NOT be decrypted, interpreted, or used to update measurement state. Failure to process PDMv2 information does not, by itself, require discarding the enclosing IPv6 packet. Unless local security policy requires otherwise, failure to process PDMv2 information SHOULD NOT cause the receiver to discard the enclosing packet's upper-layer payload. The receiver MAY ignore the PDMv2 information and continue normal IPv6 processing, subject to the processing behavior encoded in the IPv6 Option Type action bits. A deployment MAY discard or block packets carrying invalid or unauthorized PDMv2 options when required by local security policy. Because such behavior can affect connectivity and can be exploited for denial of service, implementations SHOULD default to ignoring invalid PDMv2 measurement information rather than discarding the enclosing packet when the IPv6 Option Type action bits permit that behavior. An unsupported Version MUST be processed according to the action bits in the PDMv2 Option Type. The receiver MUST NOT interpret the remaining fields using the Version 2 format. Implementations SHOULD count, log, or alert on authentication failures, unknown or expired Epoch values, unavailable security contexts, unauthorized senders, malformed options, unsupported versions, and other anomalous PDMv2 conditions. Such reporting SHOULD be aggregated or rate-limited to prevent logging-based denial of service. Implementations SHOULD provide configurable policies for ignoring invalid PDMv2 data, generating an alert, discarding an enclosing packet, or blocking a source. The selected policy and its operational consequences are deployment-specific. 8. Operational Model Elkins, et al. Expires 14 February 2027 [Page 18] Internet-Draft draft-ietf-ippm-encrypted-pdmv2 August 2026 8.1. Registration Phase Prior to sending PDMv2 data: * The endpoint authenticates to an Authentication Server * Authorization for PDMv2 usage is evaluated * Shared secret(s) or credentials are provisioned 8.2. Measurement Phase * Endpoints send PDMv2 headers according to local policy * No cryptographic negotiation occurs on the wire * Intermediate devices forward packets unchanged 8.3. Analysis Phase * Authorized analyzers access collected data * Interpretation uses registration-derived context 9. Security Considerations This section follows the security-considerations guidance in [RFC3552]. PDMv2 carries measurement information that can expose operational characteristics of endpoints and networks. The protected format is intended to limit interpretation and modification of that information to entities possessing an applicable authorized security context. Section 7.14 defines the authoritative receiver behavior for malformed, unauthenticated, unauthorized, or otherwise unusable PDMv2 options. Such information MUST NOT be used for measurement, reconstruction, or updating PDMv2 state. This prevents forged or malformed PDMv2 data from contaminating measurement results. Authentication failure, an unknown or expired Epoch, inability to map an Epoch to a security context, an unavailable security context, or a sender that is not authorized by that context causes the protected PDMv2 information to be rejected for PDMv2 processing. Failure to obtain registration information therefore fails closed with respect to protected PDMv2 content. Elkins, et al. Expires 14 February 2027 [Page 19] Internet-Draft draft-ietf-ippm-encrypted-pdmv2 August 2026 The Epoch and Global Pointer fields are selectors used to locate applicable context. Neither field is secret material, and possession or knowledge of either value is not proof of authorization. The selected protection suite and registration mechanism MUST prevent reuse of the same key and nonce for independently protected different plaintext values, as specified in Section 7.5. Segmentation, duplication, or other processing below the PDMv2 processing point can copy an already protected PDMv2 option into more than one packet. As described in Section 7.13, repetition of identical ciphertext and authentication tag is not a new authenticated-encryption invocation and is distinct from independently encrypting different plaintexts using the same key and nonce. Packet-disposition policy requires care. Discarding an enclosing IPv6 packet solely because its PDMv2 information cannot be used can affect connectivity and can create a denial-of-service opportunity. Section 7.14 therefore recommends ignoring invalid PDMv2 measurement information when the IPv6 Option Type action bits and local security policy permit that behavior. Deployments can impose stricter policy when required. Diagnostics can themselves be abused. Authentication failures, malformed options, unknown or expired Epoch values, unavailable security contexts, unauthorized senders, and unsupported versions can be counted, logged, or alerted on, but reporting SHOULD be aggregated or rate-limited as specified in Section 7.14 to avoid a logging-based denial-of-service vector. The security of protected PDMv2 depends on the registration system, selected protection suite, authentication and authorization methods, key derivation or provisioning, key lifetime, rekey procedures, and revocation practices. Section 5.4 requires cryptographic separation of PDMv2 SessionTemporaryKey material from TLS, QUIC, IPsec, and other traffic keys. 10. Privacy Considerations PDMv2 metrics may reveal traffic patterns or operational characteristics. Registration-based authorization limits access to such data to approved entities. Deployments SHOULD consider enabling PDMv2 on multiple flows to reduce metadata distinguishability. 11. IANA Considerations Elkins, et al. Expires 14 February 2027 [Page 20] Internet-Draft draft-ietf-ippm-encrypted-pdmv2 August 2026 11.1. PDMv2 Destination Option IANA is requested to assign a new IPv6 Destination Option Type for PDMv2 from the "Destination Options and Hop-by-Hop Options" registry. +=======+==============================================+===========+ | Value | Description | Reference | +=======+==============================================+===========+ | TBD1 | Performance and Diagnostic Metrics Version 2 | This | | | | document | +-------+----------------------------------------------+-----------+ Table 3 The PDMv2 allocation is independent of the PDM Option Type 0x0F assigned to [RFC8250]. This document does not modify or redefine the [RFC8250] allocation. The requested allocation must provide the option-processing behavior specified by this document. The final hexadecimal representation, including the action and change-en-route bits, will be inserted when IANA assigns the value. 12. Contributors The authors wish to thank NITK Surathkal for their support and assistance in coding and review. In particular Dr. Mohit Tahiliani and Abhishek Kumar (now with Google). Thanks also to Priyanka Sinha for her comments. Thanks to the India Internet Engineering Society (iiesoc.in), in particular Dhruv Dhody, for his comments and for providing the funding for servers needed for protocol development. Thanks to Balajinaidu V, Amogh Umesh, and Chinmaya Sharma of NITK for developing the PDMv2 implementation for testing. 13. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . Elkins, et al. Expires 14 February 2027 [Page 21] Internet-Draft draft-ietf-ippm-encrypted-pdmv2 August 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 Performance and Diagnostic Metrics (PDM) Destination Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, . Appendix A. Example: RADIUS / EAP-Based Registration This appendix illustrates one possible registration mechanism that can meet the registration objectives listed in Section 5.1 and provide the security context described in Section 5.4. The example is informative. Conformance with this document depends on satisfying the applicable normative requirements in the main body and does not depend on using RADIUS or EAP. A.1. Overview This appendix describes an example registration system for PDMv2 based on RADIUS with Extensible Authentication Protocol (EAP). This approach has been implemented and validated in a prototype environment and demonstrates that a shared master secret can be established prior to PDMv2 operation without introducing inline cryptographic negotiation at the IP layer. RADIUS and EAP are widely deployed for Authentication, Authorization, and Accounting (AAA) in enterprise, service provider, and federated environments (e.g., eduroam). Their use here is illustrative and leverages existing infrastructure and operational experience. A.2. Participants The following entities participate in this example: * PDMv2 Endpoint A Client or Server that will emit or receive PDMv2 data. * Authentication Server (AS) Elkins, et al. Expires 14 February 2027 [Page 22] Internet-Draft draft-ietf-ippm-encrypted-pdmv2 August 2026 A RADIUS server that performs authentication and authorization using EAP. * Analyzer An authorized entity that may interpret or decrypt collected PDMv2 data using registration-derived context. An implementation MAY combine multiple roles within a single system. A.3. Registration Flow (Example) A typical registration flow proceeds as follows: * Secure Channel Establishment The PDMv2 endpoint establishes a secure exchange with the Authentication Server. In many deployments this occurs implicitly as part of an EAP method protected by TLS (e.g., EAP-TLS or PEAP). * Endpoint Authentication The endpoint authenticates using credentials appropriate to the deployment, such as certificates, credentials, tokens, or federated identity. * Authorization Decision The Authentication Server determines whether the endpoint is authorized to: - Send PDMv2 data - Receive PDMv2 data - Participate in specific measurement domains * Master Secret Establishment Upon successful authentication, EAP produces keying material (e.g., a Master Session Key). This keying material is made available to the endpoint and retained by the Authentication Server according to local policy. * Provisioning of Context The endpoint associates the received master secret with local PDMv2 policy, such as permitted peers, scope, and lifetime. * Analyzer Enablement (Optional) If offline analysis is required, the Authentication Server provisions appropriate authorization or keying context to approved analyzers. Elkins, et al. Expires 14 February 2027 [Page 23] Internet-Draft draft-ietf-ippm-encrypted-pdmv2 August 2026 A.4. Registration Flow (Illustrative ASCII Diagram) The following diagram illustrates the example flow. It is provided for clarity only and does not define protocol behavior. PDMv2 Endpoint Authentication Server Analyzer | | | |--- EAP Authentication -----> | | |<-- EAP Success / Keys ------ | | | | | | (Registration Complete) | | | | | |====== PDMv2 Data Flow =====> | (out of path) | | | | | |------- Authorized Access ---->| | |<------ Analysis Results ------| A.5. Use with PDMv2 Traffic After registration: * PDMv2 packets are sent without any inline authentication or negotiation. * Endpoints locally derive any session-specific context needed to protect or interpret PDMv2 metrics. * Intermediate routers forward packets without modification or inspection. * Analyzers use registration-derived context to interpret collected data. The registration system is not involved in the PDMv2 data path. A.6. Key Lifecycle Considerations In this example, the RADIUS/EAP infrastructure can support: * Periodic re-registration to refresh secrets * Revocation of authorization by disabling credentials * Federation across administrative domains * Separation of endpoint and analyzer privileges Elkins, et al. Expires 14 February 2027 [Page 24] Internet-Draft draft-ietf-ippm-encrypted-pdmv2 August 2026 The specific key derivation, transformation, and protection mechanisms used by this illustrative RADIUS/EAP example are outside the scope of this appendix. Such mechanisms are subject to the applicable normative requirements in Section 5.4 and to the selected registration mechanism or protection-suite specification. A.7. Example Deployment: Federated Environments (eduroam-Style) In federated environments such as global research and education networks, RADIUS is commonly deployed in a hierarchical or proxy- based architecture. An endpoint authenticates using credentials issued by its home organization, while authorization decisions may be enforced by visited or intermediate domains. This model maps naturally to PDMv2 registration: * Endpoints authenticate using existing institutional credentials * Authorization for PDMv2 usage can be scoped by domain, role, or policy * Registration secrets are derived without requiring bilateral agreements between all participating domains This example demonstrates that PDMv2 registration can scale across organizational and administrative boundaries. A.8. Why TLS Session Keys Are Not Reused (Informative) It may appear attractive to reuse TLS session keys for protecting PDMv2 metrics. However, this approach is not suitable for PDMv2 for several reasons: * Layering : PDMv2 operates at the IPv6 layer, while TLS is bound to transport-layer protocols such as TCP or QUIC. * Protocol Coverage : PDMv2 applies equally to UDP, ICMP, and other non-TLS-capable protocols. * Multiplicity of Flows : A single endpoint may emit PDMv2 data for multiple concurrent flows that do not share a common TLS session. * Analyzer Access : Offline analyzers may require access to PDMv2 data without participating in live TLS sessions. * Operational Simplicity : Registration decouples security establishment from traffic patterns and avoids inline negotiation complexity. Elkins, et al. Expires 14 February 2027 [Page 25] Internet-Draft draft-ietf-ippm-encrypted-pdmv2 August 2026 For these reasons, PDMv2 adopts a registration-based security model rather than reusing transport-layer session keys. A.9. Summary This appendix demonstrates that a RADIUS/EAP-based registration system can satisfy the registration objectives and applicable normative requirements defined in this document. The example shows that secure, scalable, and federated registration can be achieved using existing AAA infrastructure, without constraining PDMv2 to a specific authentication or cryptographic technology. Appendix B. Change Log Note to RFC Editor: if this document does not obsolete an existing RFC, please remove this appendix before publication as an RFC. Appendix C. Open Issues Note to RFC Editor: please remove this appendix before publication as an RFC. Authors' Addresses Nalini Elkins Inside Products, Inc. United States Email: nalini.elkins@insidethestack.com Michael Ackermann BCBS Michigan United States Email: mackermann@bcbsm.com Ameya Deshpande NITK Surathkal/Google India Email: ameyanrd@gmail.com Tommaso Pecorella University of Florence Italy Email: tommaso.pecorella@unifi.it Elkins, et al. Expires 14 February 2027 [Page 26] Internet-Draft draft-ietf-ippm-encrypted-pdmv2 August 2026 Adnan Rashid Politecnico di Bari Italy Email: adnan.rashid@poliba.it Lorenzo Fedi University of Florence Italy Email: lorenzo.fedi3@edu.unifi.it Elkins, et al. Expires 14 February 2027 [Page 27]