[Int-dir] Re: [ippm] Re: draft-ietf-ippm-encrypted-pdmv2-14 early Intdir review

["[e-mail]" <[e-mail]>]

Hi Tommy,

Thank you again for your INT Area review of draft-ietf-ippm-encrypted-pdmv2. Your review was based on draft-14. We have now submitted draft-16.

Draft-15 addressed the primary protocol-format and receiver-processing issues you identified, including:
   
   -    
PDMv2 now requests a new IPv6 Destination Option Type and explicitly does not reuse the RFC 8250 Option Type 0x0F.

   -    
The unprotected and protected formats are separately and explicitly defined, with Option Length values of 22 and 38 respectively.

   -    
The Option Length itself distinguishes the unprotected and protected formats; a receiver does not need registration context merely to determine the format.

   -    
Section 7 was substantially expanded to specify field semantics and normative receiver validation and exception handling.

   -    
The document now explicitly addresses segmentation and aggregation offload and repeated PDMv2 observations.


Draft-16 addresses the remaining operational and privacy points from your review.

In Section 6.1, we now explicitly state that PDMv2 does not define new IPv6 extension-header ordering requirements and follows the Destination Options placement and processing rules in RFC 8200. We also clarify that IPv6 fragmentation and reassembly follow the existing RFC 8200 rules; PDMv2 does not introduce different fragmentation or reassembly behavior. Fragmentation information may, however, be useful to an authorized reconstruction system along with other packet observations.

We also added operational text noting the additional size of PDMv2 relative to RFC 8250: the complete unprotected option is 24 octets and the protected option is 40 octets. The text notes both the resulting packet overhead and the operational reality that some paths may filter or otherwise treat IPv6 extension headers or Destination Options differently.

Finally, we expanded the Privacy Considerations to address your question about the Global Pointer and IPv6 privacy-address rotation.

The new text explicitly recognizes that a Global Pointer that remains the same across an IPv6 privacy-address change can provide a means of correlating observations associated with the old and new addresses. It also points out that changing the Global Pointer alone does not guarantee unlinkability. An authorized after-the-fact analyzer may have other information available for correlation, including Layer 2 interface information, the IPv6 prefix, timing information, and observed privacy-address-change patterns.

For deployments that specifically wish to reduce correlation based on the Global Pointer, draft-16 allows an implementation or registration policy to define a Global Pointer lifetime and assign a new value when that lifetime expires. Such a lifetime may take address-rotation or other privacy policies into account. We deliberately did not mandate that the Global Pointer lifetime be tied to the IPv6 privacy-address lifetime, since rotating the Global Pointer does not by itself prevent correlation through other information.

We believe draft-16 now addresses the issues raised in your review. We appreciate the review — it resulted in substantially clearer specification of the wire formats, receiver behavior, IPv6 operational considerations, and privacy implications.

Thanks,
Nalini Elkins
Chief Technology OfficerOutside the Stacks, Inc.https://www.outsidethestacks.com

Chief Operating OfficerIndustry Network Technology Councilhttps://www.industrynetcouncil.org 

    On Sunday, August 16, 2026 at 07:20:10 AM GMT-8, [e-mail] <[e-mail]> wrote:  
 
 
Hi Tommy,

Thank you for the detailed review. Your review was against draft-14. We have since published draft-15, and a number of the changes in -15 were made to address the issues you raised.

Below is a point-by-point summary.

1. IPv6 Option Type / IANA registration

You noted an inconsistency between Section 7 appearing to reuse the RFC 8250 Option Type (0x0F) and the IANA section requesting a new allocation.

This has been corrected in draft-15.

Section 7 now explicitly states that PDMv2 uses a new PDMv2 Option Type assigned by IANA and does not reuse the RFC 8250 PDM Option Type 0x0F:


PDMv2 does not reuse the PDM Option Type 0x0F assigned by RFC 8250.


Section 7.3 similarly specifies the PDMv2 Option Type as TBD1 and states that it is distinct from 0x0F.

Section 11.1 requests a new IPv6 Destination Option Type from IANA and explicitly states that the allocation is independent of the RFC 8250 allocation.

Thus, PDM and PDMv2 have separate IPv6 Option Types.

2. Option Length

The confusing 0x22 text from draft-14 has been removed and the two wire formats are now specified separately in Sections 7.1 and 7.2.

The unprotected format has:
   
   -    
Option Length = 22 decimal (0x16)

   -    
Total PDMv2 option size = 24 octets


The protected format has:
   
   -    
Option Length = 38 decimal (0x26)

   -    
Total PDMv2 option size = 40 octets


Both sections explicitly state that Option Length excludes the Option Type and Option Length octets, following the IPv6 option convention.

The document also now contains field/offset tables for both formats.

Since PDMv2 has its own newly allocated Option Type rather than reusing RFC 8250's 0x0F, there is no ambiguity with the RFC 8250 requirement that its PDM option have a length of 10.

3. Distinguishing protected and unprotected PDMv2

This is now explicitly defined.

Section 7 states that the Option Length identifies the wire format. A receiver can therefore determine whether the PDMv2 metric block is protected directly from the option:
   
   -    
Length 22 identifies the unprotected format.

   -    
Length 38 identifies the protected format.


The document also now states normatively:


An implementation MUST NOT determine whether a received PDMv2 option is protected solely from local policy or registration context.


Registration context is therefore needed to decrypt and interpret protected data, but not to determine which PDMv2 wire format was received.

4. More detailed sender/receiver processing and normative language

Section 7 has been substantially expanded in draft-15.

Rather than only presenting a header diagram, it now contains separate subsections defining:
   
   -    
unprotected and protected wire formats;

   -    
Option Type;

   -    
Version;

   -    
Epoch;

   -    
PDMv2 flow identification;

   -    
PSNTP;

   -    
PSNLR;

   -    
Global Pointer;

   -    
scale fields and delta times;

   -    
Reserved-field processing;

   -    
segmentation and aggregation behavior;

   -    
protected options and repeated PSNTP values; and

   -    
receiver validation and exception handling.


In particular, Section 7.14 now provides normative receiver behavior. A receiver MUST validate the Option Type, Option Length, Version, and identified format before interpreting dependent fields.

For protected PDMv2, authentication failure, unknown or expired Epoch values, inability to identify an applicable security context, unavailable context, unauthorized senders, and malformed/inconsistent formats all cause the PDMv2 information to be rejected for PDMv2 processing.

Invalid, unauthenticated, or unauthorized PDMv2 information MUST NOT be used for measurement, reconstruction, or updating PDMv2 state.

The section also distinguishes failure to process the PDMv2 option from disposition of the enclosing IPv6 packet, including guidance intended to avoid turning PDMv2 validation failures into a denial-of-service mechanism.

5. Interaction with packet processing / segmentation

Draft-15 adds Section 7.12, "Segmentation and Aggregation Offload."

This clarifies that the PDMv2 processing point does not necessarily have a one-to-one relationship with packets appearing on a physical interface. In particular, segmentation below the PDMv2 processing point can produce multiple packets containing identical PDMv2 values, including identical PSNTP values.

The document therefore does not require implementations to disable segmentation/aggregation offload, inspect the outgoing MTU solely for PDMv2, or attempt to update PDMv2 separately in packets generated below the PDMv2 processing point.

Instead, reconstruction systems are expected to use other available evidence — including TCP sequence ranges, payload lengths, timestamps, IPv6 fragmentation information, and surrounding PDMv2 observations — when distinguishing segmentation, duplication, retransmission, and reordering. Where the evidence is insufficient, the result is reported as ambiguous rather than treating repeated PDMv2 values as a protocol error.

Section 7.13 also clarifies the cryptographic implications when an already-protected PDMv2 option is replicated by lower-layer processing.

6. IPv6 Destination Options and fragmentation

Section 6.1 continues to specify PDMv2 as an IPv6 Destination Option carried in the Destination Options Header under RFC 8200, with the applicable RFC 8250 processing model retained except where this document updates it.

Draft-15 also discusses IPv6 fragmentation information in the reconstruction guidance in Section 7.12.

We are reviewing whether additional explicit text about extension-header ordering and IPv6 fragmentation would be useful here, particularly to make clear that PDMv2 does not define a new extension-header ordering rule beyond the IPv6 rules.

7. Operational impact of the larger option

The wire-size issue is now explicit: draft-15 gives the complete size of both formats (24 octets unprotected and 40 octets protected), rather than leaving the size implicit in the diagrams.

The operational model also assumes policy-controlled deployment and prior registration/authorization rather than universal deployment. Intermediate devices are not required to decrypt or interpret PDMv2.

We agree that the larger protected option is an operational consideration, particularly in networks that filter or otherwise treat IPv6 extension headers differently.

8. Global Pointer and IPv6 privacy-address rotation

Draft-15 now clarifies in Section 7.9 that the Global Pointer identifies an applicable registration or measurement context, that its interpretation and allocation are defined by the registration mechanism, and that the Global Pointer is not secret or evidence of authorization.

Your specific point about IPv6 privacy-address rotation is useful, however. In particular, a Global Pointer that remains stable while an endpoint changes IPv6 privacy addresses could itself provide a correlation identifier.

We believe this deserves an explicit statement in the Privacy Considerations rather than relying on the more general privacy discussion, and we plan to clarify that relationship.

Thank you again for the review. The comments were helpful in identifying places where draft-14 relied too much on implied behavior. Draft-15 is considerably more explicit about the PDMv2 wire formats, format identification, field semantics, and receiver processing as a result.
Thanks,
Nalini ElkinsChief Technology OfficerOutside the Stacks, Inc.https://www.outsidethestacks.com

Chief Operating OfficerIndustry Network Technology Councilhttps://www.industrynetcouncil.org 

    On Tuesday, August 11, 2026 at 09:26:52 PM GMT-8, Tommy Pauly via Datatracker <[e-mail]> wrote:  
 
 Document: draft-ietf-ippm-encrypted-pdmv2
Title: IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination
Option Reviewer: Tommy Pauly Review result: Not Ready

Thanks for providing the document for early review. From the perspective of an
INT Area review, I don't see too many issues around typical concerns there, but
I do think the document overall seems to be short on details and specificity,
and has some confusing aspects that would make it difficult to correctly and
consistently implement and deploy the IPv6 option. As such, I think those
aspects need to be addressed before progressing the document further.

Issues:

- IPv6 option IANA registration. The text in Section 11 requests the allocation
of a new option type, while Section 7 indicates that it uses the type already
registered in RFC 8250. Which is correct?

- Option length. The text in Section 7 is unclear to me, as it says:

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.

What is the significance of the two lines that both indicate 0x22? Can there be
some more prose to explain what is meant? Also, if this uses the same option
type as RFC 8250, which mandates that the length MUST be 10, what is the
expected interop behavior if this length is different?

- Is there some way that receivers are expected to be able to distinguish
between unencrypted and encrypted PDM?

Overall, I find the description in Section 7 (and much of the rest of the
document) to be lacking in detail. There should be more prose, probably more
normative language, and description about how implementations fill out the
fields and how receivers validate and parse the fields.

It would also be good to cover how this option interacts with others — are
there requirements about where this option appears in the packet relative to
other extension headers? How does this option interact with IPv6 fragmentation?
Given that this option is larger than the one in RFC 8250, there should also be
some operational discussion about the possibility of the option being dropped
(although this is likely mitigated if this option is only used in particularly
controlled scenarios).

The privacy considerations should likely include some mention of the Global
Pointer and how it relates to address rotations. If hosts are rotating privacy
addresses, does the Global Pointer change? If not, does that create correlation?


_______________________________________________
ippm mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]
  _______________________________________________
ippm mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]