High-throughput enterprise backbones and distributed Anycast VPN fabrics require agile traffic steering and sub-second failure recovery. Multi-protocol label switching (MPLS) historically anchored traffic engineering and Layer 3 VPN services.

However, MPLS introduces immense protocol complexity. Maintaining Label Distribution Protocol (LDP), Resource Reservation Protocol with Traffic Engineering (RSVP-TE), and targeted BGP sessions forces transit routers to track thousands of signaling states in hardware memory.

To eliminate this operational friction, the IETF standardized Segment Routing over IPv6 (SRv6) through RFC 8402, RFC 8754, and RFC 8986. By unifying the control plane and forwarding plane entirely within native IPv6 packets, SRv6 implements stateless source routing, programmatic traffic engineering, and deterministic sub-50-millisecond failure protection through Topology-Independent Loop-Free Alternate (TI-LFA).

The MPLS Complexity Crisis: The Need for Unified IPv6 Data Plane Routing

Traditional MPLS networks decouple forwarding from underlying IP routing. This separation creates operational friction across modern cloud backbones:

  1. Protocol Stack Bloat: Operators must deploy IGP (OSPF/IS-IS), LDP for label binding, RSVP-TE for path protection, and MP-BGP for VPN customer routing.
  2. Transit State Exhaustion: In RSVP-TE, transit routers maintain per-tunnel state, exhausting memory and delaying convergence in large meshes.
  3. Encapsulation Fragmentation: MPLS cannot traverse standard IP transit without additional overlays, fragmenting visibility.

SRv6 replaces this multi-layered stack with a single native protocol: standard IPv6. Packets carry their own routing instructions inside a compact extension header, allowing commodity routers to process transit traffic using standard IPv6 longest-prefix matching.

Architecture of SRv6 Network Programming: RFC 8986 Fundamentals

RFC 8986 defines network programming: the concept that a network path can be expressed as an ordered list of instructions encoded directly within an IPv6 address.

Instead of routers maintaining tunnel tables, the ingress router encodes the entire execution path into a sequence of 128-bit Segment Identifiers (SIDs). As the packet traverses the backbone, each SRv6-capable node reads the active SID, executes the associated instruction, and advances to the next segment.

Anatomy of a 128-bit SID: Locator, Function, and Arguments Breakdown

An SRv6 Segment Identifier is structurally formatted as a standard IPv6 address, divided into functional components:

$$ ext{SRv6 SID (128 bits)} = ext{Locator} ,|, ext{Function} ,|, ext{Arguments}$$

  • Locator ($L$ bits): An IPv6 prefix assigned to a specific network node. Intermediate routers route packets toward this node using standard IGP (IS-IS or OSPFv3) shortest-path forwarding without needing SRv6 awareness.
  • Function ($F$ bits): An opcode specifying the specific network function or instruction to execute (e.g., forward via link X, decapsulate into VRF Y, inspect via firewall Z).
  • Arguments ($A$ bits): Optional parameters for the function, such as flow IDs or quality-of-service markers.

For example, in a /64 locator environment with a 16-bit function, 2001:db8:acad:1:: identifies the edge gateway, while 2001:db8:acad:1:0042:: instructs the gateway to execute function 0x0042 (such as forwarding to a specific VPN routing table).

The Segment Routing Header (SRH): RFC 8754 Packet Walkthrough

To carry multiple segments, RFC 8754 introduced the IPv6 Segment Routing Header (SRH), implemented as an IPv6 Routing Extension Header (Type 4):

+-------------------------------------------------------------------+
| Next Header (8) | Hdr Ext Len (8) | Routing Type (4) | Segments Left (8) |
+-------------------------------------------------------------------+
| Last Entry (8)  | Flags (8)       | Tag (16)                             |
+-------------------------------------------------------------------+
| Segment List[0] (128 bits - Final Destination SID)                |
+-------------------------------------------------------------------+
| Segment List[1] (128 bits - Transit Instruction SID)              |
+-------------------------------------------------------------------+
| Segment List[2] (128 bits - Initial Transit SID)                  |
+-------------------------------------------------------------------+

Operational fields include:

  • Segments Left (SL): A pointer indicating the index of the next active segment in the list.
  • Segment List: An ordered array of 128-bit IPv6 addresses, listed in reverse order of execution (Segment List[Last Entry] is processed first; Segment List[0] is processed last).

When a packet is in flight, the IPv6 destination address always contains the active SID. Upon reaching that node, the router decrements Segments Left, copies Segment List[SL] into the IPv6 destination address, and forwards the packet toward the next locator.

Source Routing Paradigm: Eliminating Mid-Network State Across Transit Meshes

SRv6 shifts all intelligence to the network edge. Ingress gateways determine the full transmission policy—based on telemetry, latency metrics, or customer SLAs—and inject the appropriate SID list into the packet header.

This paradigm offers distinct operational advantages:

  • Zero Core State: Intermediate transit routers maintain only standard IPv6 routes for locators. They do not maintain per-tunnel state, bandwidth reservations, or label forwarding databases.
  • Arbitrary Policy Traversal: An ingress gateway can force traffic through specific transit providers, scrubbing centers, or low-latency optical links simply by appending corresponding SIDs.
  • Seamless Interoperability: Routers that do not support SRv6 simply forward packets based on the locator prefix in the standard IPv6 destination address, enabling incremental deployment across legacy transit networks.

TI-LFA Fast Reroute: Sub-50ms Deterministic Failover Without RSVP-TE

Link failures in transit networks can disrupt real-time communication. Classical IP convergence requires hundreds of milliseconds to detect outages, update IGP topology databases, and recalculate routing tables.

Topology-Independent Loop-Free Alternate (TI-LFA) provides automated, deterministic sub-50-millisecond protection for any network topology:

  1. Pre-Computed Backup Paths: Routers compute post-convergence backup paths in advance using Dijkstra calculations.
  2. Post-Convergence Consistency: Unlike traditional LFA (RFC 5286), which fails in topologies where neighbors might loop packets back, TI-LFA computes the exact path traffic will take after full IGP recalculation.
  3. Segment Inversion: The router uses SRv6 SIDs (Node SIDs or Adjacency SIDs) to steer packets around the failed link to a safe release node ($Q$-node) that can reach the destination without looping.

When an interface fails, the hardware line card immediately encapsulates packets into the pre-calculated TI-LFA backup segment list. Convergence occurs locally in hardware in less than 50 milliseconds, avoiding micro-loops and dropped packets.

SRv6 Service Mapping: Encapsulating L3VPN and Anycast Overlays

RFC 9252 establishes how MP-BGP advertises overlay VPN services over an SRv6 underlay. Instead of allocating 32-bit MPLS VPN labels, BGP updates advertise SRv6 SIDs representing specific VPN instances:

  • End.DT4 / End.DT6: The receiving gateway decapsulates the IPv6 outer header and forwards the inner IPv4 or IPv6 packet into a designated Virtual Routing and Forwarding (VRF) table.
  • End.DX4 / End.DX6: Decapsulates and cross-connects traffic directly to a specific point-to-point customer interface.
  • Anycast SIDs: A shared locator advertised from multiple edge data centers. Traffic directed to an Anycast SID automatically terminates at the topologically closest healthy gateway.

This unified mapping simplifies multi-tenant VPN backbones, eliminating LDP signaling while providing native end-to-end encryption and traffic isolation.

MTU Overhead and Micro-SIDs (uSID): Overcoming IPv6 Extension Header Bloat

Each 128-bit SID in an SRH adds 16 bytes of header overhead. A policy requiring a 4-segment SID list adds 64 bytes for segments plus 8 bytes for the SRH base header, expanding packet size by 72 bytes.

To optimize bandwidth utilization and prevent MTU fragmentation, network architects employ two primary strategies:

  1. Micro-SIDs (uSID): Standardized through draft-ietf-spring-srv6-srh-compression, micro-SIDs pack multiple 16-bit or 32-bit instructions into a single 128-bit IPv6 address container. A single carrier can encode up to six segment instructions within a standard 128-bit address, reducing header overhead by over 75 percent.
  2. Automated MSS Clamping: Gateways rewrite TCP SYN Maximum Segment Size negotiation values, ensuring client packets do not exceed path MTU limits across transit meshes.

Security Considerations: Limiting the SRv6 Trusted Domain at Ingress Edges

Because SRv6 encodes routing instructions in the destination address, unauthorized external packets carrying internal SIDs could exploit internal network functions or redirect traffic.

RFC 8754 and RFC 8986 strictly define the SRv6 Trusted Domain: a closed, managed network perimeter where SRv6 packets are created, verified, and consumed.

HMAC Signature Verification and SRH Tampering Prevention

RFC 8754 Section 2.1 specifies an optional HMAC TLV within the SRH. Using pre-shared cryptographic keys, edge gateways sign the segment list and IPv6 source address:

  • Ingress nodes generate an HMAC over the SID sequence and header fields.
  • Egress or intermediate policy enforcement points verify the cryptographic signature before executing sensitive instructions.
  • Untrusted packets with altered SIDs or missing HMAC tags are immediately dropped at hardware wire speed.

Boundary Filtering via BCP 38 to Prevent External SID Injection

Edge firewalls and border routers must enforce strict boundary access control lists:

  1. Ingress Filtering: Drop any inbound packet from external peers or the public internet containing an SRH or targeted at internal locator prefixes.
  2. Egress Sanitization: Strip SRH headers before packets leave the trusted domain to prevent internal network topology leakage.
  3. Anti-Spoofing: Enforce BCP 38 / RFC 2827 ingress filtering to prevent external actors from spoofing internal gateway addresses.

RiceGuard Anycast Backbone: Deterministic SRv6 Mesh Engineering

VPNRice implements the RiceGuard Layer 3 mesh architecture across global transit points of presence. In dense Anycast networks, transit outages and provider peering instability can cause sudden routing shifts and dropped connections.

RiceGuard leverages native SRv6 to guarantee high availability and low latency:

  • TI-LFA Fast Reroute: Backbone routers deploy automated TI-LFA protection, switching failed transit links to backup optical routes within 35 milliseconds.
  • Stateless Traffic Engineering: RiceGuard dynamically injects micro-SIDs into Anycast traffic, directing flows around congested Tier-1 transit paths without maintaining state in core routers.
  • Zero-Loss Anycast Handoff: Sessions transition smoothly between Anycast nodes during maintenance windows using graceful drain SIDs.
  • Integrated Health Auditing: Real-time path telemetry monitors MTU boundaries and routing health. Users can verify their active connection parameters via /what-is-my-ip.

For users seeking stable, low-latency connectivity across high-scale distributed networks, client software is available at /download. Details on multipath ECMP hash polarization are analyzed in /news/gre-in-udp-rfc-8086-geneve-ecmp-hash-polarization-vpn, while routing resilience during control plane restarts is covered in /news/bgp-graceful-restart-rfc-4724-llgr-anycast-resilience.

Practical Implementation: Configuring SRv6 Endpoints and Encap in Linux

The Linux kernel natively supports SRv6 network programming and segment routing encapsulation via iproute2. Administrators can configure SRv6 behaviors using standard network utilities.

Enabling IPv6 Forwarding and Segment Routing:

Enable IPv6 routing and SRv6 processing on Gateway A:

# Enable IPv6 forwarding and Segment Routing support
sysctl -w net.ipv6.conf.all.forwarding=1
sysctl -w net.ipv6.conf.all.seg6_enabled=1
sysctl -w net.ipv6.conf.eth0.seg6_enabled=1

Configuring SRv6 Ingress Encapsulation:

Route outbound traffic toward an SRv6 policy by encapsulating packets into an IPv6 header with an SRH segment list:

# Encapsulate traffic destined for 10.100.0.0/16 into an SRv6 path
ip -6 route add 10.100.0.0/16 encap seg6 mode encap     segs 2001:db8:beef:2::,2001:db8:acad:1::     dev eth0

In this command, outbound packets are wrapped into an IPv6 header where the first segment is 2001:db8:acad:1:: and the final segment is 2001:db8:beef:2::.

Configuring SRv6 End.DT4 Decapsulation on the Egress Gateway:

On Gateway B, configure the locator endpoint to decapsulate packets and deliver inner IPv4 payloads to a VRF:

# Bind End.DT4 function to locator SID for VRF delivery
ip -6 route add 2001:db8:acad:1::/64 encap seg6local action End.DT4     vrftable 100     dev eth0

Verifying SRv6 Tunnel State via Telemetry:

Inspect active SRv6 encapsulation routes:

ip -6 route show encap seg6

10.100.0.0/16  encap seg6 mode encap segs 2 [ 2001:db8:beef:2:: 2001:db8:acad:1:: ] dev eth0 metric 1024

Verify packet transmission with tcpdump showing the active Segment Routing Header:

tcpdump -ni eth0 'ip6[6] == 43' -vv

07:18:22.410928 IP6 2001:db8:feed:1:: > 2001:db8:acad:1::: HBH, routing (type 4, segleft 1, [2] 2001:db8:beef:2::, [1] 2001:db8:acad:1::)

The telemetry confirms that the packet carries the SRH with active segment progression, executing deterministic source routing across the transit underlay.