IPv6 Segment Routing Header (SRH)
updated by
- rfc-9800 — Compressed SRv6 Segment List Encoding
Extracted elements (30)
A reduced SRH omits the first segment of the SR Policy (since it is already in the DA of the IPv6 header) and sets Last Entry to n-2, saving space when the source does not need to preserve the full SID list in the header.
The HMAC Key ID field is opaque, identifying both the pre-shared key and the hash algorithm, which allows simultaneous support for multiple hash algorithms (SHA-256, SHA3-256, etc.) and enables key rollover by using two key IDs during transition.
The TLV highest-order bit (bit 0) encodes mutability en route: 0 means TLV data does not change en route, 1 means it may change. This design allows the SRH source to build headers with predictable immutability guarantees without requiring per-TLV-type processing rules at every node.
ICMP error packets within the SR domain may contain an SRH where the destination address changes at each segment. To determine the ultimate destination for protocol error handlers, implementations should walk extension headers to the SRH and use Segment List[0] as the destination address of the invoking packet.
When the FIB entry at an SR segment endpoint represents a local interface but is not instantiated as an SRv6 SID, the node processes per RFC 8200 routing header rules: if Segments Left is zero, ignore the SRH and proceed to the next header; if Segments Left is non-zero, discard and send ICMP Parameter Problem pointing to the unrecognized Routing Type.
An implementation adding or parsing TLVs MUST support PAD TLVs. Unrecognized TLV Types MUST be ignored on receipt.
An implementation supporting HMAC MUST implement SHA-2 (FIPS 180-4) in its SHA-256 variant.
For interdomain packets, the SR source node MUST impose a flow label computed based on the inner packet per RFC 6438. At any transit node within an SR domain, the flow label MUST be used to calculate the ECMP hash toward the destination address.
For intradomain packets, the SR source node SHOULD impose a flow label as described in RFC 6437 to assist ECMP load balancing at transit nodes incapable of computing a 5-tuple beyond the SRH.
If HMAC verification fails, an ICMP error message (parameter problem, error code 0, pointing to the HMAC TLV) SHOULD be generated (but rate limited) and logged, and the packet SHOULD be discarded.
Ingress filtering of IPv6 source addresses as recommended in BCP 38 (RFC 2827) SHOULD be used at SR domain borders.
New SIDs defined in the future MUST specify the mutability properties of the Flags, Tag, and Segment List and indicate how HMAC TLV verification works.
Transit nodes MUST NOT inspect the Routing Extension Header (and therefore the SRH) and MUST forward the packet toward the Destination Address according to the IPv6 routing table, as only the node corresponding to the DA is allowed to inspect the routing header.
While processing TLVs at a segment endpoint, TLVs MUST be fully contained within the SRH as determined by the Hdr Ext Len. Detection of TLVs exceeding this boundary results in an ICMP Parameter Problem, Code 0, message to the Source Address and the packet being discarded.
Within an SR domain, well-known MTU mitigation techniques are RECOMMENDED, such as deploying a greater MTU value within the SR domain than at the ingress edges.
The Last Entry field contains the zero-based index of the last element in the Segment List. The Segment List is encoded in reverse order: Segment List[0] holds the last segment of the SR Policy, Segment List[1] the penultimate, and so on.
The SR source node sets the IPv6 DA to the first segment (active segment), sets Segments Left to n-1, and encodes the SR Policy in reverse order in the Segment List. If the SR Policy has a single segment and no TLVs or flags are needed, the SRH MAY be omitted.
The Tag field (16-bit) marks a packet as part of a class or group of packets. When not used at the source, it MUST be set to zero on transmission; when not used during SRH processing, it SHOULD be ignored.
When the upper-layer header of a packet matching a locally instantiated SRv6 SID is IPv4 or IPv6 and local configuration permits, the node performs IPv6 decapsulation and resubmits the inner packet. Otherwise it sends an ICMP Parameter Problem with error code 4 ('SR Upper-layer Header Error').
This document creates the 'Segment Routing Header Flags' IANA registry (8 bits, IETF Review procedure) for SRH flag bits, with all 8 bits currently marked Unused (U).
This document creates the 'Segment Routing Header TLVs' IANA registry (8-bit codepoint, IETF Review). Values 0–127 are for TLVs that do not change en route; 128–255 for TLVs that may change en route. Initial entries: 0 (Pad1), 4 (PadN), 5 (HMAC TLV), with 1–3, 6, 127, 255 reserved and 124–126, 252–254 for experimentation.
This document registers Routing Type value 4 ('Segment Routing Header (SRH)') in the IANA 'IPv6 Parameters' 'Routing Types' subregistry, and error code 4 ('SR Upper-layer Header Error') in the ICMPv6 'Type 4 - Parameter Problem' registry.
ICMPv6 error message generation can be abused for denial-of-service attacks via back-to-back error-causing packets. Implementations must follow RFC 4443 Section 2.4 ICMPv6 rate-limiting to mitigate this.
The SR domain does not rely on the Authentication Header (AH) to secure the SRH because the SR domain is a trusted domain where the SR source is trusted to add an SRH and segments are advertised via a secure control plane. Use of SRH with AH is not defined in this document.
The SR domain must enforce two levels of access control: (1) edge nodes drop any incoming external packet destined to a SID within the SR domain using an inbound IACL, and (2) each SR node drops packets destined to its local SIDs arriving from source addresses outside the SR domain. Failure to implement these controls exposes the domain to the source-routing attacks documented in RFC 5095.
The SRH is unencrypted and may contain SIDs of intermediate SR nodes. If packets can be snooped within the SR domain, the SRH may reveal topology, traffic flows, and service usage.
SRH processing at a segment endpoint: if Segments Left is zero, proceed to the next header. Otherwise, validate Last Entry and Segments Left bounds (send ICMP Parameter Problem on violation), decrement Segments Left, copy Segment List[Segments Left] to the IPv6 DA, check Hop Limit (send ICMP Time Exceeded if ≤1), decrement Hop Limit, and resubmit the packet.
The HMAC TLV (Type 5, alignment 8n) contains: Type (8-bit), Length (8-bit), D flag (1-bit indicating reduced Segment List), RESERVED (15-bit, MUST be 0), HMAC Key ID (4 octets, opaque), and HMAC (variable, multiples of 8 octets, at most 32 octets).
The Pad1 TLV (Type 0) is a single-byte padding element with no Length field. The PadN TLV (Type 4) carries a Length field (0–5) and variable padding bytes that MUST be set to 0 on transmission and ignored on receipt.
The Segment Routing Header (SRH) uses Routing Type 4 and contains: Next Header (8-bit), Hdr Ext Len (8-bit), Routing Type (8-bit, value 4), Segments Left (8-bit), Last Entry (8-bit, zero-based index of last segment), Flags (8-bit), Tag (16-bit), and Segment List[0..n] (each a 128-bit IPv6 address), followed by optional TLVs.