Loading learning content...
In traditional IP networking, the source specifies only the destination—routers along the path make autonomous decisions about how to reach it. This model works well for most traffic but lacks flexibility for specialized requirements: traffic engineering, policy routing, service function chaining, and mobility.
The IPv6 Routing Header inverts this paradigm. It enables the source to specify intermediate nodes through which a packet must travel, effectively "programming" the packet's path through the network. This capability, known as source routing, is one of IPv6's most powerful—and historically controversial—features.
The history of the Routing Header is a study in protocol evolution. The original Type 0 Routing Header was deprecated due to severe security vulnerabilities. But from its ashes emerged Type 2 (for Mobile IPv6) and the revolutionary Segment Routing Header (SRH) that's transforming modern network architecture.
By the end of this page, you will understand: (1) The general Routing Header structure and processing algorithm, (2) Why Type 0 Routing Header was deprecated and the security lessons learned, (3) Type 2 Routing Header for Mobile IPv6 optimization, (4) The Segment Routing Header (SRH) and its role in modern SDN/traffic engineering, (5) How Routing Headers interact with IPsec and security policies, and (6) Practical operational considerations for Routing Header deployment.
The Routing Header carries a list of intermediate destinations that a packet should visit en route to its final destination. This mechanism enables source-controlled path selection—a capability with profound implications for traffic engineering, policy routing, and network service composition.
Core Concepts:
General Routing Header Format:
IPv6 Routing Header - General Format═══════════════════════════════════════════════════════════════════════════ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Next Header | Hdr Ext Len | Routing Type | Segments Left |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |. .. Type-Specific Data .. .| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Field Definitions:═══════════════════════════════════════════════════════════════════════════ Next Header (8 bits): - Identifies the type of header immediately following the Routing Header - Values: TCP (6), UDP (17), ICMPv6 (58), Destination Options (60), etc. Hdr Ext Len (8 bits): - Length of the Routing Header in 8-octet units, NOT including first 8 octets - Total length = (Hdr Ext Len + 1) × 8 bytes Routing Type (8 bits): - Identifies the variant of Routing Header - Currently defined types: Type 0: Deprecated (RFC 5095) - DO NOT USE Type 2: Mobile IPv6 (RFC 6275) Type 3: RPL Source Route Header (RFC 6554) Type 4: Segment Routing Header (RFC 8754) Segments Left (8 bits): - Number of explicitly listed intermediate nodes still to be visited - Decremented by 1 at each intermediate node - When 0, packet has reached final destination - Maximum value 255 = up to 255 intermediate nodesUnlike Hop-by-Hop Options which are processed by every router, the Routing Header is processed only by nodes explicitly listed in the header—AND by the final destination. Standard routers forward packets with Routing Headers without examining them, based solely on the IPv6 Destination Address.
Understanding how nodes process Routing Headers is essential for comprehending source routing behavior. The algorithm differs based on whether the node is an intermediate point or the final destination.
Processing Flow Chart:
Routing Header Processing Algorithm═══════════════════════════════════════════════════════════════════════════ When a node receives a packet with a Routing Header: ┌─────────────────────────────────────────────────────────────────────────┐│ RECEIVE PACKET WITH ROUTING HEADER │└─────────────────────────────────────────────────────────────────────────┘ │ ▼ ┌───────────────────────────────────┐ │ Is IPv6 Destination Address │ │ one of MY addresses? │ └───────────────────────────────────┘ │ │ YES NO │ │ ▼ ▼ ┌──────────────────┐ ┌────────────────────────┐ │ Process Routing │ │ Forward packet based │ │ Header │ │ on IPv6 Destination │ └──────────────────┘ │ (do NOT examine RH) │ │ └────────────────────────┘ ▼ ┌──────────────────────────────────────────────┐ │ Check Routing Type - is it recognized? │ └──────────────────────────────────────────────┘ │ │ YES NO │ │ ▼ ▼ ┌──────────────────┐ ┌────────────────────────┐ │ Check Segments │ │ If Segments Left = 0: │ │ Left value │ │ Ignore RH, continue │ └──────────────────┘ │ Else: │ │ │ Send ICMP Parameter │ │ │ Problem (type 0) │ │ └────────────────────────┘ ▼ ┌──────────────────────────────────────────────┐ │ Segments Left = 0? │ └──────────────────────────────────────────────┘ │ │ YES NO │ │ ▼ ▼ ┌──────────────────┐ ┌────────────────────────┐ │ Continue to next │ │ 1. Decrement Segments │ │ header (RH │ │ Left by 1 │ │ processing done) │ │ 2. Compute index into │ └──────────────────┘ │ address list │ │ 3. Swap addresses: │ │ - Copy next segment │ │ to IPv6 Dest │ │ - (behavior varies │ │ by routing type) │ │ 4. Decrement Hop Limit │ │ 5. Forward packet │ └────────────────────────┘Address Swapping Visualization:
The key mechanism of source routing is the address swap. Let's trace a packet through a three-segment path:
Address Swapping Through Source Route═══════════════════════════════════════════════════════════════════════════ Scenario: Source S wants to send packet to Destination D via waypoints W1, W2 Initial state (at Source S): IPv6 Header: Source: S Destination: W1 ← First waypoint Routing Header: Segments Left: 2 Addresses: [W2, D] ← Remaining waypoints + final destination At W1 (first waypoint, Segments Left was 2): 1. W1 sees it's the Destination, processes Routing Header 2. Segments Left = 2 > 0, so swap addresses: - New IPv6 Destination = W2 (from RH address list) - Segments Left becomes 1 3. Forward packet to W2 After processing: IPv6 Header: Source: S Destination: W2 ← Second waypoint Routing Header: Segments Left: 1 Addresses: [W2, D] ← (W2 position now "consumed") At W2 (second waypoint, Segments Left was 1): 1. W2 sees it's the Destination, processes Routing Header 2. Segments Left = 1 > 0, so swap addresses: - New IPv6 Destination = D (final destination) - Segments Left becomes 0 3. Forward packet to D After processing: IPv6 Header: Source: S Destination: D ← Final destination Routing Header: Segments Left: 0 ← No more waypoints Addresses: [W2, D] At D (final destination, Segments Left = 0): 1. D sees it's the Destination, processes Routing Header 2. Segments Left = 0, processing complete 3. Pass to upper layer (TCP, UDP, etc.)Notice that throughout the entire journey, the Source Address in the IPv6 header never changes—it remains the original sender's address. Only the Destination Address is swapped at each waypoint. This preserves end-to-end source identification while enabling path control.
The original Routing Header Type 0 (RH0) was designed for full source routing—allowing a sender to specify an arbitrary list of intermediate nodes. It seemed like a useful feature but became one of IPv6's most significant security vulnerabilities.
Type 0 Routing Header Structure:
Type 0 Routing Header (DEPRECATED - DO NOT USE)═══════════════════════════════════════════════════════════════════════════ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Next Header | Hdr Ext Len | Routing Type=0| Segments Left |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Reserved |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |+ +| Address [1] |+ (128 bits) +| |+ +| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |+ +| Address [2] |+ (128 bits) +. ... .. .| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |+ +| Address [n] |+ (128 bits) +| |+ +| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Attack Vector:
Type 0 Routing Header enabled a devastating amplification attack. An attacker could force a packet to ping-pong between two nodes repeatedly, with each traversal counted against both nodes' bandwidth:
Type 0 Routing Header Amplification Attack═══════════════════════════════════════════════════════════════════════════ Attacker constructs packet with: - Destination: Victim_A - Routing Header addresses: [Victim_B, Victim_A, Victim_B, Victim_A, ...] (repeat up to 88 times in single RH0) Result: Packet travels: → Victim_A → Victim_B → Victim_A → Victim_B → ... One small packet from attacker causes: - 88+ transmissions between victims - Bandwidth amplification factor of 88x or more - CPU load at both victims for processing - Attack source is hidden (victims see each other as source) Multiple packets create: - DDoS with minimal attacker bandwidth - Victims attack each other - Very difficult to trace original attackerRFC 5095 (December 2007) formally deprecated Type 0 Routing Header. All IPv6 implementations MUST NOT generate RH0 headers, and SHOULD by default drop packets containing them. This deprecation was a rare case of removing deployed protocol functionality due to security concerns.
Lessons Learned:
The RH0 debacle taught the networking community important lessons:
The Type 2 Routing Header was designed specifically for Mobile IPv6, enabling packets to reach mobile nodes efficiently through route optimization. Unlike the deprecated Type 0, Type 2 has strict constraints that prevent amplification attacks.
Mobile IPv6 Route Optimization Problem:
When a mobile node (MN) moves to a foreign network, it gets a temporary "care-of address" (CoA). Without route optimization, all traffic would triangle-route through the home agent:
Mobile IPv6 Route Optimization═══════════════════════════════════════════════════════════════════════════ WITHOUT Route Optimization (triangle routing):──────────────────────────────────────────────────────────────────────────Correspondent Node (CN) → Home Agent (HA) → Mobile Node (MN at CoA) - CN sends to MN's home address - Home Agent intercepts, tunnels to CoA - Inefficient: packets travel extra distance through HA WITH Route Optimization (using Type 2 RH):──────────────────────────────────────────────────────────────────────────Correspondent Node (CN) → Mobile Node (MN at CoA) directly Packet structure: ┌────────────────────────────────────────────────────────────────┐ │ IPv6 Header │ │ Source: CN │ │ Destination: CoA (care-of address, where MN currently is) │ ├────────────────────────────────────────────────────────────────┤ │ Type 2 Routing Header │ │ Routing Type: 2 │ │ Segments Left: 1 │ │ Home Address: MN's permanent home address │ ├────────────────────────────────────────────────────────────────┤ │ Upper Layer (TCP/UDP) │ │ Sees: Source=CN, Destination=Home Address │ │ (Transport layer uses home address for connection identity) │ └────────────────────────────────────────────────────────────────┘ Type 2 Routing Header Format:═══════════════════════════════════════════════════════════════════════════ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Next Header |Hdr Ext Len=2 | Routing Type=2| Segments Left |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Reserved |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |+ +| |+ Home Address +| (128 bits) |+ +| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Key Constraints (preventing RH0-style attacks): - Segments Left MUST be 1 (exactly one address) - The address MUST be the mobile node's home address - Only valid in Mobile IPv6 context with binding cache entryType 2's safety comes from its strict constraints: it contains exactly one address (Segments Left must be 1), and that address must be the mobile node's home address, verified against the binding cache. An attacker can't insert arbitrary addresses or create amplification loops—the header serves only its specific Mobile IPv6 purpose.
The Segment Routing Header (SRH), Routing Header Type 4, represents a fundamental evolution in network architecture. It enables Software-Defined Networking (SDN) principles in the IPv6 data plane, allowing centralized controllers or source nodes to program packet paths with unprecedented granularity.
What is Segment Routing?
Segment Routing encodes a sequence of instructions (segments) in the packet header. Each segment can represent:
The packet follows these instructions, visiting each segment in order.
Segment Routing Header (SRH) - Type 4 Format═══════════════════════════════════════════════════════════════════════════ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Next Header | Hdr Ext Len | Routing Type=4| Segments Left |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Last Entry | Flags | Tag |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |+ +| Segment List [0] |+ (128 bits) +| (last segment) |+ +| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |+ +| Segment List [1] |+ (128 bits) +| |+ +| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+. ... .+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |+ +| Segment List [n] |+ (128 bits) +| (first segment) |+ +| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+// //// Optional TLV Objects (variable) //// //+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Field Definitions:═══════════════════════════════════════════════════════════════════════════ Last Entry (8 bits): - Index of the last entry in the Segment List (0-based) - Number of segments = Last Entry + 1 Flags (8 bits): - Reserved bits for future use (currently unused) Tag (16 bits): - Packet identification for correlating mirrored/replicated flows Segment List (128 bits each): - Ordered list of segment identifiers (SIDs) - Stored in REVERSE order: [0] = last, [n] = first - Segments Left points to current active segment Optional TLVs: - Additional metadata (padding, HMAC for security, etc.)Segment Routing Use Cases:
| Use Case | How SRH Enables It | Benefit |
|---|---|---|
| Traffic Engineering | Path encoded in packet; no per-flow state in network | Deterministic paths without signaling protocols |
| Fast Reroute | Backup path encoded as alternative segment list | Sub-50ms failover without control plane convergence |
| Service Function Chaining | Service functions as segments in the path | Flexible, ordered service delivery |
| Network Slicing | Segment IDs identify slice boundaries | Isolation and QoS differentiation |
| OAM and Telemetry | Segments trigger measurement/reporting | In-band performance monitoring |
Segment Routing can use either IPv6 (SRv6 with SRH) or MPLS labels (SR-MPLS) as the underlying data plane. SRv6's advantage is the enormous 128-bit segment ID space, enabling network programming patterns impossible with MPLS's 20-bit labels. SRv6 segments can encode instructions, arguments, and even metadata within the single 128-bit SID.
Understanding SRH processing requires grasping the reverse-order segment list and the Segments Left pointer mechanism.
Segment List Ordering:
The segment list is stored in reverse order—the first segment to visit is at the highest index, the last segment at index 0. This enables efficient processing: Segments Left directly indexes into the array.
SRH Processing Walk-Through═══════════════════════════════════════════════════════════════════════════ Path: Source → Segment_A → Segment_B → Segment_C → Destination Initial packet at Source:┌─────────────────────────────────────────────────────────────────────────┐│ IPv6 Header ││ Source: Source_Addr ││ Destination: Segment_A ← Next hop is first segment │├─────────────────────────────────────────────────────────────────────────┤│ SRH (Type 4) ││ Segments Left: 3 ││ Last Entry: 3 ││ Segment List: ││ [0] = Destination ← Last segment (final destination) ││ [1] = Segment_C ││ [2] = Segment_B ││ [3] = Segment_A ← First segment (Segments Left points here) │└─────────────────────────────────────────────────────────────────────────┘ At Segment_A (Segments Left = 3):────────────────────────────────────────────────────────────────────────────1. Segment_A is the destination, examines SRH2. Segments Left > 0, so: a. Decrement Segments Left: 3 → 2 b. Copy Segment List[2] to IPv6 Destination: Segment_B c. Forward packet toward Segment_B After processing: IPv6 Destination: Segment_B Segments Left: 2 At Segment_B (Segments Left = 2):────────────────────────────────────────────────────────────────────────────1. Segment_B is the destination, examines SRH2. Segments Left > 0, so: a. Decrement Segments Left: 2 → 1 b. Copy Segment List[1] to IPv6 Destination: Segment_C c. Forward packet toward Segment_C After processing: IPv6 Destination: Segment_C Segments Left: 1 At Segment_C (Segments Left = 1):────────────────────────────────────────────────────────────────────────────1. Segment_C is the destination, examines SRH2. Segments Left > 0, so: a. Decrement Segments Left: 1 → 0 b. Copy Segment List[0] to IPv6 Destination: Destination c. Forward packet toward Destination After processing: IPv6 Destination: Destination Segments Left: 0 At Destination (Segments Left = 0):────────────────────────────────────────────────────────────────────────────1. Destination is the destination, examines SRH2. Segments Left = 0, SRH processing complete3. Pass packet to upper layer protocolNodes not listed in the segment list forward packets based solely on the IPv6 Destination Address—they never examine the SRH. This means standard IPv6 routers between segments can forward SRH packets at full line rate without understanding Segment Routing.
Source routing inherently raises security concerns—allowing external sources to dictate internal network paths can enable reconnaissance, traffic interception, and policy evasion. Modern Routing Header designs incorporate specific security measures.
SRH Security Mechanisms:
Interaction with IPsec:
When IPsec protects packets with Routing Headers, special handling is required because the IPv6 Destination Address changes at each segment:
| IPsec Mode | Handling | Considerations |
|---|---|---|
| Transport Mode AH | AH computed with Destination = final destination (from RH) | Segments must not be included in authentication |
| Transport Mode ESP | ESP protects upper-layer only; RH manipulation visible | Path changes not protected |
| Tunnel Mode | Outer header subject to RH; inner protected header unchanged | Tunneling through SR domain works cleanly |
Network operators should carefully consider which Routing Header types to permit at network boundaries. A common practice is to drop all Routing Headers at the edge except those explicitly required (e.g., Type 4 for SRv6 if deployed internally), preventing external parties from influencing internal routing decisions.
We've completed a comprehensive examination of the IPv6 Routing Header ecosystem—from the cautionary tale of Type 0 to the revolutionary capabilities of Segment Routing. Let's consolidate the essential knowledge:
What's Next:
The next page examines the Fragment Header—the extension header that handles IPv6's unique approach to fragmentation. Unlike IPv4 where any router can fragment, IPv6 fragments only at the source, with profound implications for path MTU discovery and efficient packet handling.
You now possess comprehensive understanding of IPv6 Routing Headers—from the historical lessons of RH0's deprecation to the modern capabilities of Segment Routing. This knowledge is essential for understanding IPv6's role in SDN, traffic engineering, and next-generation network architectures.