rfc-8250

IPv6 Performance and Diagnostic Metrics (PDM) Destination Option

N. Elkins, R. Hamilton, M. Ackermann
date2017-09 streamIETF areaops wgippm statusPROPOSED STANDARD pages30 canonicalhttps://www.rfc-editor.org/rfc/rfc8250 doi10.17487/RFC8250 errataview
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.

Extracted elements (24)

design-rationale §1.2

PDM does not require time synchronization between session partners because only time differentials (deltas) computed locally are placed in packets. Each host uses its own clock exclusively, and round-trip delay is derived by arithmetic combination of the deltas, not by comparing absolute timestamps across hosts.

ip, measurement

design-rationale §3.2.2

The base time unit for PDM is 1 attosecond (10^-18 seconds), chosen as a common unit enabling uniform scaling across all hardware timer resolutions from picoseconds to seconds. The 16-bit delta plus 8-bit scale encoding can represent time differentials from 1 attosecond up to over 3×10^55 years without time synchronization between endpoints.

ip, measurement

design-rationale §3.5.1

This specification recommends having PDM off by default to minimize unintended exposure of timing metadata. PDM activation should be explicit and configurable per protocol, port, or IP address, giving operators fine-grained control over measurement scope.

ip, measurement, security

interoperability-note §1.3

IPv6 transition technologies (e.g., IPv6-to-IPv4 translation) that do not recognize or support the IPv6 Destination Options extension header may drop packets containing PDM rather than translating them. Some middleboxes may also drop packets when the PDM header pushes Layer 4 information beyond the depth of their filtering logic.

ip, v6ops

normative-requirement §4.1 SHOULD

A limit on memory used for PDM control blocks SHOULD be implemented. Without a memory limit, an attacker can misuse control blocks to cause excessive resource consumption.

ip, security

normative-requirement §4.4 SHOULD

An implementation SHOULD require an explicit restart of PDM monitoring after a certain time period (e.g., after 1 hour) to ensure PDM is not accidentally left on after debugging. Additionally, user 'Consent to be Measured' SHOULD be a prerequisite for using PDM.

ip, measurement, security, privacy

normative-requirement §3.3 MUST NOT

For each IPv6 packet header, PDM MUST NOT appear more than once. An encapsulated packet MAY contain a separate PDM associated with each encapsulated IPv6 header.

ip

normative-requirement §3.4.1 MUST

If using PDM in ESP transport mode, PDM MUST be placed after the ESP header so as not to leak information.

ip, ipsec, security

normative-requirement §3.4 SHOULD

In the ESP case, the Security Parameter Index (SPI) numbers SHOULD be ignored when considering the flow over which PDM information is measured; the flow should be identified only by SADDR, DADDR, and PROTC.

ip, ipsec, measurement

normative-requirement §3.2.1 MUST

Operating systems MUST implement a separate packet sequence number counter per 5-tuple (SADDR, SPORT, DADDR, DPORT, PROTC). PSNTP is initialized at a random number to make spoofing harder and incremented monotonically for each packet of the session flow.

ip, measurement, security

normative-requirement §3.5.1 MUST NOT

PDM MUST NOT be turned on merely because a packet is received with a PDM header, as the received packet could be spoofed by another device.

ip, security

normative-requirement §3.2.1 MUST

The Option Length field MUST be set to 10 (octets, excluding Option Type and Option Length fields).

ip, measurement

normative-requirement §3.5.2 SHOULD

The position where PDM timestamps are taken SHOULD be as close to the physical network interface as possible to minimize attribution of host processing time to network latency.

ip, measurement

normative-requirement §3.2.1 MUST

The two high-order bits of the PDM Option Type field MUST be set to 00, indicating that nodes that do not recognize this option should skip and continue processing. The third high-order bit MUST be 0, indicating the Option Data does not change en route.

ip

protocol-element §3.2.1

DELTATLR (Delta Time Last Received) is a 16-bit unsigned integer representing the server delay: the time difference between when the sender sends the current packet and when it received the previous packet (send time packet n minus receive time packet n-1). Its scale is given by SCALEDTLR.

ip, measurement

protocol-element §3.2.1

DELTATLS (Delta Time Last Sent) is a 16-bit unsigned integer representing the elapsed time from when the last packet was sent to when the current packet is sent (receive time packet n minus send time packet n-1). Its scale is given by SCALEDTLS. Used to derive round-trip delay when combined with DELTATLR.

ip, measurement

protocol-element §3.2.1

PSNLR (Packet Sequence Number Last Received) is a 16-bit unsigned integer initialized to 0. It carries the PSNTP value of the last packet received on the 5-tuple, enabling the receiver to correlate DELTATLR with the specific packet it received.

ip, measurement

protocol-element §3.2.1

PSNTP (Packet Sequence Number This Packet) is a 16-bit unsigned integer initialized to a random number and incremented monotonically per session 5-tuple. It wraps and is intended for use while analyzing packet traces to correlate packets across observation points.

ip, measurement

protocol-element §3.2.1

SCALEDTLR and SCALEDTLS are 8-bit unsigned integers (range 0–255) that store the number of low-order bits truncated from the respective 64-bit attosecond time-differential value to fit it into the 16-bit delta field. The actual time differential is: delta_value * 2^scale attoseconds.

ip, measurement

registry §5

IANA registered Destination Option Type 0x0F in the 'Destination Options and Hop-by-Hop Options' sub-registry of 'Internet Protocol Version 6 (IPv6) Parameters', with act bits 00 and chg bit 0, assigned to the Performance and Diagnostic Metrics (PDM) destination option.

ip, registry

security-consideration §4.4

PDM can enable timing attacks against cryptographic protocols: an attacker observing PDM-separated processing times may be able to extract keying material by correlating fine-grained server latency with cryptographic operations. PDM should be restricted to specific addresses or ports to limit this exposure.

ip, security, crypto, measurement

security-consideration §4.3

PDM fields (sequence numbers and delta times) could be misused as a covert channel by a compromised end host. A PDM-aware middlebox or destination host detecting nonsensical sequence numbers or timing values could take action to block, discard, or alert on such traffic.

ip, security

security-consideration §4.2

PDM timing data passes in the clear and can be used to fingerprint end hosts (e.g., inferring device speed from delta patterns) or potentially to infer the type of application in use by correlating server processing time with payload length. Encryption algorithms may wish to obfuscate server time in addition to packet length.

ip, security, privacy, measurement

wire-format §3.2.1

The PDM destination option is encoded in TLV format as a 12-byte structure: 1-byte Option Type (0x0F), 1-byte Option Length (must be 10), 1-byte ScaleDTLR, 1-byte ScaleDTLS, 2-byte PSNTP, 2-byte PSNLR, 2-byte DELTATLR, and 2-byte DELTATLS. Multi-octet values are aligned on natural boundaries per RFC 8200.

ip, measurement