Infrastructure

SRv6

2017ActivePublished: 8 May 2026Updated: 8 May 2026Published

Key innovation

Source routing native to IPv6 — the ingress node encodes a list of processing instructions (segments) as IPv6 addresses inside a new Segment Routing Header, removing the need for a separate MPLS control plane.

How it works

The ingress (SR source) inserts an SRH containing a list of IPv6 SIDs into the packet. The "Segments Left" field points to the current segment to process — its address is the active IPv6 destination. Each SR-aware node, when the destination matches one of its local SIDs, decrements Segments Left, copies the next SID into the destination address, and executes the function encoded in the SID (END, END.X, END.DT4/DT6 for VPN, END.B6 for binding, etc.). Non-SRv6-aware routers simply forward the packet via standard IPv6 longest-prefix match because a SID is just an IPv6 address.

Problem solved

Traditional MPLS-TE requires a complex control plane (LDP, RSVP-TE) and per-flow state in the network core. SRv6 removes both by placing path information inside the packet header and using IPv6 as the data plane.

Implementation

Reference implementations

Linux SRv6 (kernel + iproute2)

Official

FRRouting (FRR) SRv6

Official

VPP (Vector Packet Processing) SRv6

Official

Implementation pitfalls

SRH header sizeMedium

Each SID is 128 bits; long segment lists inflate overhead and may fragment packets or exceed MTU.

Fix:Use Compressed SRv6 (uSID) — packing multiple SIDs into a single 128-bit address.

Hardware / linecard supportHigh

Not all linecards process full SRv6 Network Programming in hardware — older ASICs may only handle the SRH in slow path.

Source-routing securityHigh

Source routing has been an attack vector historically (RFC 5095 deprecates IPv6 RH0); SRv6 requires careful edge policy to drop untrusted SRHs from outside the SR domain.