Abstract

Segment Routing over IPv6 (SRv6) offers a viable path for enterprises and service providers to retire legacy MPLS infrastructure without giving up traffic engineering capabilities. By encoding forwarding instructions as an ordered list of IPv6 segment identifiers directly in the packet header, SRv6 eliminates the need for a separate label distribution protocol, collapses the control plane, and makes the forwarding behavior fully programmable per flow. This article examines the SRv6 data plane mechanics, the migration strategies practitioners are using in 2025, and the operational maturity gaps that remain.

SRv6 Data Plane Mechanics

An SRv6 packet carries a Segment Routing Header (SRH) defined in RFC 8754. The SRH contains a segment list - an ordered stack of 128-bit IPv6 addresses called Segment Identifiers (SIDs). Each SID encodes both a locator (a routable IPv6 prefix assigned to a node) and a function (a local behavior, such as “forward to this VPN endpoint” or “apply this traffic policy”). The active segment is copied to the IPv6 destination address field. When a node processes the packet, it executes the function encoded in the SID, decrements the segment left counter, and copies the next SID into the destination address for forwarding.

The IETF SPRING working group defines a standard set of SID behaviors in RFC 8986, including End (basic forwarding), End.X (forward out a specific adjacency), End.DT4/DT6 (VPN routing table lookup), and End.DT2U (bridging). These cover the most common MPLS service constructs - L3VPN, VPLS, and EVPN - without requiring LDP, RSVP-TE, or a separate label space.

Migration Strategies Operators Are Using

Most production migrations in 2025 follow a coexistence model rather than a flag-day cutover. Routers at the edge of the SRv6 domain map incoming MPLS-labeled traffic to SRv6 SIDs using the End.B6.Encaps behavior, which wraps the MPLS packet in a new IPv6 header with an SRH. This lets the operator migrate the core to SRv6 while CE devices and legacy PE routers continue signaling MPLS labels. Cisco IOS-XR and Arista EOS both support this mapping mode, and Nokia SR OS added it in release 23.3.

On the routing protocol side, IS-IS with SRv6 TLVs (defined in RFC 9352) is the dominant choice for advertising locators and SID bindings. BGP carries the SRv6 service routes (L3VPN, EVPN) with the SRv6 L3 Service TLV defined in RFC 9252. The combination means the control plane is entirely within standard protocols; no vendor-specific signaling is required for the core migration.

Programmability and Traffic Engineering

SRv6’s traffic engineering story centers on inserting computed segment lists at the ingress. A path computation element (PCE) - typically Cisco SR-PCE, OpenConfig-driven controllers, or a custom application using PCEP - computes segment lists based on topology, link utilization, and latency constraints collected via BGP-LS. The ingress router installs computed segment lists as steering policies bound to traffic classes, enabling per-flow TE without pre-provisioning tunnels across the core.

This is the capability MPLS RSVP-TE offered, but without per-tunnel state on transit nodes. A core router running SRv6 is stateless with respect to individual flows - it reads the active SID and forwards accordingly. Scale constraints shift from per-LSP state to the size of the segment list in the packet header, which is bounded but manageable for realistic path depth.

Operational Gaps Worth Noting

Hardware support remains uneven. Line cards from 2022 or earlier in many routers handle the SRH in software, which adds latency and consumes forwarding CPU. Operators migrating high-throughput interfaces need to verify per-ASIC SRH parsing support rather than rely on software feature flags. Cisco’s Silicon One and Broadcom’s Jericho2 family handle SRH in hardware; many older ASICs do not.

Troubleshooting tooling is also thinner than MPLS. traceroute works but does not display per-segment information without explicit SID awareness at each hop. Operators building SRv6 WANs today typically deploy gNMI-based streaming telemetry from each node and build segment-path visibility into their monitoring stacks independently, rather than relying on out-of-the-box tools.