Operations, Administration, and Maintenance (OAM) in Segment Routing over IPv6 (SRv6)
Extracted elements (20)
The centralized monitoring approach extends RFC 8403 (MPLS centralized OAM) to SRv6 by using loopback probes that originate and terminate at the controller node (N100), allowing the controller to monitor arbitrary SRv6 paths without deploying OAM at every intermediate node.
The O-flag is designed as a per-packet marking mechanism (not in-band recording like IOAM per RFC 9197) so that telemetry data is exported out-of-band to an OAM process, avoiding the need to record OAM data in the forwarded packet itself. This enables controllable and predictable flow sampling without modifying packet payload.
If the penultimate segment of a segment list is a PSP SID, telemetry data from the ultimate segment cannot be requested, because the SRH (and thus the O-flag) is removed at the penultimate node before the ultimate segment processes the packet.
Non-SRv6-capable nodes process traceroute probes using standard IPv6 forwarding and generate ICMPv6 'Time Exceeded' responses that include the SRH contents (up to minimum IPv6 MTU), allowing the ingress node to display segment list information even through non-SRv6-capable hops.
Ping to an End.X SID only validates that the SID is locally programmed at the target node and does not validate switching to the correct outgoing interface. To exercise the full behavior of a SID, the OAM probe should be constructed similarly to a data packet exercising that SID behavior.
An SR domain ingress edge node MAY use the O-flag in the SRH to mark packets to trigger telemetry data collection and export at segment endpoints. Based on local configuration, it may implement a classification and sampling mechanism.
Implementation of the O-flag is OPTIONAL. If a node does not support the O-flag, it simply ignores it upon reception. If a node supports the O-flag, it can optionally advertise this capability via control plane protocols.
The OAM process MUST NOT process the copy of the packet or respond to any Upper-Layer header (like ICMP, UDP, etc.) payload, in order to prevent multiple evaluations of the datagram.
The OAM process SHOULD NOT be topologically distant from the routing node, as a distant OAM process is likely to create significant security and congestion issues.
The processing node MUST rate-limit the number of packets punted to the OAM process to a configurable rate. Failure to implement rate limiting can lead to a denial-of-service attack.
The per-packet marking capabilities of the O-flag provide a granular mechanism for telemetry collection. When deployed without user knowledge or consent, this mechanism provides an explicit protocol-level tool for surveillance and pervasive monitoring contrary to users' interests.
Centralized SRv6 path monitoring uses loopback probes: the controller (N100) advertises an End SID and generates probes with the controller's End SID as the final segment, so probes traverse the monitored path and return to the controller for continuity checking, delay measurement, and loss detection.
IPv6 OAM operations (ping and traceroute) can be performed for any SRv6 SID whose behavior allows Upper-Layer header processing for applicable OAM payloads (e.g., ICMP, UDP). The target SID may be placed in the IPv6 destination address without an SRH or as the last segment in an SRH.
The O-flag (OAM flag) is defined as bit 2 in the 8-bit Flags field of the Segment Routing Header (SRH). It is used as a marking bit in user packets to trigger telemetry data collection and export at segment endpoints.
IANA registered bit 2 as the O-flag (OAM flag) in the 'Segment Routing Header Flags' subregistry within the 'Internet Protocol Version 6 (IPv6) Parameters' registry, with reference to RFC 9259.
An on-path attacker able to observe the OAM channel carrying exported packets marked by the O-flag could conduct traffic analysis or eavesdropping on telemetry for the entire SR domain. The security properties of the OAM export channel depend on the specific OAM processes deployed.
OAM procedures described in this document are restricted to an SR domain. O-flag manipulation (like SID manipulation) is not considered a threat within the SR domain; procedures for securing an SR domain are defined in Sections 5.1 and 7 of RFC 8754.
The O-flag may be set by an attacking node within the SR domain to mount a denial-of-service attack on the OAM process at a segment endpoint. Correct implementation of rate limiting (Section 2.1.1) mitigates this attack. SRH flags including the O-flag are also protected by the HMAC TLV as defined in Section 2.1.2.1 of RFC 8754.
When a node receives a packet destined to local SID S with the O-flag set and local configuration permits O-flag processing (step S01.1): (a) make a copy of the packet, (b) send the copy with a timestamp to the OAM process. O-flag processing occurs before regular SID processing (inserted between lines S01 and S02 of RFC 8754 pseudocode).
The O-flag occupies bit position 2 (0-indexed from the left) in the 8-bit SRH Flags field as defined in RFC 8754. The field layout is: bits 0-1 unused, bit 2 is O-flag, bits 3-7 unused.