]> Inside Products, Inc.

United States nalini.elkins@insidethestack.com

BCBS Michigan

United States mackermann@bcbsm.com

NITK Surathkal/Google

India ameyanrd@gmail.com

University of Florence

Italy tommaso.pecorella@unifi.it

Politecnico di Bari

Italy adnan.rashid@poliba.it

University of Florence

Italy lorenzo.fedi3@edu.unifi.it

Transport Internet Engineering Task Force Extension Headers IPv6 PDMv2 Performance Diagnostic 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. Cryptographic algorithms, key derivation functions, and cipher negotiation are explicitly out of scope. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the IP Performance Measurement Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The Performance and Diagnostic Metrics (PDM) Destination Option defined in RFC 8250 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.

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

Design Goals PDMv2 is designed with the following goals:

• Maintain compatibility with the operational model of RFC 8250
• 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

PDMv2 Foundational Principles PDMv2 adheres to the following foundational principles:

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

Registration Framework Overview PDMv2 relies on an external registration system to establish trust and shared context between participating entities.

Registration Objectives A registration system used with PDMv2 MUST:

• Authenticate participating entities
• Authorize PDMv2 usage
• Establish one or more shared secrets or credentials
• Enable analyzers to interpret PDMv2 data
• Support revocation and lifecycle management

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.

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.

PDMv2 Destination Options

Use of IPv6 Destination Options PDMv2 is carried as an IPv6 Destination Option within the Destination Options Header as defined in RFC 8200. Processing rules from RFC 8250 continue to apply unless explicitly updated by this document.

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 RFC 8250, with the addition of the Global Pointer.

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.

PDMv2 Header Format PDMv2 uses a single header format. Whether metric contents are protected or unprotected is determined by local policy and registration context.

Option Type

0x0F 8-bit unsigned integer. The Option Type is adopted from RFC 8250 .

Option Length

0x22: Unencrypted PDM 0x22: Encrypted PDM 8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields.

Version Number

0x2 4-bit unsigned number.

Epoch

12-bit unsigned number. Epoch field is used to indicate the valid SessionTemporaryKey.

Packet Sequence Number This Packet (PSNTP)

32-bit unsigned number. This field is initialized at a random number and is incremented sequentially for each packet of the 5-tuple. This field + Epoch are used in the Encrypted PDMv2 as the encryption nonce. The nonce MUST NOT be reused in different sessions.

Packet Sequence Number Last Received (PSNLR)

32-bit unsigned number. This field is the PSNTP of the last received packet on the 5-tuple.

Global Pointer

32-bit unsigned number. Global Pointer is initialized to 1 for the different source address types and incremented sequentially for each packet with the corresponding source address type. This field stores the Global Pointer type corresponding to the SADDR type of the packet.

Scale Delta Time Last Received (SCALEDTLR)

8-bit unsigned number. This is the scaling value for the Delta Time Last Sent (DELTATLS) field.

Scale Delta Time Last Sent (SCALEDTLS)

8-bit unsigned number. This is the scaling value for the Delta Time Last Sent (DELTATLS) field.

Reserved Bits

16-bits. Reserved bits for future use. They MUST be set to zero on transmission and ignored on receipt per .

Delta Time Last Received (DELTATLR)

16-bit unsigned integer. The value is set according to the scale in SCALEDTLR. Delta Time Last Received = (send time packet n - receive time packet (n - 1))

Delta Time Last Sent (DELTATLS)

16-bit unsigned integer. The value is set according to the scale in SCALEDTLS. Delta Time Last Sent = (receive time packet n - send time packet (n - 1))

Operational Model

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

Measurement Phase

• Endpoints send PDMv2 headers according to local policy
• No cryptographic negotiation occurs on the wire
• Intermediate devices forward packets unchanged

Analysis Phase

• Authorized analyzers access collected data
• Interpretation uses registration-derived context

Security Considerations PDMv2 reduces exposure of sensitive operational metadata by ensuring that only registered and authorized entities can meaningfully interpret measurement data. This document intentionally does not specify cryptographic mechanisms. Security strength therefore depends on the chosen registration system, its authentication methods, and its key management practices. Implementations SHOULD support:

• Forward Secracy
• Logging of anomalous PDMv2 behavior

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.

IANA Considerations This document requests the allocation of a new IPv6 Destination Options Header Option Type from the "Destination Options and Hop-by- Hop Options" registry maintained by the Internet Assigned Numbers Authority. The requested allocation is for the Performance and Diagnostic Metrics Version 2 (PDMv2) option. This option is distinct from and independent of the Performance and Diagnostic Metrics option defined in RFC 8250.

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.

Normative References All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. To assess performance problems, this document describes optional headers embedded in each packet that provide sequence numbers and timing information as a basis for measurements. Such measurements may be interpreted in real time or after the fact. This document specifies the Performance and Diagnostic Metrics (PDM) Destination Options header. The field limits, calculations, and usage in measurement of PDM are included in this document. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

Example: RADIUS / EAP-Based Registration This appendix illustrates one possible registration mechanism that satisfies the requirements defined in Section 4. Other mechanisms may be used.

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.

Participants The following entities participate in this example:

• PDMv2 Endpoint A Client or Server that will emit or receive PDMv2 data.
• Authentication Server (AS) 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.

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.

Registration Flow (Illustrative ASCII Diagram) The following diagram illustrates the example flow. It is provided for clarity only and does not define protocol behavior. | | |<-- EAP Success / Keys ------ | | | | | | (Registration Complete) | | | | | |====== PDMv2 Data Flow =====> | (out of path) | | | | | |------- Authorized Access ---->| | |<------ Analysis Results ------| ]]>

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.

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

Specific key derivation, transformation, or protection mechanisms are implementation-specific and intentionally outside the scope of this document.

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.

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.

For these reasons, PDMv2 adopts a registration-based security model rather than reusing transport-layer session keys.

Summary This appendix demonstrates that a RADIUS/EAP-based registration system can satisfy the PDMv2 registration 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.

Change Log Note to RFC Editor: if this document does not obsolete an existing RFC, please remove this appendix before publication as an RFC.

Open Issues Note to RFC Editor: please remove this appendix before publication as an RFC.