Summary

  • On 3 September 2026, the IESG opened Last Call on revision 16 of Segment Routing IPv6 Security Considerations, with comments due on 17 September. The document is being considered as an Informational RFC; it is not approved, published or evidence of deployment.
  • SRH presence is not a reliable SRv6 admission test. A SID can be processed without an SRH, while an SRH-bearing packet may simply transit the domain. Trust exists only when destination ranges, source ranges, ingress and per-node filters, encapsulation provenance and actual hardware behaviour remain aligned.

Revision 16 begins from a familiar sentence: Segment Routing operates by default inside a trusted domain, and traffic must be filtered at its boundaries. Read casually, “trusted domain” can sound like a place. The draft gives it a more demanding meaning. It is a logical and operational construct. A host attached to the same physical network is not inside unless it has been brought under the controls; another SR instance can remain outside even when the same organisation administers both.

That definition changes the evidence needed for a security claim. A topology diagram can show an edge. A configuration repository can show an intended access list. Neither proves that the current packet path, every SID endpoint and the available forwarding hardware enforce the same boundary.

The most useful warning appears in the filtering section. Looking only for Routing Type 4 is insufficient for two opposite reasons. First, SRv6 SID processing does not always require an SRH. A complete path can be represented by one segment in the IPv6 destination address. Second, a packet with an SRH can be legitimate transit traffic that is not addressed to this SR domain. An SRH-only rule can therefore miss relevant packets and break unrelated ones.

The draft redirects attention from a conspicuous header to the domain's address contract. At ingress, a packet arriving from outside and destined to a SID inside the domain is dropped. At each SRv6-enabled node, a packet addressed to a locally instantiated SID is dropped when its source lies outside the permitted domain range. These are complementary receipts. If the edge rule is absent, the node rule can still contain exposure. If both fail, the draft describes a fail-open state in which attacks assumed to require an internal attacker may become feasible from outside.

Address planning is consequently a security dependency. The dedicated SID prefix allocated by RFC 9602 can make the boundary easier to express and audit. Other prefixes remain possible, but a scattered or overlapping SID inventory makes leakage controls more complex and increases the chance of configuration error. A reserved block is not protection by itself; it is a tractable input to protection.

Ingress encapsulation changes who authors the routing instruction. When a trusted edge imposes a new outer IPv6 header and optional SRH, internal forwarding no longer depends directly on fields supplied at the untrusted interface. Yet revision 16 is explicit that encapsulation complements boundary filtering. A packet that satisfies the wrong boundary criteria can still cross. “Encapsulated” is a provenance statement, not a universal admission verdict.

The HMAC TLV is bounded in a different way. It can protect the segment list, flags, Last Entry and the IPv6 source address with a pre-shared key. It is optional; manual distribution can encourage key reuse; replay remains possible during the key's lifetime; and the defined coverage excludes Segments Left. A valid HMAC does not show that a source was entitled to enter the domain, that every field is immutable, that the packet is fresh or that a service outcome is safe.

Middleboxes complicate the picture after admission. The active IPv6 destination changes as segments are processed, while the final destination may sit elsewhere in the SRH. A firewall that does not understand SRv6 may classify two directions as unrelated flows or apply access control to the wrong endpoint. Blanket extension-header rejection is not a cure: within an SR domain, dropping Routing Type 4 breaks the forwarding model, and a no-SRH packet can still address a SID.

Finally, policy competes for silicon. Revision 16 identifies ACL and TCAM capacity as scarce and potentially shared with VLAN scale, routes and MAC tables. An approved rule set can exceed the platform's inspection depth or table budget. If the device silently accepts what it cannot classify, the domain is fail-open even though the policy file remains correct.

The discipline from Heng Lu's work is to keep the layers separate. The Last Call is a coordination event. The draft is a proposed account of threats and mitigations. Address plans and rules are configured state. Counters, sampled packets and independent probes are observed state. Service continuity and unauthorized access are outcomes. No layer inherits the authority of the next merely because all use the word “security”.

Sources

  1. IESG Last Call announcement
  2. Revision 16 of the SRv6 security draft
  3. Datatracker record
  4. RFC 8402: Segment Routing Architecture
  5. RFC 8754: IPv6 Segment Routing Header
  6. RFC 8986: SRv6 Network Programming
  7. RFC 9602: dedicated SRv6 SID block
  8. RFC 9288: IPv6 extension-header filtering
  9. RFC 7872: IPv6 extension-header drop measurements
  10. RFC 8200: IPv6
  11. RFC 9098: IPv6 extension-header security
  12. RFC 9099: IPv6 operational security
  13. RFC 9259: OAM in the SRH
  14. RFC 4381: trusted-domain operational guidance
  15. RFC 3552: writing security considerations
  16. Heng Lu: Running-Code Primacy
  17. Heng Lu: Minimum Initial Specification
  18. Heng Lu: Reality Layers