SRv6 — Segment Routing over IPv6

Why it exists

SR-MPLS removed per-LSP signalling but kept the requirement that every router in the path run MPLS. In a network that is already IPv6 end to end, that is a second forwarding plane to build, monitor and troubleshoot.

SRv6 carries the segment list in an IPv6 extension header and makes each segment a routable IPv6 address. A transit router forwards on the destination address, which it already knows how to do, and needs no SRv6 support at all.

The interesting consequence is that a SID is structured. The locator gets the packet to a router and the function tells that router what to do — so one field replaces both the transport label and the service label of an MPLS VPN.

The destination address is the instruction

The active segment is the IPv6 destination. Transit routers forward on it without knowing what SRv6 is; only the segment endpoint reads the header.

Link
Blocking
Packet in flight
Discarded
Emphasis

Select a device to read its state. Arrow keys walk the topology.

Text equivalent of this diagram

Devices and links at this step
Element	Kind	State
Source node	router	Segments: A, B · Segments Left: 1
Transit · plain IPv6	router	—
Endpoint A	router	—
Endpoint B	router	—
Source node — Transit · plain IPv6	link	up
Transit · plain IPv6 — Endpoint A	link	up
Endpoint A — Endpoint B	link	up

1 / 6

The source node encapsulates the packet in an outer IPv6 header and adds a Segment Routing Header holding the segment list.

What changed

Source node: Segments → A, B
Source node: Segments Left → 1
Emphasis on Source node

How it works

The active segment is the outer destination address. The remaining segments sit in the Segment Routing Header with a Segments Left counter, and only a node whose own SID is in the destination field examines that header.

A segment endpoint matches the destination against a locally instantiated SID, decrements Segments Left, copies the next segment into the destination and forwards. At the last segment it executes the behaviour the SID encodes.

Behaviours are a defined catalogue: End as a plain waypoint, End.X to cross-connect a specific link, End.DT4 and End.DT6 to decapsulate into a named table, End.DX2 to hand a frame to a layer-two circuit.

Only the locator is routed, advertised into the IGP as an ordinary IPv6 prefix. Reachability of a SID is therefore a plain routing question, and a locator that is not advertised produces a plain routing failure.

On the wire

Constructed examples, encoded from the field table below them — not captured traffic.

Outer IPv6: Next Header 43, routing header. The destination address holds the active segment, so ordinary forwarding moves the packet toward it. RFC 8754
Segment Routing Header: Fixed fields, then the segment list in reverse order, then optional TLVs. RFC 8754
Inner packet: The original packet, when the source node encapsulated rather than inserting a header into an existing one. RFC 8754

Configure it

```
segment-routing
 srv6
  locators
   locator MAIN
    micro-segment behavior unode psp-usd
    prefix 2001:db8:a::/48
```
The locator is the routed half of every SID this node owns. Allocate it like an addressing plan — a /48 per region and a per-node block reads correctly in a traceroute and summarises into the IGP.
RFC 8986 §3.1
```
router isis CORE
 address-family ipv6 unicast
  segment-routing srv6
   locator MAIN
```
Advertises the locator as an ordinary IPv6 prefix. This is the line whose absence produces a plain routing failure that nobody connects to SRv6.
Common mistake: Configuring the locator and never advertising it. Every SRv6 command shows healthy state and packets are dropped at the first router with no route.
RFC 8986 §3.3
```
vrf CUSTOMER-A
 address-family ipv4 unicast
  segment-routing srv6
   locator MAIN
   alloc mode per-vrf
```
Allocates an End.DT4 SID for the VRF. That single SID does what a transport label and a VPN label did together — reach this PE and name the table.
RFC 8986 §4.7
```
router bgp 65000
 vrf CUSTOMER-A
  address-family ipv4 unicast
   segment-routing srv6
    alloc mode per-vrf
```
BGP advertises the SID with the prefix, so the remote PE knows which SID to encapsulate toward. The service signalling is unchanged; only what is carried differs.
```
ipv6 access-list SRV6-EDGE
 deny ipv6 any 2001:db8:a::/48
 permit ipv6 any any
interface TenGigE0/0/0/9
 ipv6 access-group SRV6-EDGE ingress
```
Keeps locator space unreachable from outside. RFC 8754 states plainly that the security model depends on the domain boundary being enforced — a packet arriving with an SRH can otherwise steer itself.
RFC 8754 §5.1
```
interface TenGigE0/0/0/0
 mtu 9216
```
Forty bytes of IPv6, eight of SRH and sixteen per segment. On a 1500-byte core this is the difference between a working service and one where only small packets pass.

Verify

show segment-routing srv6 sid: The local SID table — what this node will actually execute.
show segment-routing srv6 locator: Whether the locator is allocated and advertised.
show bgp vrf CUSTOMER-A ipv4 unicast: Prefixes with the SID attached.
ping ipv6 <remote-sid>: That the locator is reachable before blaming anything else.

Caveats

Only the locator is routed. If it is not in the IGP, packets are dropped as ordinary unroutable IPv6 and the failure looks like a routing problem — which it is.
Behaviour support differs between platforms. An unimplemented behaviour is not rejected; the SID resolves as something else.
Size the core MTU before deployment, not after the first application complains.

When it breaks

Symptom first, because that is what you have when it happens.

An SRv6 policy is configured and traffic is dropped somewhere in the core, with no SRv6-specific error anywhere.
Narrow it down
1. Check for a route to the SID’s locator on every router along the path.
2. Confirm the locator is being advertised into the IGP by its owner.
3. Look at whether summarisation at an area boundary has swallowed it.
Cause
Only the locator is routed. Without a route to it, the packet is an ordinary unroutable IPv6 packet and is discarded as one.
Fix
Advertise the locator into the IGP, and check the summarisation at every area boundary it has to cross.
Small packets pass and large ones vanish. Ping succeeds, DNS works, TLS handshakes hang.
Narrow it down
1. Sweep the packet size with the do-not-fragment bit set and find the threshold.
2. Count the segments — sixteen bytes each on top of forty-eight.
3. Check whether ICMPv6 is permitted end to end.
Cause
The encapsulation does not fit the core MTU. The ICMPv6 Packet Too Big goes to the encapsulating node rather than the customer host, so path MTU discovery cannot complete.
Fix
Raise the core MTU, shorten the segment list, and permit ICMPv6. A 9000-byte core removes the whole class of problem.
A policy works on one platform and misdelivers on another, with the same configuration.
Narrow it down
1. Compare the behaviour catalogue the two platforms implement.
2. Check how the SID resolves in the FIB on the failing one — local SID, local interface, or ordinary route.
3. Look at whether a flavour such as PSP or USP is being assumed.
Cause
The behaviour is not implemented. The SID then matches as a local interface or a nonlocal route, both of which are defined and neither of which is what was intended.
Fix
Design to the behaviours the hardware actually supports, and verify the local SID table rather than the configuration.
Traffic from outside the network appears to be following an internal engineered path.
Narrow it down
1. Check for an inbound filter on SRH-bearing packets at every external interface.
2. Confirm the locator space is not reachable from outside.
3. Look at whether an internal SID is being addressed directly from the internet.
Cause
The SR domain boundary is not enforced. A packet carrying an SRH can steer itself, and the RFC’s security model assumes the edge filters it.
Fix
Drop SRH-bearing packets and packets addressed into locator space at every domain boundary.
Traffic steered with an inserted header is dropped as soon as it leaves the operator’s own network.
Narrow it down
1. Check whether the source is encapsulating or inserting — `mode encap` against `mode inline` on Linux.
2. Find the first hop outside the SR domain and see whether it discards the packet.
3. Confirm whether the original source address survives, which inline preserves and encapsulation does not.
Cause
Inserting an SRH into an existing header rewrites a packet the sender did not consent to, so it is only defined inside an SR domain. Anything validating headers at the edge is entitled to discard it.
Fix
Encapsulate rather than insert for anything that crosses a boundary. Inline is a within-domain optimisation and its constraint is not a bug.

Design notes

Size the core for the encapsulation before deploying anything. Forty-eight bytes plus sixteen per segment turns a 1500-byte core into a partial-failure generator, and the ICMPv6 that would explain it goes to the encapsulating node rather than to the customer.

Plan the locator allocation like an addressing plan, because it is one. A /48 per region with a /64 locator per node is readable in a traceroute and summarises into the IGP; ad-hoc allocation is not recoverable later.

Filter the SR domain at its edge. A packet arriving from outside with an SRH can steer itself through the network, and RFC 8754 is explicit that the security model depends on the domain boundary being enforced.

Check the behaviour catalogue per platform before designing around one. An unimplemented behaviour is not rejected — the SID resolves as a local interface or an ordinary route and the packet goes somewhere unintended.

Misconceptions

“SRv6 is MPLS with IPv6 addresses.”: There is no MPLS in it. The segment list is an IPv6 extension header and each segment is a routable address, so the forwarding plane is plain IPv6 — which is the entire point.
“Every router on the path must support SRv6.”: Only the segment endpoints do. A transit router forwards on the destination address and never looks at the SRH, which is what makes incremental deployment possible.
“A SID is a 128-bit label.”: It is a structured, routable address. The locator half is advertised into the IGP and reached by ordinary routing; the function half is an instruction the owning router looks up locally.
“Each hop pops a segment from the SRH.”: Only the node whose SID is currently in the destination address touches it, and it decrements a counter rather than removing anything. Transit hops in between do nothing to the header at all.

More walkthroughs

A SID is an address with an opiniondesign-choice

The locator gets the packet to a router; the function tells that router what to do with it. One 128-bit field replaces a label stack and a VPN label.

Link
Blocking
Packet in flight
Discarded
Emphasis

Select a device to read its state. Arrow keys walk the topology.

Text equivalent of this diagram

Devices and links at this step
Element	Kind	State
PE1	router	—
IPv6 core	cloud	—
PE2	router	SID: 2001:db8:a::1:0/128 · Structure: locator : function : argument
VRF CUSTOMER-A	zone	—
PE1 — IPv6 core	link	up
IPv6 core — PE2	link	up
PE2 — VRF CUSTOMER-A	link	up

1 / 6

A SID is not opaque. It splits into a locator, a function, and optionally an argument — and only the locator is routed.

What changed

PE2: SID → 2001:db8:a::1:0/128
PE2: Structure → locator : function : argument
Emphasis on PE2

Small packets fine, large packets gonefailure

Every segment adds sixteen bytes to a header that already added forty-eight. Ping works, the application does not, and the ICMP that would explain it never arrives.

Link
Blocking
Packet in flight
Discarded
Emphasis

Select a device to read its state. Arrow keys walk the topology.

Text equivalent of this diagram

Devices and links at this step
Element	Kind	State
Source node	router	Overhead: 40 + 8 + 4×16 = 112 B
Core · MTU 1500	cloud	—
Endpoint	router	—
Source node — Core · MTU 1500	link	up
Core · MTU 1500 — Endpoint	link	up

1 / 5

The encapsulation is forty bytes of IPv6 header, eight of SRH, and sixteen more for every segment in the list. A four-segment path costs 112 bytes.

What changed

Source node: Overhead → 40 + 8 + 4×16 = 112 B
Emphasis on Source node

Terms

SRv6 SID: A 128-bit routable IPv6 address with structure: a locator that gets the packet to a router and a function that tells that router what to do. One field replaces a transport label and a VPN label.
Segments Left: The counter in the Segment Routing Header naming which entry is active. Only the node whose SID is currently in the destination address decrements it; transit hops never touch the header.
Locator: The routed half of an SRv6 SID, advertised into the IGP as an ordinary IPv6 prefix. A locator that is not advertised produces a plain routing failure nobody connects to SRv6.

Check yourself

What SRv6 support does a transit router need?
Where is the segment currently being processed?
What replaces the VPN label of an MPLS L3VPN in SRv6?
A locator is not advertised into the IGP. What is the symptom?
Ping works and TLS handshakes hang across an SRv6 policy. Why?
In what order does the segment list appear in the header?
Why is the SRH defined as a routing header rather than a new header type?
What does a reduced SRH leave out?

Why it exists

The destination address is the instruction

How it works

On the wire

Configure it

Verify

Caveats

When it breaks

An SRv6 policy is configured and traffic is dropped somewhere in the core, with no SRv6-specific error anywhere.

Narrow it down

Cause

Fix

Small packets pass and large ones vanish. Ping succeeds, DNS works, TLS handshakes hang.

Narrow it down

Cause

Fix

A policy works on one platform and misdelivers on another, with the same configuration.

Narrow it down

Cause

Fix

Traffic from outside the network appears to be following an internal engineered path.

Narrow it down

Cause

Fix

Traffic steered with an inserted header is dropped as soon as it leaves the operator’s own network.

Narrow it down

Cause

Fix

Design notes

Misconceptions

More walkthroughs

A SID is an address with an opiniondesign-choice

Small packets fine, large packets gonefailure

Terms

Check yourself

Related

SR-MPLS

L3VPN

RSVP-TE