IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination Option
draft-ietf-ippm-encrypted-pdmv2-13

Internet Engineering Task Force                                N. Elkins
Internet-Draft                                     Inside Products, Inc.
Intended status: Standards Track                            M. Ackermann
Expires: 23 July 2026                                      BCBS Michigan
                                                            A. Deshpande
                                                   NITK Surathkal/Google
                                                            T. Pecorella
                                                  University of Florence
                                                               A. Rashid
                                                     Politecnico di Bari
                                                                 L. Fedi
                                                  University of Florence
                                                         19 January 2026

 IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination
                                 Option
                   draft-ietf-ippm-encrypted-pdmv2-13

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.  Cryptographic algorithms, key derivation
   functions, and cipher negotiation are explicitly out of scope.

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 23 July 2026                  [Page 1]
Internet-Draft       draft-ietf-ippm-encrypted-pdmv2        January 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 23 July 2026.

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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   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 . . . . . . . . . . . . . . . .   5

Elkins, et al.            Expires 23 July 2026                  [Page 2]
Internet-Draft       draft-ietf-ippm-encrypted-pdmv2        January 2026

     5.3.  Registration Transport  . . . . . . . . . . . . . . . . .   5
   6.  PDMv2 Destination Options . . . . . . . . . . . . . . . . . .   5
     6.1.  Use of IPv6 Destination Options . . . . . . . . . . . . .   6
     6.2.  Metrics . . . . . . . . . . . . . . . . . . . . . . . . .   6
     6.3.  Global Pointer  . . . . . . . . . . . . . . . . . . . . .   6
   7.  PDMv2 Header Format . . . . . . . . . . . . . . . . . . . . .   6
   8.  Operational Model . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Registration Phase  . . . . . . . . . . . . . . . . . . .   9
     8.2.  Measurement Phase . . . . . . . . . . . . . . . . . . . .   9
     8.3.  Analysis Phase  . . . . . . . . . . . . . . . . . . . . .   9
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   10. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  10
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   12. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  10
   13. Normative References  . . . . . . . . . . . . . . . . . . . .  10
   Appendix A.  Example: RADIUS / EAP-Based Registration . . . . . .  11
     A.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  11
     A.2.  Participants  . . . . . . . . . . . . . . . . . . . . . .  11
     A.3.  Registration Flow (Example) . . . . . . . . . . . . . . .  12
     A.4.  Registration Flow (Illustrative ASCII Diagram)  . . . . .  12
     A.5.  Use with PDMv2 Traffic  . . . . . . . . . . . . . . . . .  13
     A.6.  Key Lifecycle Considerations  . . . . . . . . . . . . . .  13
     A.7.  Example Deployment: Federated Environments
           (eduroam-Style) . . . . . . . . . . . . . . . . . . . . .  14
     A.8.  Why TLS Session Keys Are Not Reused (Informative) . . . .  14
     A.9.  Summary . . . . . . . . . . . . . . . . . . . . . . . . .  15
   Appendix B.  Change Log . . . . . . . . . . . . . . . . . . . . .  15
   Appendix C.  Open Issues  . . . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

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

Elkins, et al.            Expires 23 July 2026                  [Page 3]
Internet-Draft       draft-ietf-ippm-encrypted-pdmv2        January 2026

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

4.  PDMv2 Foundational Principles

   PDMv2 adheres to the following foundational principles:

   1.  Registration-First Security: All security context used by PDMv2
       is established during a prior registration phase.  No
       cryptographic negotiation occurs during PDMv2 packet exchange.

   2.  IP-Layer Independence: PDMv2 security does not depend on TCP,
       TLS, QUIC, or any specific transport protocol.

   3.  Minimal On-Path Impact: Routers and intermediate nodes forward
       PDMv2 packets without decryption or inspection.

   4.  Offline Decryption and Analysis: PDMv2 data MAY be collected and
       analyzed after transmission.  Real-time interpretation is
       optional and deployment-specific.

   5.  Separation of Specification Scope: This document defines protocol
       behavior and data formats, not cryptographic algorithms.

Elkins, et al.            Expires 23 July 2026                  [Page 4]
Internet-Draft       draft-ietf-ippm-encrypted-pdmv2        January 2026

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

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.

6.  PDMv2 Destination Options

Elkins, et al.            Expires 23 July 2026                  [Page 5]
Internet-Draft       draft-ietf-ippm-encrypted-pdmv2        January 2026

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

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 RFC 8250, 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 Header Format

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

Elkins, et al.            Expires 23 July 2026                  [Page 6]
Internet-Draft       draft-ietf-ippm-encrypted-pdmv2        January 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 Length | Version |        Epoch        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Packet Sequence Number (This)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Packet Sequence Number (Last)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Global Pointer                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  ScaleDTLR    |  ScaleDTLS    |           Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Delta Time Last Received    |    Delta Time Last Sent       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Option Type

      0x0F

      8-bit unsigned integer.  The Option Type is adopted from RFC 8250
      [RFC8250].

      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.

Elkins, et al.            Expires 23 July 2026                  [Page 7]
Internet-Draft       draft-ietf-ippm-encrypted-pdmv2        January 2026

      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 [RFC3552].

      Delta Time Last Received (DELTATLR)

Elkins, et al.            Expires 23 July 2026                  [Page 8]
Internet-Draft       draft-ietf-ippm-encrypted-pdmv2        January 2026

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

8.  Operational Model

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

   PDMv2 reduces exposure of sensitive operational metadata by ensuring
   that only registered and authorized entities can meaningfully
   interpret measurement data.

Elkins, et al.            Expires 23 July 2026                  [Page 9]
Internet-Draft       draft-ietf-ippm-encrypted-pdmv2        January 2026

   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

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

   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.

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,
              <https://www.rfc-editor.org/rfc/rfc2119>.

Elkins, et al.            Expires 23 July 2026                 [Page 10]
Internet-Draft       draft-ietf-ippm-encrypted-pdmv2        January 2026

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              DOI 10.17487/RFC3552, July 2003,
              <https://www.rfc-editor.org/rfc/rfc3552>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8250]  Elkins, N., Hamilton, R., and M. Ackermann, "IPv6
              Performance and Diagnostic Metrics (PDM) Destination
              Option", RFC 8250, DOI 10.17487/RFC8250, September 2017,
              <https://www.rfc-editor.org/rfc/rfc8250>.

Appendix A.  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.

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)

   A RADIUS server that performs authentication and authorization using
   EAP.

   *  Analyzer

Elkins, et al.            Expires 23 July 2026                 [Page 11]
Internet-Draft       draft-ietf-ippm-encrypted-pdmv2        January 2026

   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.

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.

Elkins, et al.            Expires 23 July 2026                 [Page 12]
Internet-Draft       draft-ietf-ippm-encrypted-pdmv2        January 2026

  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

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

Elkins, et al.            Expires 23 July 2026                 [Page 13]
Internet-Draft       draft-ietf-ippm-encrypted-pdmv2        January 2026

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.

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

Elkins, et al.            Expires 23 July 2026                 [Page 14]
Internet-Draft       draft-ietf-ippm-encrypted-pdmv2        January 2026

A.9.  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.

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

   Adnan Rashid
   Politecnico di Bari
   Italy

Elkins, et al.            Expires 23 July 2026                 [Page 15]
Internet-Draft       draft-ietf-ippm-encrypted-pdmv2        January 2026

   Email: adnan.rashid@poliba.it

   Lorenzo Fedi
   University of Florence
   Italy
   Email: lorenzo.fedi3@edu.unifi.it

Elkins, et al.            Expires 23 July 2026                 [Page 16]