Summary

  • Posted on 7 September 2026, draft-ietf-spring-sid-as-source-address-00 is now a SPRING working-group document. Adoption makes it a work item; it does not make the Internet-Draft an RFC or verify the document’s implementation claims.
  • The proposal replaces an ingress PE loopback in the outer IPv6 source field with the corresponding service SID. That can make forward and reverse outer tuples symmetric enough for a stateful firewall to associate them.
  • The same change weakens any assumption that the source field identifies one physical origin. The draft itself warns about reduced accountability, internal SID spoofing and firewall session-table churn.

The failure begins with two individually sensible conventions. An SRv6 ingress PE commonly encapsulates customer traffic with its loopback address as the outer IPv6 source. The far service is represented by an egress VPN SID, either as the destination in a best-effort packet or as the final entry of a Segment Routing Header. A firewall aware of SRv6 can recover that final destination and build state from the outer tuple.

On the return path, the other PE supplies its own loopback as source and the first PE’s service SID becomes the final destination. The addresses do not reverse cleanly. A firewall that expects the return source to equal the original destination can classify two halves of one customer exchange as unrelated flows. Legitimate return traffic or an ICMP response may be dropped even though routing behaved exactly as configured.

The 7 September draft proposes semantic symmetry. Once an ingress PE has identified the L3 VPN context, it uses the service SID that the far end would expect as the outer source address. In the opposite direction, the peer does the same. The address pair can now reverse across the firewall’s state key. When a SID sits in the source field it is treated as an ordinary IPv6 address; it does not invoke its endpoint behaviour there.

That is a real engineering gain, but it is also an exchange. The source field stops being a straightforward locator for the ingress PE and becomes a service classifier selected by that PE. A session match can therefore prove that a packet fit an existing state-table relation. It cannot, without separate evidence, prove which chassis emitted it, which customer caused it, whether that origin was entitled to use the SID or whether the address was authentic.

The draft makes the trade-off visible through granularity. A per-VRF SID is cheap to select because the incoming attachment already identifies the VRF, but every customer edge in that VRF can appear under the same source. A per-attachment-circuit SID preserves a finer boundary without another lookup. A per-prefix SID can be finer still, but requires a source-address lookup in the VRF and may burden forwarding. The prescribed preference for the most granular available match—per-prefix, then per-AC, then per-VRF—does not erase the choice. It tells leadership where attribution quality and packet-processing cost meet.

The security section refuses to let symmetry become trust. Routable locator prefixes mean an internal node may be able to originate a forged source that resembles a service SID. Programmable SIDs can also create rapid churn in stateful appliances, consuming session capacity, disturbing aging and possibly overflowing tables. The draft therefore calls for strict controls over which service flows may use a SID as source. Anti-spoofing, origin authorization and state budgets are not delivered by the tuple rewrite.

ICMP has a separate evidentiary value. An SRv6 ping may use an End SID as outer source to test whether the return path works. A transit node generating an error may use the SID associated with the failed processing step, helping the head-end locate the relevant node and segment. For VPN traffic, the ingress PE still has to process the embedded upper-layer header so the inner ICMP reaches the customer edge. A useful diagnostic locator is not a cryptographic attestation from the reporting node, and it is not a root-cause verdict.

Compression adds another dependency. RFC 9800 can encode a compressed segment list so that the last routing-header element differs from the address ultimately received, or place compressed instructions in the destination without an SRH. The new draft recommends leaving the final destination uncompressed and carrying it as the last SRH element. Otherwise a firewall may not recover the endpoint semantic on which its symmetric state depends. A correct source choice at both PEs cannot rescue an intermediary that parses a different destination.

The implementation row deserves equal precision. It says New H3C CR16000 and CR19000 routers running version 7.1.119 or later implement all sections, labels maturity as production and ties coverage to predecessor revision 13. It also records no specific implementation experience. Following RFC 7942, the draft expressly says contributor-supplied implementation descriptions are not verified by the IETF and do not imply endorsement. This is useful running-code evidence for a proposal; it is not an independent conformance report, interoperability result or installed-base measurement.

That distinction reflects Heng Lu’s discipline. Running code checks abstract design, while evidence remains bounded to the proposition actually observed. The working-group label is coordination state. The PE configuration is intended state. A packet capture and firewall entry are observed state. Customer delivery and defensible attribution are outcomes. A green indicator in one layer cannot author the next.

The adoption event is therefore worth attention precisely because the draft exposes its own price. It offers a practical answer to false drops caused by address asymmetry. Operators should evaluate it as a controlled remapping of packet semantics, not as a new identity primitive. The useful receipt must join the source-SID allocation, authorized origin, exact selection granularity, firewall parser, state generation, packet observation and customer result. Only then can “the return flow matched” remain true without becoming “we know who sent it.”

Sources

  1. IETF Datatracker — SID as source address in SRv6
  2. Working-group draft 00
  3. Datatracker — predecessor draft
  4. Predecessor revision 13
  5. SRv6 Security Considerations, revision 16
  6. RFC 8402 — Segment Routing Architecture
  7. RFC 8754 — IPv6 Segment Routing Header
  8. RFC 8986 — SRv6 Network Programming
  9. RFC 9252 — BGP Overlay Services over SRv6
  10. RFC 9259 — OAM in SRv6
  11. RFC 9800 — Compressed SRv6 Segment Lists
  12. RFC 7942 — Implementation Status Sections
  13. Heng Lu — Running-Code Primacy
  14. Heng Lu — Minimum Initial Specification
  15. Heng Lu — Reality Layers