Segment Routing over IPv6 (SRv6) represents a fundamental shift in how modern networks handle traffic engineering, service delivery, and network programmability. By combining the source routing paradigm of Segment Routing with the ubiquitous IPv6 protocol, SRv6 transforms the network into a programmable platform where complex service chains and traffic paths can be expressed as simple sequences of IPv6 addresses.
Standardized by the IETF through a series of RFCs starting with RFC 8754 (IPv6 Segment Routing Header) in March 2020 and RFC 8986 (SRv6 Network Programming) in February 2021, SRv6 has rapidly evolved from theoretical concept to production-ready technology deployed by major carriers and cloud providers worldwide. This builds upon existing IPv6 infrastructure and protocols.
At its core, SRv6 solves several critical challenges facing modern networks:
SRv6 is particularly relevant as organizations worldwide transition to IPv6 and seek modern alternatives to aging MPLS infrastructure. Understanding SRv6 becomes essential for network architects planning next-generation service provider networks, data center fabrics, and enterprise WANs.
For over two decades, Multi-Protocol Label Switching (MPLS) dominated carrier networks and enterprise WANs, providing traffic engineering, VPN services, and QoS capabilities that IP routing alone could not deliver. MPLS achieved this through label-based forwarding and protocols like LDP (Label Distribution Protocol), RSVP-TE (Resource Reservation Protocol - Traffic Engineering), and BGP-based L3VPNs.
However, MPLS carries significant complexity:
Segment Routing, originally developed by Cisco and standardized through the IETF Spring (Source Packet Routing in Networking) working group, reimagines traffic steering using a source routing approach. Instead of establishing paths through signaling protocols, the source node encodes the complete path as an ordered list of segments in the packet header.
Key Innovation: The network core becomes stateless—routers forward packets based solely on the active segment identifier, with no per-flow or per-tunnel state required.
Segment Routing has two data plane options:
SRv6 extends Segment Routing concepts to IPv6, leveraging several IPv6 characteristics:
The result is a powerful network programming platform that simplifies operations while enabling sophisticated services.
The fundamental building block of SRv6 is the Segment Identifier (SID), a 128-bit IPv6 address with special semantics. Each SID instructs a node to perform a specific action on the packet.
SID Structure (128 bits total):
┌─────────────────┬──────────────────┬──────────────────┐
│ Locator │ Function │ Arguments │
│ (Variable) │ (Variable) │ (Optional) │
└─────────────────┴──────────────────┴──────────────────┘
Routing Behavior Parameters
Components:
Locator (typically first 48-64 bits)
Function (typically 16-32 bits)
Arguments (remaining bits, optional)
Example SID:
2001:db8:a:1:40:: (SID representing "forward to node A, then apply function 0x40")
│ │ │
│ │ └── Function ID (0x40 = End function)
│ └───── Locator (identifies Node A in network)
└──────────────── Global IPv6 prefix (2001:db8::/32)
SR Domain Ingress Node (Source)
SR Transit Node
SR Segment Endpoint Node
SR Domain Egress Node (Destination)
Segment List: An ordered sequence of SIDs representing the path and services a packet must traverse.
Example Segment List:
[SID1, SID2, SID3]
│ │ └── Segment 3: Firewall service at DataCenter-B
│ └────────── Segment 2: Low-latency path waypoint
└────────────────── Segment 1: Edge router at POP-A
SR Policy: Defines traffic steering rules, including:
The Segment Routing Header (SRH) is a new IPv6 Routing Extension Header (Type 4) defined in RFC 8754. It carries the list of segments and metadata for steering packets through the network.
IPv6 Packet with SRH:
┌─────────────────────────────────────────────────────┐
│ IPv6 Header (40 bytes) │
│ ┌──────────────────────────────────────────────┐ │
│ │ Source Address: 2001:db8:1::100 │ │
│ │ Destination Address: 2001:db8:a:1:40:: │ │ ◄── Active SID
│ │ (First SID in list) │ │
│ │ Next Header: 43 (Routing Header) │ │
│ └──────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────┐
│ Segment Routing Header (SRH) - Extension │
│ ┌──────────────────────────────────────────────┐ │
│ │ Next Header: 41 (IPv6 encapsulation) or 17 │ │
│ │ Hdr Ext Len: Variable │ │
│ │ Routing Type: 4 (Segment Routing) │ │
│ │ Segments Left: 2 (remaining segments) │ │
│ │ Last Entry: 2 (index of last segment) │ │
│ │ Flags: 0 │ │
│ │ Tag: 0x0000 (optional metadata) │ │
│ ├──────────────────────────────────────────────┤ │
│ │ Segment List (bottom to top order): │ │
│ │ Segment[0]: 2001:db8:c:1:41:: │ │ ◄── Final dest.
│ │ Segment[1]: 2001:db8:b:1:40:: │ │ ◄── 2nd segment
│ │ Segment[2]: 2001:db8:a:1:40:: │ │ ◄── 1st segment (active)
│ └──────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────┐
│ Payload (inner IPv6 or other) │
└─────────────────────────────────────────────────────┘
Segments Left
Last Entry
Segment List
Tag
Each SID adds 16 bytes (128 bits) to the packet. A path with 5 segments requires:
For networks concerned with overhead, Compressed SID (CSID) techniques like SRv6 micro-segment (uSID) reduce this significantly by packing multiple short SIDs into a single IPv6 address, achieving substantial compression. This is similar to IPv6 address compression techniques used for efficiency.
Understanding SRv6 requires following a packet through its journey across an SR domain. Let's trace a packet from source to destination through multiple segments.
Network Topology:
┌──────┐ ┌──────┐
│Source│ │ Dest │
│ A │ │ Z │
└───┬──┘ └───▲──┘
│ │
│ Traffic must traverse: │
│ 1. Node B (waypoint for low-latency) │
│ 2. Node C (firewall service function) │
│ 3. Node D (destination endpoint) │
│ │
[Insert SRH] [Remove SRH]
│ │
▼ │
┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐
│Node B │─────▶│Node C │─────▶│Node D │──▶│Node Z │
│ (SID1)│ │ (SID2)│ │ (SID3)│ └───────┘
└───────┘ └───────┘ └───────┘
Step 1: Source Node A (Ingress - SR Policy Headend)
Source node A receives a packet destined for 2001:db8:999::1. Based on configured SR Policy, it determines the packet must traverse SID1→SID2→SID3.
Actions:
Resulting Packet:
IPv6 DA: 2001:db8:b:1:40:: (SID1 - Node B)
SRH:
Segments Left: 2
Segment[0]: 2001:db8:d:1:40:: (SID3 - Node D)
Segment[1]: 2001:db8:c:1:41:: (SID2 - Node C)
Segment[2]: 2001:db8:b:1:40:: (SID1 - Node B) ← Active
Step 2: Transit Nodes (Stateless Forwarding)
Intermediate routers between A and B perform standard IPv6 forwarding based on the destination address (SID1). They do NOT examine the SRH or maintain any state about this flow. This is a critical advantage of SRv6: the core remains simple and stateless.
Step 3: Node B (Segment Endpoint - SID1)
Node B recognizes 2001:db8:b:1:40:: as its own SID and processes the segment endpoint function.
Actions:
Resulting Packet:
IPv6 DA: 2001:db8:c:1:41:: (SID2 - Node C)
SRH:
Segments Left: 1
Segment[0]: 2001:db8:d:1:40:: (SID3 - Node D)
Segment[1]: 2001:db8:c:1:41:: (SID2 - Node C) ← Active
Segment[2]: 2001:db8:b:1:40:: (SID1 - Node B)
Step 4: Node C (Service Function - SID2)
Node C recognizes 2001:db8:c:1:41:: as its SID with function 0x41 (firewall inspection).
Actions:
Resulting Packet:
IPv6 DA: 2001:db8:d:1:40:: (SID3 - Node D)
SRH:
Segments Left: 0
Segment[0]: 2001:db8:d:1:40:: (SID3 - Node D) ← Active
Segment[1]: 2001:db8:c:1:41:: (SID2 - Node C)
Segment[2]: 2001:db8:b:1:40:: (SID1 - Node B)
Step 5: Node D (Egress/Destination - SID3)
Node D recognizes its SID and sees "Segments Left" = 0, indicating this is the final segment.
Actions:
Final Packet (SRH removed):
IPv6 Header:
Source Address: (original source)
Destination Address: 2001:db8:999::1 (Node Z)
Payload: (original application data)
One of SRv6's most powerful aspects is network programming: the ability to encode instructions directly into SIDs, allowing nodes to perform diverse functions based on the SID encountered.
RFC 8986 defines a set of standard SRv6 behaviors that routers can implement. Each behavior is identified by its function code within the SID.
End (Endpoint)
End.X (Endpoint with Layer-3 Cross-Connect)
End.T (Endpoint with specific IPv6 table)
End.DX6/DX4 (Endpoint with Decapsulation and IPv6/IPv4 forwarding)
End.DT6/DT4 (Endpoint with Decapsulation and Table lookup)
End.AS (Endpoint with Static proxy to SR-unaware service)
End.AD (Endpoint with Dynamic proxy)
End.B6.Encaps (Binding SID with IPv6 Encapsulation)
Scenario: Route traffic from Branch A to DataCenter, applying:
Segment List:
[2001:db8:1:1:End.X:: , // SID1: Use low-latency link at Node 1
2001:db8:2:1:End.AS:: , // SID2: Apply DPI service at Node 2
2001:db8:3:1:End.AS:: , // SID3: Apply load balancer at Node 3
2001:db8:4:1:End.AS:: , // SID4: Apply firewall at Node 4
2001:db8:5:1:End.DT6:: ] // SID5: Decapsulate into VPN table
The network automatically processes this "program," applying each service in sequence without requiring complex overlay configurations or signaling protocols.
Flexibility: Services expressed as ordered lists of functions Agility: Change service chains by modifying segment lists Visibility: Each SID explicitly identifies the operation being performed Extensibility: New functions can be defined without changing the protocol Simplicity: No need for NSH (Network Service Header) or proprietary service chaining protocols
Traffic engineering (TE)—controlling which paths packets take through the network—is a primary use case for SRv6. Traditional IP routing follows shortest paths, but many networks require more sophisticated path selection based on latency, bandwidth, reliability, or cost.
Explicit Path Control
SRv6 allows network operators to specify exact paths using Segment Lists:
Path 1 (Low Latency):
[Node-A → Node-B → Node-C → Dest]
Path 2 (High Bandwidth):
[Node-A → Node-X → Node-Y → Node-Z → Dest]
Path 3 (Geographic Compliance):
[Node-A → EU-Region-Only-Nodes → Dest]
Disjoint Paths
For redundancy, multiple disjoint paths can be configured as separate Segment Lists within an SR Policy. If Path 1 fails, traffic automatically switches to Path 2.
Color-Based Steering
SR Policies use "colors" to classify path characteristics:
Applications or BGP routes can specify a color, and the headend router selects the matching SR Policy.
Flex-Algo extends IGPs (OSPFv3, IS-IS) to compute paths optimized for specific metrics beyond shortest path.
Example Flex-Algo Definitions:
Flex-Algo 128: Minimize latency
- Metric: Link latency
- Exclude: High-latency links
Flex-Algo 129: Maximize bandwidth
- Metric: Available bandwidth
- Constraint: Minimum 10 Gbps
Flex-Algo 130: Geographic constraint
- Include: Only links within EU region
- Exclude: Trans-Atlantic links
Each Flex-Algo creates a separate routing topology, and SIDs can reference these algorithms. For example:
2001:db8:a:128:40:: (Locator for Node A, Flex-Algo 128 = low latency)
2001:db8:a:129:40:: (Locator for Node A, Flex-Algo 129 = high bandwidth)
SRv6 enables 5G network slicing, where different services (eMBB, URLLC, mMTC) require distinct network treatment:
Slice 1 (eMBB - Enhanced Mobile Broadband):
Slice 2 (URLLC - Ultra-Reliable Low-Latency Communications):
Slice 3 (mMTC - Massive Machine-Type Communications):
Each slice is implemented as an SR Policy with appropriate Segment Lists and Flex-Algo, providing logical network separation over shared physical infrastructure.
SRv6 naturally supports Equal-Cost Multi-Path (ECMP) load balancing. Routers hash the IPv6 Flow Label and destination address to distribute traffic across multiple equal-cost paths.
For controlled load balancing, SR Policies can define multiple Segment Lists with weights:
SR Policy to DataCenter:
Segment List 1 (weight 70): [SID1, SID2, SID3]
Segment List 2 (weight 30): [SID4, SID5, SID6]
Traffic splits 70/30 across the two paths.
Service Function Chaining (SFC) involves steering traffic through an ordered sequence of network services (firewall, NAT, DPI, IDS, load balancer) before reaching its destination. Traditional SFC required complex overlays like NSH (Network Service Header) or proprietary solutions.
SRv6 provides native, stateless service chaining using its network programming capabilities.
Components:
Scenario: HTTP traffic must traverse Firewall → DPI → Load Balancer before reaching web server.
Step 1: Classifier Applies Service Chain
Original Packet:
IPv6 SA: 2001:db8:client::1
IPv6 DA: 2001:db8:server::80
Payload: HTTP GET request
After Classification:
IPv6 SA: 2001:db8:client::1
IPv6 DA: 2001:db8:sfc1:End.AS:: (SID1 = Firewall)
SRH:
Segment[0]: 2001:db8:server::80 (final destination)
Segment[1]: 2001:db8:sfc3:End.AS:: (Load Balancer)
Segment[2]: 2001:db8:sfc2:End.AS:: (DPI)
Segment[3]: 2001:db8:sfc1:End.AS:: (Firewall) ← Active
Step 2: Firewall Service (SID1 - End.AS)
Node hosting firewall recognizes its SID and invokes the firewall service.
Actions:
Step 3: DPI Service (SID2 - End.AS)
Similar process: packet sent to DPI service, inspected, returned, and forwarded to next SID.
Step 4: Load Balancer Service (SID3 - End.AS)
Load balancer selects backend server, modifies destination if needed, returns packet.
Step 5: Final Segment (SID4 - End.DX6)
Final segment endpoint decapsulates, removes SRH, and forwards inner packet to web server.
Simplicity: No separate SFC protocol required—just SRv6 segments Flexibility: Reorder services by changing Segment List Visibility: Each segment identifies the service being applied Performance: Stateless processing, no overlay tunnels Interoperability: Works with SR-unaware services using End.AS behavior
Data Center East-West Traffic:
Carrier Networks:
Enterprise WAN:
Organizations evaluating modern network architectures frequently compare SRv6 with established MPLS technologies. Both provide traffic engineering and service capabilities, but with fundamentally different approaches.
| Aspect | SRv6 | MPLS (including SR-MPLS) |
|---|---|---|
| Data Plane | IPv6 routing and forwarding | MPLS label switching |
| Control Plane | OSPFv3, IS-IS, BGP with SRv6 extensions | LDP, RSVP-TE (traditional) or IGP-based (SR-MPLS) |
| Encapsulation | IPv6 header + SRH | MPLS label stack |
| Segment Identifier Size | 128 bits (full IPv6 address) | 20-32 bits (MPLS label) |
| Network Layer | Layer 3 (IPv6) | Layer 2.5 (between L2 and L3) |
1. Native IPv6 Integration
SRv6 operates entirely within IPv6, eliminating the need for MPLS infrastructure:
2. Massive Scalability via Summarization
SRv6 locators (the routable portion of SIDs) can be summarized hierarchically, dramatically reducing routing table sizes in large networks:
Traditional SR-MPLS (1000 routers):
- Each router advertises per-node SID
- 1000 routing entries minimum
SRv6 with Summarization:
- Aggregate: 2001:db8:region1::/48 covers 256 nodes
- Core routers see ~10 summarized prefixes instead of 1000
- Scales to 10,000+ routers efficiently
For networks exceeding 1000 routers, this is a decisive advantage.
3. Enhanced Programmability
The 128-bit SID space allows encoding complex instructions:
4. Operational Simplification
Single protocol stack reduces operational complexity:
This relates to IPv6 network troubleshooting and IPv6 connectivity testing.
5. Flexible Migration Path
SRv6 can be deployed incrementally on IPv6 networks:
1. Hardware Maturity and Performance
MPLS forwarding has decades of silicon optimization:
SRv6 requires more complex hardware processing:
2. Lower Overhead
MPLS labels are compact (4 bytes per label):
MPLS Label Stack (5 segments): 20 bytes
SRv6 SRH (5 segments): 88 bytes (8-byte header + 80 bytes for SIDs)
For small packets or bandwidth-constrained links, MPLS overhead is significantly lower.
3. Established Ecosystem
MPLS benefits from 20+ years of deployment:
4. Smooth Upgrade Path for Existing MPLS Networks
For networks already running MPLS, SR-MPLS provides:
Greenfield Deployments:
Large-Scale Networks (1000+ routers):
IPv6-Only Environments:
Advanced Service Requirements:
This aligns with IPv6 deployment best practices and IPv6-only network strategies.
Brownfield MPLS Networks:
Performance-Critical Applications:
Conservative Risk Profile:
Bandwidth-Constrained Links:
Many experts believe SRv6 represents the long-term future as:
However, MPLS and SR-MPLS will remain dominant in existing carrier networks for many years. The choice depends on specific network requirements, existing infrastructure, and strategic direction.
As of 2025, SRv6 has transitioned from experimental to production-ready, with comprehensive support across major networking vendors and successful multi-vendor deployments.
Platform Support:
Features:
Deployment Status: Production-ready since 2017, extensive carrier deployments
Platform Support:
Features:
Deployment Status: Large-scale commercial deployments in Asia-Pacific, Europe
Platform Support (2024):
Features:
Deployment Status: Rapid expansion in 2023-2024, production deployments
Platform Support:
Features:
Deployment Status: Production support, carrier-grade deployments
EANTC Testing (2024): The European Advanced Networking Test Center conducted comprehensive multi-vendor SRv6 interoperability testing with participants including Cisco, Huawei, Juniper, Nokia, Arista, Ciena, H3C, ZTE, and Keysight.
Key Results:
Real-World Multi-Vendor Deployment: XL Axiata (Indonesian carrier) operates a production SRv6 network with Huawei, Cisco, ZTE, and Juniper equipment, demonstrating real-world interoperability.
Linux Kernel:
VPP (Vector Packet Processing):
FRRouting:
As of early 2025, SRv6 has been deployed in commercial production networks including:
Deployments span mobile backhaul, metro aggregation, data center interconnect, and wide-area backbone networks.
SRv6 addresses diverse networking challenges across multiple domains. Understanding real-world scenarios helps identify where SRv6 delivers the most value.
1. Mobile Backhaul and 5G Transport
5G networks require flexible, scalable transport with network slicing capabilities. SRv6 provides:
Use Case: Ultra-Reliable Low-Latency Communications (URLLC) slice
Use Case: Massive Machine-Type Communications (mMTC) slice
Benefits:
2. Content Delivery and Caching
CDN providers leverage SRv6 for intelligent content routing:
Use Case: Geo-based content steering
Use Case: DDoS mitigation
3. Carrier Ethernet and Business Services
Enterprise L2/L3 VPN services over SRv6:
Use Case: Multi-site enterprise VPN
Use Case: Wholesale bandwidth services
1. East-West Traffic Engineering
Modern data centers require sophisticated traffic steering between servers:
Use Case: Microservices communication
Use Case: AI/ML fabric
2. Data Center Interconnect (DCI)
Connecting multiple data centers with SRv6:
Use Case: Active-active data centers
Use Case: Disaster recovery
3. Network Function Virtualization (NFV)
SRv6 as the underlay for virtualized network functions:
Use Case: Virtual firewall insertion
1. Multi-Cloud Connectivity
SRv6 enables intelligent routing across cloud providers:
Use Case: Hybrid cloud application
2. Edge Computing (MEC - Multi-Access Edge Computing)
Use Case: Low-latency gaming
1. SD-WAN over SRv6
Replace traditional SD-WAN overlays with SRv6:
Use Case: Branch office connectivity
2. Zero Trust Network Access (ZTNA)
SRv6 enables secure, identity-based routing:
Use Case: User-to-application policy enforcement
Understanding how organizations successfully deploy SRv6 provides valuable insights for network architects.
Deployment Scope:
Architecture:
Key Results:
Lessons Learned:
Deployment Scope:
Architecture:
Key Results:
Challenges Addressed:
Deployment Scope:
Architecture:
Key Results:
Operational Benefits:
Deployment Scope:
Architecture:
Key Results:
Deployment Scope:
Architecture:
Key Achievements:
While SRv6 offers compelling benefits, organizations must address several challenges for successful deployment.
Challenge: SRv6 requires more complex packet processing than traditional MPLS.
Specifics:
Mitigation:
Hardware Lifecycle:
Challenge: SRH adds significant overhead (8 bytes base + 16 bytes per SID).
Impact:
Mitigation:
Challenge: Limited SRv6 expertise in the workforce.
Considerations:
Mitigation:
Challenge: Traditional monitoring tools may not fully support SRv6.
Gaps:
Solutions:
Challenge: New attack vectors and security implications.
Concerns:
Mitigation:
These security considerations relate to general IPv6 network security principles.
Challenge: SRv6 standards continue to evolve.
Status:
Approach:
Challenge: Transitioning from MPLS or traditional IPv6 to SRv6.
Strategies:
Greenfield (Easiest):
Brownfield MPLS:
Brownfield IPv6:
SRv6 is positioned to become a foundational technology for next-generation networks, driven by several converging trends.
Accelerated Carrier Adoption:
Compressed SID Standardization:
Data Center Expansion:
Tooling Maturity:
IPv6-Only Networks:
AI-Driven Network Optimization:
Edge Computing Integration:
Enterprise Adoption:
Ubiquitous Network Programmability:
Internet-Scale SRv6:
MPLS Replacement:
Quantum-Safe SRv6:
Active Areas of Innovation:
1. SRv6-Aware Security:
2. In-Network Computing:
3. Cross-Layer Optimization:
4. Energy-Efficient Routing:
IETF Spring Working Group Focus:
Industry Collaboration:
Segment Routing over IPv6 (SRv6) represents a paradigm shift in network architecture, combining the source routing elegance of Segment Routing with the ubiquity and scalability of IPv6. By encoding network instructions directly into IPv6 addresses, SRv6 transforms networks into programmable platforms capable of sophisticated traffic engineering, service chaining, and network slicing—all without the complexity of traditional MPLS or overlay protocols.
Technical Advantages:
Strategic Benefits:
Deployment Reality:
Ideal Use Cases:
Consider Alternatives When:
As the networking industry accelerates toward IPv6-dominant infrastructure, SRv6 emerges as the natural evolution for traffic engineering and service delivery. While MPLS will remain relevant in brownfield environments for years to come, new network builds increasingly favor SRv6 for its simplicity, scalability, and alignment with modern architectural trends.
Organizations planning next-generation networks should evaluate SRv6 seriously, considering not just current requirements but the trajectory toward IPv6-only, cloud-native, and programmable network infrastructures. The question is no longer whether SRv6 will succeed, but how quickly it will become the dominant paradigm for advanced network services.
Understanding whether your network properly supports IPv6 is the foundation for SRv6 adoption. Modern tools like test-ipv6.run provide comprehensive testing of your IPv6 connectivity, including:
While test-ipv6.run doesn't specifically validate SRv6 capabilities, it confirms that your IPv6 infrastructure is functional—a prerequisite for SRv6 deployment. Networks scoring well on IPv6 readiness tests are well-positioned to explore SRv6's advanced capabilities.
SRv6 transforms IPv6 from a simple addressing protocol into a powerful network programming platform. For organizations ready to embrace the next generation of network architecture, SRv6 offers a compelling path forward—combining proven IPv6 technology with innovative traffic engineering and service delivery capabilities that will define networking for decades to come.
Last Updated: October 2025 Document Version: 1.0