| Internet-Draft | Binding SID Header Replacement | November 2026 |
| Liu & Lin | Expires 6 May 2027 | [Page] |
This document specifies a mechanism for replacing the preceding Segment Routing (SR) encapsulation upon the expansion of a Binding Segment Identifier (BSID) in SRv6. The current SR architecture, as defined in RFC 8402 (Segment Routing Architecture), RFC 8754 (IPv6 Segment Routing Header (SRH)), and RFC 8986 (Segment Routing over IPv6 (SRv6) Network Programming), mandates that the entire SR policy remains intact when a BSID is expanded: the binding node encapsulates the packet into a further outer IPv6 header with a new SRH, preserving all preceding encapsulations as the inner payload. This imposes significant overhead on scenarios requiring strict domain isolation, resource pooling, and future 6G core networks. This proposal, termed "Binding SID Header Replacement" (BSHR), challenges the existing standard by allowing the binding node to substitute the incoming SR encapsulation with a new one, via a decapsulation-plus-re-encapsulation sequence. This mechanism offers benefits in reducing overhead, enforcing security boundaries, and enabling new use cases. The document discusses the technical rationale, potential risks including path validation failures, and specifies a new SRv6 Endpoint behavior, End.B6.Replace, to realize the mechanism.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 6 May 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Segment Routing (SR) leverages the source routing paradigm to steer packets through a network. A Binding SID (BSID) represents a segment that is bound to an SR Policy, effectively acting as a macro-instruction that triggers the imposition of a new SR policy onto the packet [RFC9256]. In the SRv6 data plane, when a packet matches a BSID, the binding node encapsulates the packet into a new IPv6 header with a new SRH carrying the policy's segment list (the End.B6.Encaps behavior [RFC8986]), while the original packet, including any existing SR header, is preserved as the inner payload.¶
This behavior, while simple and robust, presents limitations:¶
This document proposes a new SRv6 Endpoint behavior, called "End.B6.Replace", which implements a mechanism termed "Binding SID Header Replacement" (BSHR). When a BSID is processed, the node is instructed to discard the incoming SR header(s) and replace them with a new set of SR headers derived from the BSID policy. This effectively "resets" the SR context at the binding point. This document specifies the BSHR behavior for the SRv6 data plane; its applicability to the SR-MPLS data plane is discussed in Section 6.3.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses the terminology defined in [RFC8402], [RFC8754], [RFC8986], and [RFC9256].¶
The current BSID processing model for SRv6 is defined by the End.B6.Encaps behavior in [RFC8986]: upon receiving a packet whose Destination Address matches a local BSID, the node encapsulates the packet into a new IPv6 header with a new SRH carrying the segment list of the bound policy. The explicit path is then processed from the new SRH. The result is a nested IPv6-in-IPv6 structure.¶
Consider a scenario involving three domains: A, B, and C, as illustrated in Figure 1. A packet originates in Domain A, encapsulated with an SRH whose segment list (A2, ..., B1, VPN2) steers the packet to the border node B1, followed by the VPN SID (VPN2) of the egress PE (PE2) in Domain C. At B1, a BSID instructs the packet to traverse Domain B to reach border node C1. Under the current standard, the BSID expansion encapsulates the packet in a further outer IPv6 header with a new SRH (the inner packet's destination address is updated to the next segment, VPN2, as part of the standard End processing before encapsulation). The packet traversing Domain B thus carries two complete IPv6+SRH encapsulations: Domain A's (A1->B1) as the inner payload, and Domain B's (B1->C1) on the outside. Each additional domain adds another full outer IPv6 header (40 bytes) plus its SRH; for example, with a three-segment policy per domain, each domain adds 96 bytes of per-domain encapsulation overhead. In a 6G core network slice, where latency and bandwidth are premium, these extra bytes on every packet are non-trivial.¶
Domain A Domain B Domain C
(opaque) (opaque) (opaque)
+-----------+ +-----------+ +-----------+
| | | | | |
| A1-------B1(BSID)-------------C1 |
+-----------+ +-----------+ +-----------+
(a) Packet in Domain A:
+--------------------------+
| IPv6 DA = A2 | Domain A's encapsulation
| SRH (A2, ..., B1, VPN2) |
+--------------------------+
| Payload |
+--------------------------+
(b) Packet in Domain B (after BSID expansion at B1):
+--------------------------+ \
| IPv6 DA = B2 | |
| SRH (B2, B3, ..., C1) | | Domain B's new encapsulation
+--------------------------+ /
| IPv6 DA = VPN2 | \
| SRH (A2, ..., B1, VPN2) | | Domain A's encapsulation
+--------------------------+ / (preserved inside, untouched)
| Payload |
+--------------------------+
More critically, the encapsulated inner packet from Domain A is carried, untouched, across Domain B and is exposed again upon decapsulation at the egress of Domain B: it contains the internal segment identifiers of Domain A. If Domain B is a separate administrative entity (e.g., a neutral host or a different operator), it is required to carry header information that is irrelevant to its forwarding decisions, and the downstream domain is exposed to the origin domain's internal SIDs. This is a security and efficiency concern.¶
This document proposes an extension to the BSID processing rules, specified as a new SRv6 Endpoint behavior, "End.B6.Replace" (Section 6.1), instantiated on the BSID itself. The behavior is advertised together with the SRv6 SID using existing SID advertisement mechanisms; no new flags or encodings are introduced in the SR Policy signaling.¶
When a node receives a packet whose Destination Address matches a BSID instantiated with the End.B6.Replace behavior, the node MUST perform the following actions instead of the default encapsulation action (the normative specification is given in Section 6.1):¶
The resulting packet has a single, clean SR context for the next domain. The original SR context is completely discarded.¶
Architecturally, the Replace operation is not an in-transit modification of a Segment Routing header. It is decomposed into two standard, well-understood operations executed back-to-back at the binding node: the binding node terminates the incoming SR context, and it then acts as a fresh encapsulating node and originates the SR context associated with the BSID policy.¶
This framing preserves the architectural principle that an SRH is imposed by the node that originates the corresponding SR context: the new SRH is not "edited into" the packet in transit; rather, the binding node terminates the previous SR context and originates a new one. The End.B6.Replace behavior is thus the atomic realization of this decapsulation-plus-re-encapsulation sequence, and the resulting packet is indistinguishable from one freshly encapsulated at the binding node. This framing also clarifies the validation semantics discussed in Section 7.1: the replaced header starts a new validation context rather than corrupting an existing one.¶
In a multi-domain SRv6 deployment, the origin domain's segment list is not relevant to the transit domain. By replacing the header at the domain boundary, we achieve:¶
This section specifies the End.B6.Replace behavior (the data plane realization of BSHR), its control-plane instantiation, and its applicability to the SR-MPLS data plane.¶
End.B6.Replace is a new SRv6 Endpoint behavior in the sense of [RFC8986], instantiated on a local SRv6 SID that serves as a BSID. As with End.B6.Encaps, the SID is associated with an SR Policy [RFC9256] whose Segment List determines the outgoing encapsulation; the difference lies solely in the processing of the incoming encapsulation. When the node receives a packet whose Destination Address matches a local SID instantiated with the End.B6.Replace behavior, the node MUST perform the following steps instead of the End.B6.Encaps processing:¶
The header fields of the new outer IPv6 header (e.g., Hop Limit, Traffic Class) are initialized as with any locally originated encapsulation. The Hop Limit of the exposed inner packet is not decremented by the Replace processing itself, consistent with the other decapsulation behaviors in [RFC8986]; it is verified again when the packet is finally decapsulated at its egress.¶
The processing at the binding node is as follows:¶
End.B6.Replace processing:
// DA matches the local BSID instantiated with End.B6.Replace
inner_packet = decapsulate(packet); // remove outer IPv6 header
// + SRH, or remove the SRH
// if directly imposed
packet = encapsulate(inner_packet, new_srh);
// new_srh carries the segment list of the bound SR Policy,
// plus any tail segments (e.g., VPN SID) carried over from
// the original SRH
¶
The End.B6.Replace behavior requires no new control-plane encodings. The BSID is an SRv6 SID like any other: the behavior is instantiated on the SID and advertised using the existing SRv6 SID advertisement mechanisms, such as the Endpoint Behavior TLV in IS-IS [RFC9352] and the corresponding OSPFv3 and BGP-LS [RFC9552] extensions. In an SR Policy [RFC9256], a policy whose BSID is instantiated with End.B6.Replace instead of End.B6.Encaps is signaled without any encoding change; controllers and PCEs [RFC8664] simply account for the behavior of the BSID when computing or steering candidate paths. No new flags, sub-TLVs, or objects are introduced in the SR Policy signaling.¶
This document specifies BSHR only for the SRv6 data plane and does not define a replacement behavior for SR-MPLS: the standard SR-MPLS BSID processing [RFC8660] (pop the active BSID label, push the new label stack) already yields a clean forwarding context in the common cross-domain deployment, so the header-stacking overhead that motivates BSHR does not arise.¶
The most significant challenge is the impact on path validation. [RFC8754] defines consistency checks on the SRH (e.g., that Segments Left does not exceed Last Entry + 1 and that Last Entry does not exceed the maximum index derived from the header length). If a node replaces the header, it loses the context of the original path: an SRH validation state that a downstream node in the previous domain might still rely upon no longer exists, and consistency checks that span the boundary between the old and new encapsulation can no longer be performed.¶
Mitigation: We propose that BSHR is only used at trusted domain boundaries. The removal of the previous header is an explicit administrative action. To maintain some level of validation, the new SRH SHOULD be formed with its Last Entry field and Segments Left field set consistently with the new segment list (as required by [RFC8754]), effectively starting a new validation context.¶
Configuring End.B6.Replace requires a clear understanding of the trust boundaries and the routing policies at those boundaries. Misconfiguration could lead to black-holing or routing loops. Therefore, we strongly recommend that the feature be deployed only under explicit administrative control and with robust monitoring.¶
Signaling replacement via a control-plane flag: adding a flag to the SR Policy encodings (e.g., in BGP SR Policy or PCEP) was considered but rejected. It would require parallel extensions in every protocol that carries SR Policy state, and it would separate the data plane behavior from the SID, contrary to the self-describing design of [RFC8986], in which the behavior is an attribute of the SID itself.¶
End.B6.Replace does not introduce attack vectors beyond those already associated with Binding SID processing: the risk of traffic redirection through a compromised node is not specific to this mechanism and is mitigated by the same control-plane protections (e.g., BGPsec, PCEP authentication) that protect existing BSID mechanisms.¶
In addition, because End.B6.Replace includes a decapsulation step, it inherits the security obligations that [RFC8986] and [RFC8754] place on decapsulation behaviors. Unlike End.B6.Encaps, which never exposes the inner packet, End.B6.Replace terminates an incoming encapsulation; without proper checks, an on-path attacker could inject packets addressed to the BSID with an arbitrary inner payload and use the binding node as an unintended decapsulation point. Operators SHOULD restrict the reachability of the BSID to trusted interfaces and apply the security filtering guidance of [RFC8986] and [RFC8754].¶
This document requests the allocation of one new codepoint in the "SRv6 Endpoint Behaviors" registry created by [RFC8986]:¶
| Value | Hex | Endpoint Behavior | Reference |
|---|---|---|---|
| TBD | 0xTBD | End.B6.Replace | This document |
The allocation follows the "First Come First Served" registration procedure of that registry (the range 0x0001-0x7FFF as specified in [RFC8986]). This document requests no other IANA allocations. A reduced variant (e.g., "End.B6.Replace.Red", omitting the SRH of the new encapsulation when it contains a single segment) MAY be defined in a future document.¶