Binding SID Header Replacement (BSHR) for Enhanced Domain Isolation and Overhead Optimization

Introduction 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 . 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 ), while the original packet, including any existing SR header, is preserved as the inner payload. This behavior, while simple and robust, presents limitations:

Overhead: In multi-domain environments, each domain adds its own SR encapsulation. This leads to "header stacking" where the total header size grows linearly with the number of domains traversed. This is particularly problematic in SRv6, where each traversed domain adds a full 40-byte outer IPv6 header plus an SRH on top of the existing encapsulation.
Lack of Isolation: The preservation of the original header allows information about the source domain's internal topology to leak into the destination domain. This violates strict isolation requirements common in multi-tenant environments and 6G network slicing.

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 .

Terminology 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 when, and only when, they appear in all capitals, as shown here. This document uses the terminology defined in , , , and .

Problem Statement The current BSID processing model for SRv6 is defined by the End.B6.Encaps behavior in : 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 . 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.

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.

The Proposed Mechanism: Binding SID Header Replacement (BSHR) This document proposes an extension to the BSID processing rules, specified as a new SRv6 Endpoint behavior, "End.B6.Replace" (), 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 ):

Decapsulation: terminate the incoming SR policy by removing the incoming SR header(s), exposing the payload as a clean IPv6 packet. For SRv6, if the packet is IPv6-in-IPv6 encapsulated, this means removing the outer IPv6 header and its SRH; if the SRH was imposed directly on the packet, this means removing the SRH itself.
Re-encapsulation: impose the new SRH (and outer IPv6 header, as with any other encapsulating node) associated with the BSID policy.

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 : the replaced header starts a new validation context rather than corrupting an existing one.

Use Cases 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:

Security: The internal SIDs of the origin domain are not exposed to the transit domain.
Efficiency: Transit nodes only process the headers relevant to their forwarding decisions, reducing CPU cycles and memory lookups.
Simplified Operations: Each domain operates as a self-contained SR island, simplifying troubleshooting and fault isolation.

The End.B6.Replace Behavior 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.

Behavior Definition End.B6.Replace is a new SRv6 Endpoint behavior in the sense of , instantiated on a local SRv6 SID that serves as a BSID. As with End.B6.Encaps, the SID is associated with an SR Policy 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:

Decapsulate: terminate the incoming SR policy by removing the incoming SR encapsulation, exposing the inner packet. If the packet is IPv6-encapsulated, this means removing the outer IPv6 header and its extension headers; if the SRH was imposed directly on the packet, this means removing the SRH itself.
Re-encapsulate: as a fresh encapsulating node, impose a new IPv6 header and a new SRH carrying the Segment List of the SR Policy bound to the BSID, exactly as performed by End.B6.Encaps . When the incoming segment list continues beyond the BSID, such that the tail following the BSID contains the VPN SID of the egress PE, that VPN SID MUST be carried over to the end of the new segment list: in the example of , the incoming SRH (A2, ..., B1, VPN2) is replaced by (B2, B3, ..., C1, VPN2). Without carrying over the VPN SID, the packet would arrive at the egress border node C1 with no usable destination context.

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 ; it is verified again when the packet is finally decapsulated at its egress. The processing at the binding node is as follows:

Control-Plane Instantiation 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 and the corresponding OSPFv3 and BGP-LS extensions. In an SR Policy , a policy whose BSID is instantiated with End.B6.Replace instead of End.B6.Encaps is signaled without any encoding change; controllers and PCEs 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.

Applicability to SR-MPLS 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 (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.

Challenges and Risks

Path Validation Failure The most significant challenge is the impact on path validation. 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 ), effectively starting a new validation context.

Operational Complexity 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.

Alternatives Considered 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 , in which the behavior is an attribute of the SID itself.

Security Considerations 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 and 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 and .

IANA Considerations This document requests the allocation of one new codepoint in the "SRv6 Endpoint Behaviors" registry created by :

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 ). 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.