Skip to content

RFC 8754 - IPv6 Segment Routing Header (SRH)

Field Value
Title IPv6 Segment Routing Header (SRH)
Authors C. Filsfils, D. Dukes, S. Previdi, J. Leddy, S. Matsushima, D. Voyer
Date March 2020
Status Proposed Standard
Link datatracker.ietf.org/doc/rfc8754

Summary

RFC 8754 defines the Segment Routing Header (SRH), an IPv6 Routing Header of type 4. The SRH is the core data-plane mechanism that carries the ordered list of segments (instructions) that a packet must traverse in an SRv6 network.

Key Concepts

SRH Format

The SRH is an IPv6 extension header containing:

  • Segments Left (SL) - Index pointing to the current active segment
  • Last Entry - Index of the last element in the segment list
  • Flags - Currently reserved
  • Tag - Used for packet grouping
  • Segment List - Array of 128-bit SRv6 SIDs in reverse order
 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Last Entry   |    Flags      |              Tag              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|            Segment List[0] (128-bit IPv6 address)             |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            ...                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Packet Processing

  1. Source node creates the SRH with the full segment list
  2. Segments Left is initialized to point to the first segment to process
  3. At each SR-capable node, SL is decremented and the next segment is copied to the IPv6 Destination Address
  4. When SL reaches 0, the packet has traversed the complete segment list

Security Considerations

The SRH supports an HMAC TLV (Type-Length-Value) for authentication, which allows verification that the SRH was applied by an authorized source and has not been tampered with.

Key Sections

Section Topic Description
2 SRH Format Defines the full header layout including Next Header, Hdr Ext Len, Routing Type (4), Segments Left, Last Entry, Flags, Tag, and the Segment List array
3 SRH and SRv6 Explains how SRH is used in SRv6 domain, packet flow through segment endpoints, and the relationship between the Destination Address and SL pointer
4 SRH Processing Specifies source node creation, transit node forwarding (SRH is not examined), and SR segment endpoint processing (SL decrement, DA update)
4.1 Source SR Node Packet origination: building the segment list in reverse order, setting SL = n-1, copying Segment List[SL] to DA
4.2 Transit Node Transit nodes forward based on DA only -- they do not inspect or process the SRH
4.3 SR Segment Endpoint SL is decremented; Segment List[SL] is copied to DA; packet is forwarded toward the new DA
5 Security Considerations Threat model analysis, domain trust boundaries, and the HMAC TLV mechanism for SRH authentication
5.1 HMAC TLV Keyed hash-based authentication using HMAC-SHA-256 truncated to 256 bits; prevents SRH insertion by unauthorized sources
5.2 Deployment Models Trusted domain (infrastructure filtering), HMAC-based (per-SRH verification), and combined approaches
6 IANA Considerations Routing Type 4 registration, SRH Flags registry, SRH TLV Types registry

Upper-Layer Header Processing

RFC 8754 Section 4.1.1 defines the Upper-Layer Header interaction. When the final segment has been reached (SL = 0) and the next header is an upper-layer protocol (TCP, UDP, ICMPv6), the SR endpoint node must process the upper-layer header using the packet's actual destination address. This is critical for correct socket demultiplexing and checksum validation.

Common Pitfalls

Transit nodes do NOT process the SRH. A common misconception is that every router on the path examines the SRH. In reality, only SR segment endpoint nodes (those whose address appears in the segment list) inspect and process the SRH. Transit nodes forward based solely on the IPv6 Destination Address using standard IPv6 forwarding.

Segment list is in reverse order. The segment list is encoded with the last segment at index 0 and the first segment at the highest index. Segments Left starts at the value pointing to the first segment to visit and decrements toward 0. This reverse encoding is a frequent source of confusion during implementation and debugging.

SRH may be present with SL = 0. After processing the final segment, the SRH remains in the packet with SL = 0. PSP (Penultimate Segment Pop) behavior from RFC 8986 can remove it, but the base SRH spec does not require removal.

HMAC does not encrypt. The HMAC TLV provides authentication and integrity, not confidentiality. The SRH contents including the full segment list remain visible in cleartext. For confidentiality, IPsec or other encryption must be used in conjunction.

Document Relationship Description
RFC 9800 Extension SRv6 SID compression via the NEXT-C-SID and REPLACE-C-SID flavors, reducing SRH overhead
draft-ietf-spring-srv6-security Security Analysis Detailed security analysis of the SRv6 data plane including SRH-specific threats
RFC 8986 Companion Defines endpoint behaviors (End, End.X, etc.) that process the SRH
RFC 9259 Uses SRH OAM procedures that leverage SRH for ping and traceroute in SRv6