SRv6 Path Egress Protection

Introduction and TI-LFA provide fast protection for transit nodes and links of an SR path (those within a link-state IGP area), but do not protect the egress node or its egress link. Section 7.2 addresses an intermediate segment endpoint (where the packet continues as a transit packet after segment processing), and TI-LFA only pre-computes backup paths that keep the same destination. Neither addresses the final egress node of an SR path, where traffic is decapsulated and delivered outside the IGP domain. This document fills that gap for SRv6 paths by introducing a Mirror SID (End.M) mechanism that lets a backup egress node take over the forwarding behavior of the failed egress node, extending protection to the network edge. and specify fast protection for the egress node and link of an MPLS TE LSP tunnel, but do not address SRv6 paths. Full egress protection for an SRv6 path can be provided by 1+1 global protection, but that duplicates the path and complicates operation. This document instead protects the egress node and link by extending the IGP and using a Mirror SID. The solution is scoped to a single link-state IGP area/level — a deliberate design choice so that the Point of Local Repair (PLR), the protector, and the failed egress share one flooding domain and can compute congruent LFA/TI-LFA backup paths. It relies on IGP (IS-IS/OSPFv3) extensions (, ) — specifically the advertisement of the Mirror SID and protected locators specified in — to distribute the required state, and on BGP () or configuration to obtain the forwarding behavior of the protected service SIDs. The approach is intended for modest numbers of protected services; large-scale deployments are not recommended due to IGP scaling considerations. A related mechanism, protects the SRv6 egress using a different data-plane approach (a Penultimate Segment Decapsulation Flavor with a pre-installed backup SID) and without IGP extensions. That document protects the egress node, whereas this document protects both the egress node and its egress link. The two mechanisms are complementary and target different deployment constraints.

Terminologies The following terminologies are used in this document.

BFD:: Bidirectional Forwarding Detection
BGP:: Border Gateway Protocol
CE:: Customer Edge
DA:: Destination Address
Egress link:: A link from an egress node to another domain
Egress node:: A domain exit node on an SRv6 path
FIB:: Forwarding Information Base
IGP:: Interior Gateway Protocol
IS-IS:: Intermediate System to Intermediate System
L3VPN:: Layer 3 VPN
LFA:: Loop-Free Alternate
LS:: Link State, which is LSA in OSPF/OSPFv3 or LSP in IS-IS
LSA:: Link State Advertisement in OSPF/OSPFv3
LSP:: Label Switched Path in MPLS or Link State Protocol PDU in IS-IS
OSPF:: Open Shortest Path First
OSPFv3:: Open Shortest Path First version 3
P2MP:: Point-to-MultiPoint
P2P:: Point-to-Point
PDU:: Protocol Data Unit
PE:: Provider Edge
PLR:: Point of Local Repair
RL:: Repair List
SA:: Source Address
SID:: Segment Identifier
SR:: Segment Routing
SRv6:: SR for IPv6
SRH:: Segment Routing Header
TE:: Traffic Engineering
TI-LFA:: Topology-Independent Loop-Free Alternate
VPN:: Virtual Private Network

SRv6 Path Egress Protection This section describes the mechanism of SRv6 path egress protection and illustrates it through an example. All advertisements and computations in this section are confined to a single link-state IGP area/level for SRv6.

Notation The following notation is used throughout this document to represent packet formats: - (SA, DA) represents an IPv6 header with Source Address SA and Destination Address DA. - (SL1, SL2, ..., SLn; SL=k) represents an SRH (Segment Routing Header) with Segment List [SL1, SL2, ..., SLn] and Segments Left field set to k. - Pkt0 represents the payload following the SRv6 encapsulation headers. - Nested headers are represented by concatenation. For example, (T, Mirror SID)(S, SIDa) Pkt0 represents an outer IPv6 header with source T and destination Mirror SID, encapsulating an inner IPv6 header with source S and destination SIDa, followed by payload Pkt0. - When an SRH is present, it is shown in parentheses following the IPv6 header. For example, (T, S1)(Mirror SID, Sn, ..., S1; SL=n)(S, SIDa) Pkt0 represents an outer IPv6 header (T, S1) with an SRH containing Segment List [Mirror SID, Sn, ..., S1] with SL=n, encapsulating an inner IPv6 header (S, SIDa) and payload Pkt0. This notation is consistent with the packet format descriptions used in and . The IPv6 addresses used in the examples throughout this document are drawn from the documentation address block 3fff::/20 reserved by , and the IPv4 addresses are drawn from the documentation address blocks reserved by .

Mechanism is used to explain the mechanism of SRv6 path egress node and egress link protection.

PEB Protects Egress PEA of SRv6 Path

Egress Node Protection Desired Pathways in : Node PEA (Provider Edge A, i.e., the primary/protected egress node) in is the egress node of the SRv6 path from PE1 to PEA and has SIDa, which is the active Segment Identifier (SID) at PEA — specifically, the SID that identifies the protected service (e.g., a VPN SID) or the protected egress link, and whose forwarding behavior the protector PEB must replicate. Node PEB (Provider Edge B, aka backup egress or protector) is the backup egress node that provides the fast protection for PEA. Node P1 is the direct previous/upstream endpoint of egress node PEA and acts as PLR (refer to ) to support the fast protection for PEA. Mirror SID Overview: The SRv6 Mirror SID (End.M) is the core mechanism used in this document for egress protection. A Mirror SID is configured on the protector (PEB) and associated with a FIB (Forwarding Information Base) table that replicates the forwarding behavior of the protected egress node (PEA). When traffic is rerouted to PEB due to PEA failure, the Mirror SID enables PEB to decapsulate the traffic and forward it using PEA's forwarding context. The End.M behavior is a variation of the End.DT6 behavior defined in Section 4.6, and its detailed processing is described in Step 3c below. The IANA assignment for End.M is described in . Steps in Creating the Pathways: Step 1: Normal Pathway Set-up Normal path set-up establishes the SR path from ingress PE1 to egress PEA via P1. Ingress PE1 imports the traffic from CE1 into the SR path and egress PEA delivers the traffic from the SRv6 path to CE2. Step 2: Backup Pathway Set-up Step 2a: PEB Announces to Protect PEA When PEB is selected as a backup egress node to protect the egress node PEA, a SRv6 Mirror SID (refer to Section 5.1 of ) is configured on PEB to protect PEA. PEB MUST advertise this information through IGP (IS-IS or OSPFv3) as specified in (which extends and ), and the advertisement includes the Mirror SID and the egress PEA. The information is represented by <PEB, PEA, Mirror SID>, together with the protected locators. This IGP signaling does not enumerate per-service entries. Step 2b: PEB Learns Forwarding Behavior of PEA PEB MUST learn the forwarding behavior of SIDa (the active SRv6 segment at PEA). When SIDa is a Service SID (e.g., a VPN SID) anchored on PEA, PEB learns its forwarding behavior via the BGP-based overlay as per or by configuration; this document does not introduce per-service signaling in IGP. This enables PEB to reproduce the egress behavior for packets whose active segment at PEA is a Service SID, without requiring IGP to flood per-service state. Step 2c: PEB Programs the Mirror SID Context for PEA When PEB learns the forwarding behavior of SIDa of PEA, it MUST program the Mirror SID context (i.e., the forwarding table identified by the Mirror SID, also called the PEA context) so that packets whose active segment is SIDa are forwarded according to PEA's behavior. The exact implementation (for example, installing a forwarding entry) is a local matter; the observable requirement is that the Mirror SID context reproduces PEA's forwarding behavior for SIDa. This supports Service SID semantics at the protector. However, for large numbers of Service SIDs, operators SHOULD avoid deployments where protection requires fine-grained per-service modeling in IGP, as it may increase IGP flooding and affect convergence. Step 2d: P1 as PLR Prepares to Protect PEA by PEB After P1 as PLR receives the information <PEB, PEA, Mirror SID> and knows that PEB wants to protect SIDa of PEA, it computes an LFA (Loop-Free Alternate) for PEA assuming that PEA and PEB have the same anycast address. A Repair List (RL) (or say backup path) is obtained based on the LFA. It is one of the following:

o: RL = <Mirror SID> if the LFA is the next hop node to PEB along the shortest path to PEB; or
o: RL = <S1, ..., Sn, Mirror SID> if the LFA is a TI-LFA, where <S1, ..., Sn> is the TI-LFA Repair List to PEB computed by P1.

Step 3: Backup Path Is Engaged upon PEA Failure Step 3a: P1 Detects PEA Failure The PLR (P1) detects the failure of the egress node PEA and engages the backup path using one or more of the following detection mechanisms: For egress node (PEA) failure detection: - BFD (Bidirectional Forwarding Detection) : A BFD session is established between P1 (the PLR) and PEA, providing sub-second failure detection. BFD authentication is RECOMMENDED (see ). - IGP Hello detection: Loss of the IS-IS or OSPFv3 adjacency between P1 and PEA can trigger protection. IGP hello timers are typically slower than BFD and may result in longer detection times. - Hardware-level detection: Link-level signal loss, carrier loss, or interface-down events provide immediate detection for failures of directly connected links. For egress link (PEA-CE) failure detection (see ): - BFD on the PEA-CE link: When BFD is enabled on the link between PEA and CE, PEA detects the egress link failure and triggers protection by rerouting traffic to PEB. - CE involvement: The CE MAY participate in failure detection. For example, if the CE detects a link failure, it can withdraw routes or signal the failure to PEA via BGP. In some deployments, BFD may be enabled between PEA and CE across the customer-operator boundary. The level of CE involvement depends on the operational agreement between the operator and the customer. - Ethernet OAM : Connectivity Fault Management (CFM) can detect link or node failures in Ethernet-based access networks. BFD is RECOMMENDED as the primary detection mechanism due to its fast detection capability and wide deployment. The choice of detection mechanism depends on the deployment scenario, the required detection time, and operational constraints. Step 3b: P1 Sends Packet with SIDa to Backup Egress PEB Upon detecting egress node PEA failure, P1 as PLR sends the packet with SIDa carried by the SR path to backup egress node PEB, but MUST encapsulate the packet before sending it by executing H.Encaps with the Repair List (RL) and a Source Address T, where T is a source address of P1 (e.g., a loopback or interface address of the PLR). P1 as PLR will retain the route to PEA for a period of time after its IGP converges on the failure of PEA. Thus the backup path for PEA will be used when the other nodes (such as PE1) still send the packet to PEA via P1 since their IGPs do not converge on the failure. Using the notation of (consistent with the packet illustrations in and ), suppose that the packet received by P1 is represented by Pkt = (S, SID-P1)(SIDa, SID-P1; SL=1) Pkt0, where SA = S and DA = SID-P1 (i.e., SID of P1), and Pkt0 is the rest of the packet. P1 sets DA to SIDa, updates SL and executes H.Encaps. The execution of H.Encaps pushes an IPv6 header to Pkt and sets some fields in the outer and inner IPv6 header to produce an encapsulated packet Pkt'. Pkt' will be one of the following:

o: Pkt' = (T, Mirror SID) (S, SIDa)Pkt0 if RL = <Mirror SID>; or
o: Pkt' = (T, S1)(Mirror SID, Sn, ..., S1; SL=n) (S, SIDa)Pkt0 if RL = <S1, ..., Sn, Mirror SID>.

Step 3c: PEB Decapsulates Packet and Forwards It When PEB receives the re-routed packet — i.e., a packet whose outer destination is the Mirror SID (the form (T, Mirror SID)(S, SIDa) Pkt0 shown in Step 3b is one instance; the same processing applies when an SRH is present in the outer header, e.g., (T, S1)(Mirror SID, Sn, ..., S1; SL=n)(S, SIDa) Pkt0) — it decapsulates the outer IPv6 header and forwards the decapsulated packet using the FIB table Tm identified by the Mirror SID as a variant of the End.DT6 behavior. The Mirror SID is called End.M. When a node processes a packet with an End.M SID as the destination, it MUST perform the following steps in order: 1. Verify that the End.M SID is locally instantiated. If not, process according to Section 4.1.1 of . 2. Remove the outer IPv6 header with all its extension headers. 3. Identify the FIB table associated with the End.M SID context. 4. Submit the inner packet to the identified FIB table for forwarding. If any of these steps fail, the packet MUST be dropped and an appropriate error counter SHOULD be incremented. The behavior of Mirror SID (End.M for short) is a variant of the End.DT6 behavior (refer to Section 4.6 of ). The End.M SID MUST be the last segment in an SR path, and a SID instance is associated with an IPv6 FIB table Tm.

Egress Link Protection Egress link protection is similar to egress node protection for SRv6 . When the egress link from egress node PEA to CE2 fails, PEA acting as a PLR reroutes the traffic to backup egress node PEB via a backup path. Specifically, PEA as a PLR pre-computes a Repair List (RL) (or say backup path) toward PEB after receiving <PEB, PEA, Mirror SID> and knowing that PEB wants to protect SIDa of PEA. When the link fails, PEA as PLR sends the packet with SIDa by executing H.Encaps with the Repair List (RL). All operations occur within the same IGP flooding scope; no per-service signaling is introduced in IGP. The egress link failure is detected by PEA using one or more of the mechanisms described in Step 3a of : BFD on the PEA-CE link, CE participation (e.g., route withdrawal or BGP signaling), or Ethernet OAM . BFD is RECOMMENDED as the primary detection mechanism. When the link failure is detected, PEA performs the same H.Encaps-based reroute as in egress node protection, sending the packet to PEB via the pre-computed Repair List (RL).

Example shows an example of fast protecting egress node PE3 of an SRv6 path, which is from ingress node PE1 to egress node PE3.

PE4 Protects Egress PE3 of SR Path Note: This example demonstrates egress protection at the locator level. The Mirror SID (3fff:4::3) protects PE3's entire locator (3fff:3::/64) rather than an individual Service SID. The VPN SID 3fff:3::B100 shown below is a representative Service SID under that locator, used here for illustrative purposes; its per-service forwarding behavior is learned by PE4 via BGP or configuration, not through IGP signaling. The IGP only advertises the locator-level protection association <PE4, PE3, 3fff:4::3> together with the protected locator, as described in . Desired Pathways in : Node P1's pre-computed backup path for PE3 is from P1 to PE4 via P2. In normal operations, after receiving a packet with SRv6 destination PE3, P1 forwards the packet to PE3 according to its FIB. When PE3 receives the packet, it sends the packet to CE2. When PE3 fails, P1 as PLR detects the failure through using a failure detection mechanism such as BFD and forwards the packet to PE4 via the backup path. When PE4 receives the packet, it sends the packet to the same CE2. When P1's IGP converges on the failure of PE3, P1 as PLR needs to retain the route to PE3 for a period of time. Thus the backup path for PE3 will be used when the other nodes (such as PE1) still send the packet to PE3 via P1 since their IGPs do not converge on the failure. In , Both CE2 and CE3 are dual-homed to PE3 and PE4. PE3 has a locator 3fff:3::/64 and a VPN SID 3fff:3::B100. PE4 has a locator 3fff:4::/64 and VPN SID 3fff:4::B100. A Mirror SID 3fff:4::3 is configured on PE4 for protecting PE3 with locator 3fff:3::/64. P1 has SID-P1 = 3fff:5::A100. Steps in Creating the Pathways: Step 1: Normal Pathway Set-up [PEB is PE4, PEA is PE3] Step 2: Backup Pathway Set-up Step 2a: PE4 (aka PEB) Announces to Protect PE3 (aka PEA) After the configuration, PE4 advertises this information through an IGP LS (i.e., LSA in OSPFv3 or LSP in IS-IS), as specified in , which includes PE3's locator and Mirror SID 3fff:4::3. Every node in the SR domain will receive this IGP LS, which indicates that PE4 wants to protect PE3 (indicated by PE3's locator) with Mirror SID 3fff:4::3. Step 2b: PE4 (aka PEB) Gets Forwarding Behavior of PE3 (aka PEA) The IGP advertisement only associates the Mirror SID 3fff:4::3 with PE3's locator 3fff:3::/64; it does not enumerate any per-service entries. When PE4 (e.g., BGP on PE4) receives a prefix whose VPN SID belongs to PE3 that is protected by PE4 through Mirror SID 3fff:4::3, it learns the forwarding behavior for that Service SID via BGP or configuration, outside the IGP. For example, local PE4 has Prefix 203.0.113.1 with VPN SID 3fff:4::B100; when PE4 receives prefix 203.0.113.1 with remote PE3's VPN SID 3fff:3::B100, it knows that they are for the same VPN and that both SIDs are anchored on the same CE2. The forwarding behaviors for these two VPN SIDs are the same from function's point of view. If the behavior for PE3's VPN SID in PE3 forwards the packet with it to CE2, then the behavior for PE4's VPN SID in PE4 forwards the packet to the same CE2; and vice versa. Because protection is at the locator level, any Service SID under 3fff:3::/64 is handled through the same Mirror SID context without requiring additional IGP state. Step 2c: PE4 (aka PEB) Creates FIB for PE3 (aka PEA) PE4 creates a forwarding entry for PE3's VPN SID 3fff:3::B100 in the FIB table identified by Mirror SID 3fff:4::3 according to the forwarding behavior for PE4's VPN SID 3fff:4::B100. More generally, because protection is at the locator level, PE4 creates forwarding entries for all Service SIDs under PE3's locator 3fff:3::/64 as their forwarding behaviors are learned via BGP or configuration; no per-service state is introduced in IGP. Step 2d: P1 Prepares to Protect PE3 (aka PEA) by PE4 (aka PEB) Node P1's pre-computed backup path for destination PE3 is from P1 to PE4 having mirror SID 3fff:4::3. When P1 receives a packet destined to PE3's VPN SID 3fff:3::B100, in normal operations, it forwards the packet with source 3fff:1::1 and destination PE3's VPN SID 3fff:3::B100 according to the FIB using the destination PE3's VPN SID 3fff:3::B100. Step 3: Backup Path Is Engaged upon PE3 (aka PEA) Failure Step 3a: P1 Detects PE3 (aka PEA) Failure via BFD Step 3b: P1 Sends Packet with SIDa to Backup Egress PE4 (aka PEB) When PE3 fails, P1 as PLR sends the packet to PE4 via the backup path pre-computed. P1 encapsulates the packet using H.Encaps before sending it to PE4. Suppose that the packet received by P1 is represented by Pkt = (SA=3fff:1::1,DA=3fff:5::A100)(SIDa=3fff:3::B100,SID-P1=3fff:5::A100;SL=1) Pkt0, where DA = 3fff:5::A100 is P1's SID, 3fff:3::B100 is PE3's VPN SID, and Pkt0 is the rest of the packet. P1 sets DA to 3fff:3::B100, updates SL, and encapsulates the packet. The encapsulated packet Pkt' will be one of the following:

o: Pkt' = (T, Mirror SID 3fff:4::3) (3fff:1::1, 3fff:3::B100)Pkt0 if the LFA is the next hop node to PE4 along the shortest path to PE4; or (otherwise)
o: Pkt' = (T, S1)(Mirror SID 3fff:4::3, Sn, ..., S1; SL=n) (3fff:1::1, 3fff:3::B100)Pkt0.

where T is a Source Address, <S1, ..., Sn> is the TI-LFA Repair List to PE4 computed by P1. Step 3c: PE4 (aka PEB) Decapsulates Packet and Forwards It When PE4 receives the re-routed packet, it decapsulates the packet and forwards the decapsulated packet by executing the behavior of End.M for the Mirror SID that is associated with the IPv6 FIB table for PE3. The packet received by PE4 is (T, Mirror SID 3fff:4::3) (3fff:1::1, PE3's VPN SID 3fff:3::B100)Pkt0. PE4 obtains Mirror SID 3fff:4::3 in the outer IPv6 header of the packet, removes this outer IPv6 header, and then processes the inner IPv6 packet (3fff:1::1, 3fff:3::B100)Pkt0. It finds the FIB table for PE3 using Mirror SID 3fff:4::3 as the context ID, gets the forwarding entry for PE3's VPN SID 3fff:3::B100 from the table, and forwards the packet to CE2 using the entry. Note:This example demonstrates that a Service SID (e.g., a VPN SID) is preserved at the protector via the Mirror-SID context, and that this is achieved through locator-level protection: the IGP advertises only the locator-level association <PE4, PE3, 3fff:4::3> with the protected locator, while per-service forwarding behaviors are learned via BGP or configuration. However, at large scale (many VPN/service instances and/or random multi-homing of services across multiple protectors), the amount of egress-protection information to be flooded in IGP increases and may affect convergence; such deployments are not recommended for this IGP-based mechanism. Operators SHOULD consolidate protectors per egress and limit per-service granularity in IGP.

Operational Guidelines Protector Consolidation: Within an IGP area/level, prefer a single protector PEB per PEA to minimize the number of SRv6 <PEB, PEA, Mirror SID> advertisements. The choice of PEB SHOULD be aligned with the multi-homing topology of the destination CE: - When the CE is multi-homed to both PEA and PEB, PEB is the natural choice as the protector, since it already has connectivity to the CE and can deliver traffic upon PEA failure. - When the CE is multi-homed to PEA and a different PE (not PEB), the protector PEB MUST have a path to reach the CE through that other PE, or an alternative protector that has direct CE connectivity SHOULD be considered. - When multiple CEs served by PEA have different multi-homing topologies, the operator SHOULD evaluate whether a single protector can adequately serve all CEs, or whether multiple protectors are needed. Limit Granularity in IGP: Do not attempt to enumerate per-service entries in IGP; use locator-level protection only. Service Behavior Acquisition: Learning Service-SID behaviors at the protector (e.g., via BGP per or configuration) is an implementation choice and does not alter the IGP flooding scope. Applicability Thresholds: When the protected service count per egress or the number of protection relationships grows large-especially with random multi-homing-the IGP control-plane load and convergence may be adversely affected; such deployments are not recommended for this mechanism.

Security Considerations

General Security Considerations The egress protection specified in this document involves rerouting traffic around an egress node or link failure, via a backup path from a PLR to a backup egress node. The forwarding performed by the nodes in the data plane is anticipated, as part of the planning of egress protection. The extensions to control plane protocol IS-IS or OSPFv3 are used to support the egress protection on the nodes in an OSPFv3 or IS-IS area. The area is in a single administrative domain. In addition, the PLR and backup egress node are located close to the egress node, which is in the same administrative domain. Security concerns for IS-IS are addressed in , and . While IS-IS is deployed under a single administrative domain, there can be deployments where potential attackers have access to one or more networks in the IS-IS routing domain. In these deployments, the stronger authentication mechanisms defined in the aforementioned documents SHOULD be used. Security concerns for OSPFv3 are described in and . While OSPFv3 is under a single administrative domain, there can be deployments where potential attackers have access to one or more networks in the OSPFv3 routing domain. In these deployments, stronger authentication mechanisms such as those specified in and SHOULD be used. SRv6-Specific Security Considerations:The Mirror SID mechanism introduces the following SRv6-specific security considerations: - Mirror SID Authentication: Since the Mirror SID is advertised through IGP, it is essential that IGP advertisements are authenticated to prevent malicious nodes from advertising counterfeit Mirror SIDs. Implementations SHOULD support the cryptographic authentication mechanisms specified in for IS-IS and for OSPFv3. - Context Isolation: The FIB table identified by the Mirror SID MUST be properly isolated to prevent traffic from one protected egress node from being forwarded using the context of another egress node. Implementations MUST ensure that the context identified by a Mirror SID is only used for packets explicitly addressed to that Mirror SID. Security attacks may sometimes come from a customer domain. Such attacks are not introduced by the egress protection in this document and may occur regardless of the existence of egress protection. In one possible case, the egress link between an egress node and a CE could become a point of attack. An attacker that gains control of the CE might use it to simulate link failures and trigger constant and cascading activities in the network. If egress link protection is in place, egress link protection activities may also be triggered. As a general solution to defeat the attack, a damping mechanism SHOULD be used by the egress node to promptly suppress the services associated with the link or CE. The egress node would stop delivering the services to CE, essentially detaching them from the network and eliminating the effect of the simulated link failures. All protocol extensions operate within a single link-state IGP area/level; no per-service signaling is introduced in IGP, and references to BGP concern only how a protector may learn forwarding behavior.When a protector learns per-service forwarding behavior via mechanisms outside the IGP (e.g., BGP as per or local configuration), it SHOULD validate that the behavior is authorized and consistent with the protected egress node's capabilities advertised through those same external mechanisms. This document does not introduce per-service signaling in the IGP for this validation. The following threats are addressed by corresponding mechanisms: -- Unauthorized Rerouting: An attacker could attempt to trigger unnecessary rerouting by advertising false failure information. This is mitigated by: * Using BFD (preferably with authentication, as described in ) or other reliable failure detection mechanisms. * Authenticating IGP advertisements. * Implementing damping mechanisms to prevent flapping. -- Traffic Interception: An attacker could attempt to become a protector to intercept traffic. This is mitigated by: * Limiting protector selection to trusted nodes within the same administrative domain. * Authenticating IGP advertisements of Mirror SIDs. * Monitoring for unexpected protector advertisements. -- Denial of Service: An attacker could attempt to overwhelm the protector with traffic. This is mitigated by: * Implementing rate limiting at the protector. * Using proper FIB table isolation. * Monitoring traffic patterns. -- Control Plane Overload: An attacker could attempt to flood the IGP with excessive protection advertisements, causing control plane overload and convergence issues.This is mitigated by: * Limit the number of protection relationships per node. * Implement IGP flooding rate limiting. * Use the operational guidelines in Section 3.3 to limit the scale of deployments. * Monitor IGP database size and convergence times.

BFD Security Considerations BFD is used as a primary mechanism for detecting egress node or link failures (see Step 3a of ). To mitigate security threats associated with BFD misuse, the following measures are RECOMMENDED: 1. BFD Authentication: Implementations SHOULD support and enable BFD cryptographic authentication as defined in Section 6.7. This prevents attackers from injecting forged BFD packets that could trigger false failure detection and unauthorized traffic rerouting. 2. BFD Deployment for Egress Node Protection: When BFD is used between the PLR and the PEA for egress node protection, the BFD session SHOULD be established over the IGP domain's authenticated infrastructure. The single-hop BFD operation between the PLR and the PEA follows . When the PEA is a domain border node, BFD authentication becomes critical, as the PEA may have interfaces facing external networks. 3. BFD for Egress Link Protection: When BFD is used to detect egress link failures (between PEA and CE), the BFD session may span administrative boundaries. The single-hop BFD operation between the PEA and the CE follows . In such cases, operators SHOULD use BFD authentication and ensure that BFD session parameters are agreed upon between the operator and the CE administrator. 4. Alternative Detection Mechanisms: In addition to BFD, other mechanisms such as hardware-level link detection, IGP hello timers, or Ethernet OAM MAY be used either alone or in combination with BFD to provide layered failure detection.

Attack on the Protector-CE Link An attacker may attempt to compromise the link between the protector (PEB) and the CE. In this scenario: 1. Traffic Interception: The attacker can intercept traffic rerouted from PEA to PEB and destined for the CE, potentially accessing sensitive data. 2. Traffic Injection: The attacker can inject malicious traffic toward the CE or the network through the compromised link. 3. Service Disruption: The attacker can disrupt connectivity between PEB and CE, causing the protection mechanism to fail when PEA fails. Mitigation measures include: - Physical and link-layer security (e.g., MACsec ) SHOULD be used to secure the PEB-CE link when feasible. - When the PEB-CE link crosses administrative boundaries, operators SHOULD establish security agreements with the CE administrator. - Monitoring of traffic patterns on the PEB-CE link can help detect anomalous behavior. - BFD authentication on the PEB-CE link (see ) can prevent false failure injection.

IANA Considerations

SRv6 Endpoint Behaviors Under registry "SRv6 Endpoint Behaviors" , IANA has assigned the following for End.M Endpoint Behavior:

References Normative References Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473) International Organization for Standardization Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Expanding the IPv6 Documentation Space The document describes the reservation of an additional IPv6 address prefix for use in documentation. This update to RFC 3849 expands on the existing 2001:db8::/32 address block with the reservation of an additional, larger prefix. The addition of a /20 prefix allows documented examples to more closely reflect a broader range of realistic, current deployment scenarios and more closely aligns with contemporary allocation models for large networks. Authentication/Confidentiality for OSPFv3 This document describes means and mechanisms to provide authentication/confidentiality to OSPFv3 using an IPv6 Authentication Header/Encapsulating Security Payload (AH/ESP) extension header. [STANDARDS-TRACK] IS-IS Cryptographic Authentication This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document replaces RFC 3567. This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. [STANDARDS-TRACK] IS-IS Generic Cryptographic Authentication This document proposes an extension to Intermediate System to Intermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes, described in the base specification and RFC 5304. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. Although this document has been written specifically for using the Hashed Message Authentication Code (HMAC) construct along with the Secure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future. [STANDARDS-TRACK] OSPF for IPv6 This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, Short Path First (SPF) calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3). Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link State Advertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP). Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible. All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6. [STANDARDS-TRACK] IPv4 Address Blocks Reserved for Documentation When writing documentation or sample configuration for publication, there is a need for fixed, yet not globally reachable, IP addresses. This document reserves three IPv4 address blocks for this purpose. Bidirectional Forwarding Detection (BFD) This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. The protocol operates in a manner similar to the one-way, connection-oriented, dedicated control channel associated with MPLS and ATM. The protocol is independent of media, data protocols, and routing protocols. Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop) This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol over IPv4 and IPv6 for single IP hops. Supporting Authentication Trailer for OSPFv3 Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not depend only upon IPsec for authentication. The OSPFv3 Authentication Trailer was originally defined in RFC 6506. This document obsoletes RFC 6506 by providing a revised definition, including clarifications and refinements of the procedures. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. OSPFv3 Link State Advertisement (LSA) Extensibility OSPFv3 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisement (LSA) as described in RFC 5340. Without LSA extension, attributes associated with OSPFv3 links and advertised IPv6 prefixes must be advertised in separate LSAs and correlated to the fixed-format LSAs. This document extends the LSA format by encoding the existing OSPFv3 LSA information in Type-Length-Value (TLV) tuples and allowing advertisement of additional information with additional TLVs. Backward-compatibility mechanisms are also described. This document updates RFC 5340, "OSPF for IPv6", and RFC 5838, "Support of Address Families in OSPFv3", by providing TLV-based encodings for the base OSPFv3 unicast support and OSPFv3 address family support. Segment Routing Architecture Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. Segment Routing over IPv6 (SRv6) Network Programming The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. IPv6 Segment Routing Header (SRH) The Segment Routing Header (SRH) is an IPv6 routing extension header that is used by a source-routing mode of Segment Routing to steer packets through a controlled set of intermediate nodes. Segment Routing Policy Architecture Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy. IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called "segments". It can be implemented over the MPLS or the IPv6 data plane. This document describes the IS-IS extensions required to support SR over the IPv6 data plane. This document updates RFC 7370 by modifying an existing registry. OSPFv3 Extensions for Segment Routing over IPv6 (SRv6) The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called segments. It can be implemented over an MPLS or IPv6 data plane. This document describes the OSPFv3 extensions required to support SR over the IPv6 data plane. SRv6 Mirror SID IGP Encoding This document specifies the IS-IS and OSPFv3 extensions for advertising the SRv6 Mirror SID and protected locators used by the SRv6 path egress protection mechanism. Topology Independent Fast Reroute using Segment Routing Individual Cisco Systems Cisco Systems INSA Lyon Orange Bell Canada This document presents Topology Independent Loop-free Alternate Fast Reroute (TI-LFA), aimed at providing protection of node and adjacency segments within the Segment Routing (SR) framework. This Fast Reroute (FRR) behavior builds on proven IP Fast Reroute concepts being LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding (DLFA). It extends these concepts to provide guaranteed coverage in any two-connected networks using a link-state IGP. An important aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the point of local repair, reducing the operational need to control the tie-breaks among various FRR options. Informative References Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the egress node(s) of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) Traffic Engineered (TE) Label Switched Path (LSP). MPLS Egress Protection Framework This document specifies a fast reroute framework for protecting IP/MPLS services and MPLS transport tunnels against egress node and egress link failures. For each type of egress failure, it defines the roles of Point of Local Repair (PLR), protector, and backup egress router and the procedures of establishing a bypass tunnel from a PLR to a protector. It describes the behaviors of these routers in handling an egress failure, including local repair on the PLR and context-based forwarding on the protector. The framework can be used to develop egress protection mechanisms to reduce traffic loss before global repair reacts to an egress failure and control-plane protocols converge on the topology changes due to the egress failure. BGP Overlay Services Based on Segment Routing over IPv6 (SRv6) This document defines procedures and messages for SRv6-based BGP services, including Layer 3 Virtual Private Network (L3VPN), Ethernet VPN (EVPN), and Internet services. It builds on "BGP/MPLS IP Virtual Private Networks (VPNs)" (RFC 4364) and "BGP MPLS-Based Ethernet VPN" (RFC 7432). SRv6 Multihome Egress Protection This document describes an SRv6-based multi-home egress protection mechanism that protects the egress node of an SRv6 path using a pre-installed backup SID and Segment List decrement, without requiring IGP extensions. IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 5: Connectivity Fault Management IEEE Computer Society IEEE Standard for Local and Metropolitan Area Networks--Media Access Control (MAC) Security IEEE Computer Society

Acknowledgments The authors would like to thank Acee Lindem, Peter Psenak, Yimin Shen, Jie Dong, Zhenqiang Li, Alexander Vainshtein, Greg Mirsky, Bruno Decraene, Jeff Tantsura, Chris Bowers, Ketan Talaulikar, Bob Halley, Tal Mizrahi, Yingzhen Qu, Susan Hares, and Antoine Fressancourt for their comments to this work.

Contributors' Addresses