Skip to content

RFC 9259 - Operations and Management of SRv6

Field Value
Title Operations, Administration, and Maintenance (OAM) in Segment Routing over IPv6 (SRv6)
Authors Z. Ali, C. Filsfils, S. Matsushima, D. Voyer, M. Chen
Date June 2022
Status Proposed Standard
Link datatracker.ietf.org/doc/rfc9259

Summary

RFC 9259 defines the OAM mechanisms for SRv6 networks. It specifies how existing OAM tools (ping, traceroute) work in an SRv6 environment and defines new SRv6-specific OAM behaviors.

Key Concepts

SRv6 OAM Behaviors

Behavior Description
End.OP OAM endpoint - punt packet to control plane for OAM processing
End.OTP OAM endpoint with timestamp - adds timestamp before punting

Ping in SRv6

SRv6 ping uses ICMPv6 Echo Request/Reply with the SRH to verify reachability along an SRv6 path. The ping follows the segment list, allowing operators to verify end-to-end SRv6 connectivity.

Traceroute in SRv6

SRv6 traceroute works by incrementing the IPv6 Hop Limit to discover each hop along the SRv6 path. Each intermediate node returns an ICMPv6 Time Exceeded message, revealing the path taken.

Key Differences from Traditional OAM

  • OAM packets carry the SRH to follow the same path as data traffic
  • Intermediate nodes may or may not be SRv6-aware
  • SRv6 OAM can validate both the underlay path and the overlay service

Key Sections

Section Topic Description
3 OAM Flag in SRH Defines the O-flag (bit 0) in the SRH Flags field; when set, it indicates the packet is an OAM packet that should be processed by the OAM mechanism at each SRv6-capable node
4 SRv6 OAM Endpoint Behaviors Specifies End.OP (OAM punt) and End.OTP (OAM with Timestamp) endpoint behaviors for OAM processing
5 SRv6 Ping ICMPv6 Echo Request/Reply procedures for SRv6; the source constructs the ping packet with an SRH containing the target segment list
5.1 Ping to a SID Ping a specific SRv6 SID by placing it as the final segment; verifies SID reachability
5.2 Ping to a Policy Ping using the full segment list of an SR Policy; verifies end-to-end path connectivity
6 SRv6 Traceroute Hop-by-hop discovery using incrementing IPv6 Hop Limit with SRH; each hop returns ICMPv6 Time Exceeded
6.1 Traceroute to a SID Discovers the path to a specific SRv6 SID
6.2 Traceroute to a Policy Discovers all hops along an SR Policy path
7 Security Considerations Rate limiting, trust boundaries, and filtering of OAM packets

OAM Flag Detail

The O-flag (Bit 0 in the SRH Flags field) marks a packet as an OAM packet:

SRH Flags:
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|O|    Unused   |
+-+-+-+-+-+-+-+-+

When the O-flag is set, an SR endpoint node may choose to process the packet as OAM (e.g., punt to control plane) rather than forwarding it in the data plane.

Common Pitfalls

Rate limiting ICMPv6 is critical. SRv6 OAM relies on ICMPv6 Echo and Time Exceeded messages. Without proper rate limiting, OAM traffic can be used for denial-of-service attacks or can overwhelm the control plane of transit and endpoint nodes. Implementations must apply ICMPv6 rate limiting consistent with RFC 4443.

Transit nodes may not respond to traceroute. In SRv6, transit nodes (non-segment-endpoint routers between SRv6 nodes) forward packets based only on the IPv6 DA. They do not process the SRH and may not generate ICMPv6 Time Exceeded messages that include the SRH. This means traceroute output may show transit hops but without SRv6-specific context. Some transit nodes may even suppress ICMPv6 responses entirely.

O-flag processing is optional. Not all SRv6 implementations process the O-flag. An endpoint that does not support OAM behaviors (End.OP / End.OTP) will process the packet as a regular data packet despite the flag being set. Operators must verify OAM support on all relevant nodes.

Ping to a SID verifies the control plane, not necessarily the data plane. A successful SRv6 ping confirms that the SID is reachable and the node responds, but it does not guarantee that data traffic following the same segment list will be forwarded correctly (e.g., VRF binding, L2 cross-connect).

Use Cases

  • Path verification - Confirm traffic follows the intended SRv6 policy
  • Fault isolation - Identify which segment in the path is failing
  • Performance monitoring - Measure latency and loss per segment
  • SLA validation - Verify service-level agreements on SRv6 paths
Document Relationship Description
draft-ietf-ippm-ioam-srv6-options Extension In-situ OAM (IOAM) data fields carried in SRv6 extension headers for per-hop telemetry
draft-filsfils-spring-path-tracing Extension Lightweight path tracing for SRv6 using a compressed per-hop record in the SRH TLV space
RFC 8754 Dependency Defines the SRH Flags field where the OAM O-flag resides
RFC 8986 Defines behaviors End.OP and End.OTP behaviors are registered in the SRv6 Endpoint Behaviors registry