LinkedIn

United States of America gdawra.ietf@gmail.com

Cisco Systems

India ketant.ietf@gmail.com

NTT Network Innovations

940 Stewart Dr. Sunnyvale CA 94085 United States of America robert@raszuk.net

Orange

France bruno.decraene@orange.com

Huawei Technologies

China zhuangshunwan@huawei.com

Nokia

United States of America jorge.rabadan@nokia.com

RTG BESS BGP 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).

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2022 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 () 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.

Table of Contents

• .  Introduction
  • .  Requirements Language
• .  SRv6 Services TLVs
• .  SRv6 Service Sub-TLVs
  • .  SRv6 SID Information Sub-TLV
  • .  SRv6 Service Data Sub-Sub-TLVs
    • .  SRv6 SID Structure Sub-Sub-TLV
• .  Encoding SRv6 SID Information
• .  BGP-Based L3 Service over SRv6
  • .  IPv4 VPN over SRv6 Core
  • .  IPv6 VPN over SRv6 Core
  • .  Global IPv4 over SRv6 Core
  • .  Global IPv6 over SRv6 Core
• .  BGP-Based Ethernet VPN (EVPN) over SRv6
  • .  Ethernet Auto-Discovery Route over SRv6 Core
    • .  Ethernet A-D per ES Route
    • .  Ethernet A-D per EVI Route
  • .  MAC/IP Advertisement Route over SRv6 Core
    • .  MAC/IP Advertisement Route with MAC Only
    • .  MAC/IP Advertisement Route with MAC+IP
  • .  Inclusive Multicast Ethernet Tag Route over SRv6 Core
  • .  Ethernet Segment Route over SRv6 Core
  • .  IP Prefix Route over SRv6 Core
  • .  EVPN Multicast Routes (Route Types 6, 7, and 8) over SRv6 Core
• .  Error Handling
• .  IANA Considerations
  • .  BGP Prefix-SID TLV Types Registry
  • .  SRv6 Service Sub-TLV Types Registry
  • .  SRv6 Service Data Sub-Sub-TLV Types Registry
  • .  BGP SRv6 Service SID Flags Registry
  • .  SAFI Values Registry
• .  Security Considerations
  • .  Considerations Related to BGP Sessions
  • .  Considerations Related to BGP Services
  • .  Considerations Related to SR over IPv6 Data Plane
• . References
  • .  Normative References
  • .  Informative References
• Acknowledgements
• Contributors
• Authors' Addresses

Introduction SRv6 refers to Segment Routing instantiated on the IPv6 data plane . BGP is used to advertise the reachability of prefixes of a particular service from an egress Provider Edge (PE) to ingress PE nodes. SRv6-based BGP services refer to the Layer 3 (L3) and Layer 2 (L2) overlay services with BGP as the control plane and SRv6 as the data plane. This document defines procedures and messages for SRv6-based BGP services, including L3VPN, EVPN, and Internet services. It builds on "BGP/MPLS IP Virtual Private Networks (VPNs)" and "BGP MPLS-Based Ethernet VPN" . SRv6 SID refers to an SRv6 Segment Identifier, as defined in . SRv6 Service SID refers to an SRv6 SID associated with one of the service-specific SRv6 Endpoint Behaviors on the advertising PE router, such as (but not limited to) End.DT (look up in the Virtual Routing and Forwarding (VRF) table) or End.DX (cross-connect to a next hop) behaviors in the case of L3VPN service, as defined in . This document describes how existing BGP messages between PEs may carry SRv6 Service SIDs to interconnect PEs and form VPNs. To provide SRv6 service with best-effort connectivity, the egress PE signals an SRv6 Service SID with the BGP overlay service route. The ingress PE encapsulates the payload in an outer IPv6 header where the destination address is the SRv6 Service SID provided by the egress PE. The underlay between the PEs only needs to support plain IPv6 forwarding . To provide SRv6 service in conjunction with an underlay Service Level Agreement (SLA) from the ingress PE to the egress PE, the egress PE colors the overlay service route with a Color Extended Community for steering flows for those routes, as specified in . The ingress PE encapsulates the payload packet in an outer IPv6 header with the SR Policy segment list associated with the related SLA along with the SRv6 Service SID associated with the route using the Segment Routing Header (SRH) . The underlay nodes whose SRv6 SIDs are part of the SRH segment list MUST support the SRv6 data plane.

Requirements Language 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.

SRv6 Services TLVs This document extends the use of the BGP Prefix-SID attribute to carry SRv6 SIDs and their associated information with the BGP address families that are listed further in this section. The SRv6 Service TLVs are defined as two new TLVs of the BGP Prefix-SID attribute to achieve signaling of SRv6 SIDs for L3 and L2 services.

SRv6 L3 Service TLV:

This TLV encodes Service SID information for SRv6-based L3 services. It corresponds to the equivalent functionality provided by an MPLS label when received with a Layer 3 service route, as defined in , , , and . Some SRv6 Endpoint Behaviors that may be encoded are, but not limited to, End.DX4, End.DT4, End.DX6, End.DT6, and End.DT46.

SRv6 L2 Service TLV:

This TLV encodes Service SID information for SRv6-based L2 services. It corresponds to the equivalent functionality provided by an MPLS label for Ethernet VPN (EVPN) Route Types for Layer 2 services, as defined in . Some SRv6 Endpoint Behaviors that may be encoded are, but not limited to, End.DX2, End.DX2V, End.DT2U, and End.DT2M.

When an egress PE is enabled for BGP Services over the SRv6 data plane, it signals one or more SRv6 Service SIDs enclosed in an SRv6 Service TLV(s) within the BGP Prefix-SID attribute attached to Multiprotocol BGP (MP-BGP) Network Layer Reachability Information (NLRI) defined in , , , , , and , where applicable, as described in Sections and . The support for BGP Multicast VPN (MVPN) Services with SRv6 is outside the scope of this document. The following depicts the SRv6 Service TLVs encoded in the BGP Prefix-SID attribute:

SRv6 Service TLVs 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type | TLV Length | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRv6 Service Sub-TLVs // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TLV Type (1 octet):

This field is assigned a value from IANA's "BGP Prefix-SID TLV Types" subregistry. It is set to 5 for the SRv6 L3 Service TLV. It is set to 6 for the SRv6 L2 Service TLV.

TLV Length (2 octets):

This field specifies the total length, in octets, of the TLV Value.

RESERVED (1 octet):

This field is reserved; it MUST be set to 0 by the sender and ignored by the receiver.

SRv6 Service Sub-TLVs (variable):

This field contains SRv6 service-related information and is encoded as an unordered list of Sub-TLVs whose format is described below.

A BGP speaker receiving a route containing the BGP Prefix-SID attribute with one or more SRv6 Service TLVs observes the following rules when advertising the received route to other peers:

• If the BGP next hop is unchanged during the advertisement, the SRv6 Service TLVs, including any unrecognized Types of Sub-TLV and Sub-Sub-TLV, SHOULD be propagated further. In addition, all Reserved fields in the TLV, Sub-TLV, or Sub-Sub-TLV MUST be propagated unchanged.
• If the BGP next hop is changed, the TLVs, Sub-TLVs, and Sub-Sub-TLVs SHOULD be updated with the locally allocated SRv6 SID information. Any received Sub-TLVs and Sub-Sub-TLVs that are unrecognized MUST be removed.

SRv6 Service Sub-TLVs The format of a single SRv6 Service Sub-TLV is depicted below:

SRv6 Service Sub-TLVs 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRv6 Service | SRv6 Service | SRv6 Service // | Sub-TLV | Sub-TLV | Sub-TLV // | Type | Length | Value // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SRv6 Service Sub-TLV Type (1 octet):

This field identifies the type of SRv6 service information. It is assigned a value from IANA's "SRv6 Service Sub-TLV Types" subregistry.

SRv6 Service Sub-TLV Length (2 octets):

This field specifies the total length, in octets, of the Sub-TLV Value field.

SRv6 Service Sub-TLV Value (variable):

This field contains data specific to the Sub-TLV Type. In addition to fixed-length data, it contains other properties of the SRv6 service encoded as a set of SRv6 Service Data Sub-Sub-TLVs whose format is described in below.

SRv6 SID Information Sub-TLV SRv6 Service Sub-TLV Type 1 is assigned for the SRv6 SID Information Sub-TLV. This Sub-TLV contains a single SRv6 SID along with its properties. Its encoding is depicted below:

SRv6 SID Information Sub-TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRv6 Service | SRv6 Service | | | Sub-TLV | Sub-TLV | | | Type=1 | Length | RESERVED1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRv6 SID Value (16 octets) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Svc SID Flags | SRv6 Endpoint Behavior | RESERVED2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRv6 Service Data Sub-Sub-TLVs // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SRv6 Service Sub-TLV Type (1 octet):

This field is set to 1 to represent the SRv6 SID Information Sub-TLV.

SRv6 Service Sub-TLV Length (2 octets):

This field contains the total length, in octets, of the Value field of the Sub-TLV.

RESERVED1 (1 octet):

This field MUST be set to 0 by the sender and ignored by the receiver.

SRv6 SID Value (16 octets):

This field encodes an SRv6 SID, as defined in .

SRv6 Service SID Flags (1 octet):

This field encodes SRv6 Service SID Flags -- none are currently defined. It MUST be set to 0 by the sender and any unknown flags MUST be ignored by the receiver.

SRv6 Endpoint Behavior (2 octets):

This field encodes the SRv6 Endpoint Behavior codepoint value that is associated with the SRv6 SID. The codepoints used are from IANA's "SRv6 Endpoint Behaviors" subregistry under the "Segment Routing" registry that was introduced by . The opaque SRv6 Endpoint Behavior (i.e., value 0xFFFF) MAY be used when the advertising router wishes to abstract the actual behavior of its locally instantiated SRv6 SID.

RESERVED2 (1 octet):

This field MUST be set to 0 by the sender and ignored by the receiver.

SRv6 Service Data Sub-Sub-TLV Value (variable):

This field is used to advertise properties of the SRv6 SID. It is encoded as a set of SRv6 Service Data Sub-Sub-TLVs.

The choice of SRv6 Endpoint Behavior of the SRv6 SID is entirely up to the originator of the advertisement. While Sections and list the SRv6 Endpoint Behaviors that are normally expected to be used by the specific route advertisements, the reception of other SRv6 Endpoint Behaviors (e.g., new behaviors that may be introduced in the future) is not considered an error. An unrecognized SRv6 Endpoint Behavior MUST NOT be considered invalid by the receiver, except for behaviors that involve the use of arguments (refer to for details on argument validation). An implementation MAY log a rate-limited warning when it receives an unexpected behavior. When multiple SRv6 SID Information Sub-TLVs are present, the ingress PE SHOULD use the SRv6 SID from the first instance of the Sub-TLV. An implementation MAY provide a local policy to override this selection.

SRv6 Service Data Sub-Sub-TLVs The format of the SRv6 Service Data Sub-Sub-TLV is depicted below:

SRv6 Service Data Sub-Sub-TLVs 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Data | Sub-Sub-TLV Length |Sub-Sub TLV // | Sub-Sub-TLV | | Value // | Type | | // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SRv6 Service Data Sub-Sub-TLV Type (1 octet):

This field identifies the type of Sub-Sub-TLV. It is assigned a value from IANA's "SRv6 Service Data Sub-Sub-TLV Types" subregistry.

SRv6 Service Data Sub-Sub-TLV Length (2 octets):

This field specifies the total length, in octets, of the Sub-Sub-TLV Value field.

SRv6 Service Data Sub-Sub-TLV Value (variable):

This field contains data specific to the Sub-Sub-TLV Type.

SRv6 SID Structure Sub-Sub-TLV SRv6 Service Data Sub-Sub-TLV Type 1 is assigned for the SRv6 SID Structure Sub-Sub-TLV. The SRv6 SID Structure Sub-Sub-TLV is used to advertise the lengths of the individual parts of the SRv6 SID, as defined in . The terms Locator Block and Locator Node correspond to the B and N parts, respectively, of the SRv6 Locator that is defined in . It is carried as Sub-Sub-TLV in the SRv6 SID Information Sub-TLV.

SRv6 SID Structure Sub-Sub-TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRv6 Service | SRv6 Service | Locator Block | | Data Sub-Sub | Data Sub-Sub-TLV | Length | | -TLV Type=1 | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator Node | Function | Argument | Transposition | | Length | Length | Length | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transposition | | Offset | +-+-+-+-+-+-+-+-+

SRv6 Service Data Sub-Sub-TLV Type (1 octet):

This field is set to 1 to represent the SRv6 SID Structure Sub-Sub-TLV.

SRv6 Service Data Sub-Sub-TLV Length (2 octets):

This field contains a total length of 6 octets.

Locator Block Length (1 octet):

This field contains the length of the SRv6 SID Locator Block in bits.

Locator Node Length (1 octet):

This field contains the length of the SRv6 SID Locator Node in bits.

Function Length (1 octet):

This field contains the length of the SRv6 SID Function in bits.

Argument Length (1 octet):

This field contains the length of the SRv6 SID Argument in bits.

Transposition Length (1 octet):

This field is the size in bits for the part of the SID that has been transposed (or shifted) into an MPLS Label field.

Transposition Offset (1 octet):

This field is the offset position in bits for the part of the SID that has been transposed (or shifted) into an MPLS Label field.

describes mechanisms for the signaling of the SRv6 Service SID by transposing a variable part of the SRv6 SID value and carrying this variable part in existing MPLS Label fields to achieve more efficient packing of those service prefix NLRIs in BGP update messages. The SRv6 SID Structure Sub-Sub-TLV contains appropriate length fields when the SRv6 Service SID is signaled in split parts to enable the receiver to put together the SID accurately. Transposition Offset indicates the bit position, and Transposition Length indicates the number of bits that are being taken out of the SRv6 SID value and encoded in the MPLS Label field. The bits that have been shifted out MUST be set to 0 in the SID value. A Transposition Length of 0 indicates nothing is transposed and that the entire SRv6 SID value is encoded in the SID Information Sub-TLV. In this case, the Transposition Offset MUST be set to 0. The size of the MPLS Label field limits the bits transposed from the SRv6 SID value into it. For example, the size of the MPLS Label field is 20 bits in and , and the size is 24 bits in . As defined in , the sum of the Locator Block Length (LBL), Locator Node Length (LNL), Function Length (FL), and Argument Length (AL) fields MUST be less than or equal to 128 and greater than the sum of Transposition Offset and Transposition Length. As an example, consider that the sum of the Locator Block and the Locator Node parts is 64. For an SRv6 SID where the entire Function part of size 16 bits is transposed, the transposition offset is set to 64 and the transposition length is set to 16. While for an SRv6 SID for which the FL is 24 bits and only the lower order 20 bits are transposed (e.g., due to the limit of the MPLS Label field size), the transposition offset is set to 68 and the transposition length is set to 20. BGP speakers that do not support this specification may misinterpret, on the reception of an SRv6-based BGP service route update, the part of the SRv6 SID encoded in an MPLS Label field(s) as MPLS label values for MPLS-based services. Implementations supporting this specification MUST provide a mechanism to control the advertisement of SRv6-based BGP service routes on a per-neighbor and per-service basis. The details of deployment designs and implementation options are outside the scope of this document. Arguments may be generally applicable for SIDs of only specific SRv6 Endpoint Behaviors (e.g., End.DT2M); therefore, the AL MUST be set to 0 for SIDs where the Argument is not applicable. A receiver is unable to validate the applicability of arguments for SRv6 Endpoint Behaviors that are unknown to it and hence MUST ignore SRv6 SIDs with arguments (indicated by a non-zero AL) with unknown SRv6 Endpoint Behaviors. For SIDs corresponding to an SRv6 Endpoint Behavior that is known, a receiver MUST validate that the consistency of the AL with the specific SRv6 Endpoint Behavior definition.

Encoding SRv6 SID Information The SRv6 Service SID(s) for a BGP service prefix is carried in the SRv6 Services TLVs of the BGP Prefix-SID attribute. For certain types of BGP Services, like L3VPN where a per-VRF SID allocation is used (i.e., End.DT4 or End.DT6 behaviors), the same SID is shared across multiple NLRIs, thus providing efficient packing. However, for certain other types of BGP Services, like EVPN Virtual Private Wire Service (VPWS) where a per-PW SID allocation is required (i.e., End.DX2 behavior), each NLRI would have its own unique SID, thereby resulting in inefficient packing. To achieve efficient packing, this document allows either 1) the encoding of the SRv6 Service SID as a whole in the SRv6 Services TLVs or 2) the encoding of only the common part of the SRv6 SID (e.g., Locator) in the SRv6 Services TLVs and the encoding of the variable (e.g., Function or Argument parts) in the existing label fields specific to that service encoding. This later form of encoding is referred to as the Transposition Scheme, where the SRv6 SID Structure Sub-Sub-TLV describes the sizes of the parts of the SRv6 SID and also indicates the offset of the variable part along with its length in the SRv6 SID value. The use of the Transposition Scheme is RECOMMENDED for the specific service encodings that allow it, as described further in Sections and . As an example, for the EVPN VPWS service prefix described further in , the Function part of the SRv6 SID is encoded in the MPLS Label field of the NLRI, and the SID value in the SRv6 Services TLV carries only the Locator part with the SRv6 SID Structure Sub-Sub-TLV. The SRv6 SID Structure Sub-Sub-TLV defines the lengths of Locator Block, Locator Node, and Function parts (Arguments are not applicable for the End.DX2 behavior). Transposition Offset indicates the bit position, and Transposition Length indicates the number of bits that are being taken out of the SID and put into the label field. In yet another example, for the EVPN Ethernet Auto-Discovery (A-D) per Ethernet Segment (ES) route described further in , only the Argument of the SID needs to be signaled. This Argument part of the SRv6 SID MAY be transposed in the Ethernet Segment Identifier (ESI) Label field of the ESI Label extended community, and the SID value in the SRv6 Services TLV is set to 0 along with the inclusion of the SRv6 SID Structure Sub-Sub-TLV. The SRv6 SID Structure Sub-Sub-TLV defines the lengths of Locator Block, Locator Node, Function, and Argument parts. The offset and length of the Argument part SID value moved to the label field is set in transposition offset and length of the SID Structure TLV. The receiving router is then able to put together the entire SRv6 Service SID (e.g., for the End.DT2M behavior), placing the label value received in the ESI Label field of the Ethernet A-D per ES route into the correct transposition offset and length in the SRv6 SID with the End.DT2M behavior received for an EVPN Route Type 3 value.

BGP-Based L3 Service over SRv6 BGP egress nodes (egress PEs) advertise a set of reachable prefixes. Standard BGP update propagation schemes , which may make use of route reflectors , are used to propagate these prefixes. BGP ingress nodes (ingress PEs) receive these advertisements and may add the prefix to the RIB in an appropriate VRF. Egress PEs that support SRv6-based L3 services advertise overlay service prefixes along with a Service SID enclosed in an SRv6 L3 Service TLV within the BGP Prefix-SID attribute. This TLV serves two purposes -- first, it indicates that the egress PE supports SRv6 overlay, and the BGP ingress PE receiving this route MUST perform IPv6 encapsulation and insert an SRH when required; second, it indicates the value of the Service SID to be used in the encapsulation. Thus, the Service SID signaled only has local significance at the egress PE, where it may be allocated or configured on a per-Customer-Edge (CE) or per-VRF basis. In practice, the SID may encode a cross-connect to a specific address family table (End.DT) or next hop / interface (End.DX), as defined in . The SRv6 Service SID SHOULD be routable (refer to ) within the Autonomous System (AS) of the egress PE and serves the dual purpose of providing reachability between ingress PE and egress PE while also encoding the SRv6 Endpoint Behavior. When steering for SRv6 services is based on shortest path forwarding (e.g., best effort or IGP Flexible Algorithm ) to the egress PE, the ingress PE encapsulates the IPv4 or IPv6 customer packet in an outer IPv6 header (using H.Encaps or H.Encaps.Red flavors specified in ), where the destination address is the SRv6 Service SID associated with the related BGP route update. Therefore, the ingress PE MUST perform a resolvability check for the SRv6 Service SID before considering the received prefix for the BGP best path computation. The resolvability is evaluated as per . If the SRv6 SID is reachable via more than one forwarding table, local policy is used to determine which table to use. The result of an SRv6 Service SID resolvability (e.g., when provided via IGP Flexible Algorithm) can be ignored if the ingress PE has a local policy that allows an alternate steering mechanism to reach the egress PE. The details of such steering mechanisms are outside the scope of this document. For service over SRv6 core, the egress PE sets the BGP next hop to one of its IPv6 addresses. Such an address MAY be covered by the SRv6 Locator from which the SRv6 Service SID is allocated. The BGP next hop is used for tracking the reachability of the egress PE based on existing BGP procedures. When the BGP route received at an ingress PE is colored with a Color Extended Community and a valid SRv6 Policy is available, the steering for service flows is performed as described in . When the ingress PE determines (with the help of the SRv6 SID Structure) that the Service SID belongs to the same SRv6 Locator as the last SRv6 SID (of the egress PE) in the SR Policy segment list, it MAY exclude that last SRv6 SID when steering the service flow. For example, the effective segment list of the SRv6 Policy associated with SID list <S1, S2, S3> would be <S1, S2, S3-Service-SID>.

IPv4 VPN over SRv6 Core The MP_REACH_NLRI over SRv6 core is encoded according to IPv4 VPN unicast over IPv6 core defined in . The label field of IPv4-VPN NLRI is encoded as specified in with the 20-bit Label Value set to the whole or a portion of the Function part of the SRv6 SID when the Transposition Scheme of encoding () is used; otherwise, it is set to Implicit NULL. When using the Transposition Scheme, the Transposition Length MUST be less than or equal to 20 and less than or equal to the FL. The SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The SRv6 Endpoint Behavior SHOULD be one of these: End.DX4, End.DT4, or End.DT46.

IPv6 VPN over SRv6 Core The MP_REACH_NLRI over SRv6 core is encoded according to IPv6 VPN over IPv6 core, as defined in . The label field of the IPv6-VPN NLRI is encoded as specified in with the 20-bit Label Value set to the whole or a portion of the Function part of the SRv6 SID when the Transposition Scheme of encoding () is used; otherwise, it is set to Implicit NULL. When using the Transposition Scheme, the Transposition Length MUST be less than or equal to 20 and less than or equal to the FL. The SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The SRv6 Endpoint Behavior SHOULD be one of these: End.DX6, End.DT6, or End.DT46.

Global IPv4 over SRv6 Core The MP_REACH_NLRI over SRv6 core is encoded according to IPv4 over IPv6 core, as defined in . SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The SRv6 Endpoint Behavior SHOULD be one of these: End.DX4, End.DT4, or End.DT46.

Global IPv6 over SRv6 Core The MP_REACH_NLRI over SRv6 core is encoded according to . The SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The SRv6 Endpoint Behavior SHOULD be one of these: End.DX6, End.DT6, or End.DT46.

BGP-Based Ethernet VPN (EVPN) over SRv6 provides an extendable method of building an EVPN overlay. It primarily focuses on MPLS-based EVPNs, and extends to IP-based EVPN overlays. defines Route Types 1, 2, and 3, which carry prefixes and MPLS Label fields; the Label fields have a specific use for MPLS encapsulation of EVPN traffic. Route Type 5 carrying MPLS label information (and thus encapsulation information) for an EVPN is defined in . Route Types 6, 7, and 8 are defined in .

• Ethernet Auto-Discovery (A-D) route (Route Type 1)
• MAC/IP Advertisement route (Route Type 2)
• Inclusive Multicast Ethernet Tag route (Route Type 3)
• Ethernet Segment route (Route Type 4)
• IP Prefix route (Route Type 5)
• Selective Multicast Ethernet Tag route (Route Type 6)
• Multicast Membership Report Synch route (Route Type 7)
• Multicast Leave Synch route (Route Type 8)

The specifications for other EVPN Route Types are outside the scope of this document. To support SRv6-based EVPN overlays, one or more SRv6 Service SIDs are advertised with Route Types 1, 2, 3, and 5. The SRv6 Service SID(s) per Route Type is advertised in SRv6 L3/L2 Service TLVs within the BGP Prefix-SID attribute. Signaling of the SRv6 Service SID(s) serves two purposes -- first, it indicates that the BGP egress device supports SRv6 overlay, and the BGP ingress device receiving this route MUST perform IPv6 encapsulation and insert an SRH when required; second, it indicates the value of the Service SID(s) to be used in the encapsulation. The SRv6 Service SID SHOULD be routable (refer to ) within the AS of the egress PE and serves the dual purpose of providing reachability between the ingress PE and egress PE while also encoding the SRv6 Endpoint Behavior. When steering for SRv6 services is based on shortest path forwarding (e.g., best effort or IGP Flexible Algorithm ) to the egress PE, the ingress PE encapsulates the customer Layer 2 Ethernet packet in an outer IPv6 header (using H.Encaps.L2 or H.Encaps.L2.Red flavors specified in ) where the destination address is the SRv6 Service SID associated with the related BGP route update. Therefore, the ingress PE MUST perform a resolvability check for the SRv6 Service SID before considering the received prefix for the BGP best path computation. The resolvability is evaluated as per . If the SRv6 SID is reachable via more than one forwarding table, local policy is used to determine which table to use. The result of an SRv6 Service SID resolvability (e.g., when provided via IGP Flexible Algorithm) can be ignored if the ingress PE has a local policy that allows an alternate steering mechanism to reach the egress PE. The details of such steering mechanisms are outside the scope of this document. For service over SRv6 core, the egress PE sets the BGP next hop to one of its IPv6 addresses. Such an address MAY be covered by the SRv6 Locator from which the SRv6 Service SID is allocated. The BGP next hop is used for tracking the reachability of the egress PE based on existing BGP procedures. When the BGP route received at an ingress PE is colored with a Color Extended Community and a valid SRv6 Policy is available, the steering for service flows is performed as described in . When the ingress PE determines (with the help of the SRv6 SID Structure) that the Service SID belongs to the same SRv6 Locator as the last SRv6 SID (of the egress PE) in the SR Policy segment list, it MAY exclude that last SRv6 SID when steering the service flow. For example, the effective segment list of the SRv6 Policy associated with SID list <S1, S2, S3> would be <S1, S2, S3-Service-SID>.

Ethernet Auto-Discovery Route over SRv6 Core Ethernet A-D routes are Route Type 1, as defined in , and may be used to achieve split-horizon filtering, fast convergence, and aliasing. EVPN Route Type 1 is also used in EVPN-VPWS as well as in EVPN-flexible cross-connect, mainly to advertise point-to-point service IDs. As a reminder, EVPN Route Type 1 is encoded as follows:

EVPN Route Type 1 +-----------------------------------------+ | RD (8 octets) | +-----------------------------------------+ | Ethernet Segment Identifier (10 octets)| +-----------------------------------------+ | Ethernet Tag ID (4 octets) | +-----------------------------------------+ | MPLS label (3 octets) | +-----------------------------------------+

Ethernet A-D per ES Route Ethernet A-D per ES route NLRI encoding over SRv6 core is as per . The 24-bit ESI Label field of the ESI Label extended community carries the whole or a portion of the Argument part of the SRv6 SID when the ESI filtering approach is used along with the Transposition Scheme of encoding (); otherwise, it is set to Implicit NULL in the higher-order 20 bits (i.e., as 0x000030). In either case, the value is set in the 24 bits. When using the Transposition Scheme, the Transposition Length MUST be less than or equal to 24 and less than or equal to the AL. A Service SID enclosed in an SRv6 L2 Service TLV within the BGP Prefix-SID attribute is advertised along with the A-D route. The SRv6 Endpoint Behavior SHOULD be End.DT2M. When the ESI filtering approach is used, the Service SID is used to signal the Arg.FE2 SID Argument for applicable End.DT2M behavior . When the local-bias approach is used, the Service SID MAY be of value 0.

Ethernet A-D per EVI Route Ethernet A-D per EVPN Instance (EVI) route NLRI encoding over SRv6 core is similar to what is described in and with the following change:

MPLS Label:

The 24-bit field carries the whole or a portion of the Function part of the SRv6 SID when the Transposition Scheme of encoding () is used; otherwise, it is set to Implicit NULL in the higher-order 20 bits (i.e., as 0x000030). In either case, the value is set in the 24 bits. When using the Transposition Scheme, the Transposition Length MUST be less than or equal to 24 and less than or equal to the FL.

A Service SID enclosed in an SRv6 L2 Service TLV within the BGP Prefix-SID attribute is advertised along with the A-D route. The SRv6 Endpoint Behavior SHOULD be one of these: End.DX2, End.DX2V, or End.DT2U.

MAC/IP Advertisement Route over SRv6 Core EVPN Route Type 2 is used to advertise unicast traffic Media Access Control (MAC) + IP address reachability through MP-BGP to all other PEs in a given EVPN instance. As a reminder, EVPN Route Type 2 is encoded as follows:

EVPN Route Type 2 +-----------------------------------------+ | RD (8 octets) | +-----------------------------------------+ | Ethernet Segment Identifier (10 octets)| +-----------------------------------------+ | Ethernet Tag ID (4 octets) | +-----------------------------------------+ | MAC Address Length (1 octet) | +-----------------------------------------+ | MAC Address (6 octets) | +-----------------------------------------+ | IP Address Length (1 octet) | +-----------------------------------------+ | IP Address (0, 4, or 16 octets) | +-----------------------------------------+ | MPLS Label1 (3 octets) | +-----------------------------------------+ | MPLS Label2 (0 or 3 octets) | +-----------------------------------------+

NLRI encoding over SRv6 core is similar to what is described in with the following changes:

MPLS Label1:

This is associated with the SRv6 L2 Service TLV. This 24-bit field carries the whole or a portion of the Function part of the SRv6 SID when the Transposition Scheme of encoding () is used; otherwise, it is set to Implicit NULL in the higher-order 20 bits (i.e., as 0x000030). In either case, the value is set in the 24 bits. When using the Transposition Scheme, the Transposition Length MUST be less than or equal to 24 and less than or equal to the FL.

MPLS Label2:

This is associated with the SRv6 L3 Service TLV. This 24-bit field carries the whole or a portion of the Function part of the SRv6 SID when the Transposition Scheme of encoding () is used; otherwise, it is set to Implicit NULL in the higher-order 20 bits (i.e., as 0x000030). In either case, the value is set in the 24 bits. When using the Transposition Scheme, the Transposition Length MUST be less than or equal to 24 and less than or equal to the FL.

Service SIDs enclosed in the SRv6 L2 Service TLV and optionally in the SRv6 L3 Service TLV within the BGP Prefix-SID attribute are advertised along with the MAC/IP Advertisement route. Described below are different types of Route Type 2 advertisements.

MAC/IP Advertisement Route with MAC Only

MPLS Label1:

This is associated with the SRv6 L2 Service TLV. This 24-bit field carries the whole or a portion of the Function part of the SRv6 SID when the Transposition Scheme of encoding () is used; otherwise, it is set to Implicit NULL in the higher-order 20 bits (i.e., as 0x000030). In either case, the value is set in the 24 bits. When using the Transposition Scheme, the Transposition Length MUST be less than or equal to 24 and less than or equal to the FL.

A Service SID enclosed in an SRv6 L2 Service TLV within the BGP Prefix-SID attribute is advertised along with the route. The SRv6 Endpoint Behavior SHOULD be one of these: End.DX2 or End.DT2U.

MAC/IP Advertisement Route with MAC+IP

MPLS Label1:

This is associated with the SRv6 L2 Service TLV. This 24-bit field carries the whole or a portion of the Function part of the SRv6 SID when the Transposition Scheme of encoding () is used; otherwise, it is set to Implicit NULL in the higher-order 20 bits (i.e., as 0x000030). In either case, the value is set in the 24 bits. When using the Transposition Scheme, the Transposition Length MUST be less than or equal to 24 and less than or equal to the FL.

MPLS Label2:

This is associated with the SRv6 L3 Service TLV. This 24-bit field carries the whole or a portion of the Function part of the SRv6 SID when the Transposition Scheme of encoding () is used; otherwise, it is set to Implicit NULL in the higher-order 20 bits (i.e., as 0x000030). In either case, the value is set in the 24 bits. When using the Transposition Scheme, the Transposition Length MUST be less than or equal to 24 and less than or equal to the FL.

An L2 Service SID enclosed in an SRv6 L2 Service TLV within the BGP Prefix-SID attribute is advertised along with the route. In addition, an L3 Service SID enclosed in an SRv6 L3 Service TLV within the BGP Prefix-SID attribute MAY also be advertised along with the route. The SRv6 Endpoint Behavior SHOULD be one of these: for the L2 Service SID, End.DX2 or End.DT2U and for the L3 Service SID, End.DT46, End.DT4, End.DT6, End.DX4, or End.DX6.

Inclusive Multicast Ethernet Tag Route over SRv6 Core EVPN Route Type 3 is used to advertise multicast traffic reachability information through MP-BGP to all other PEs in a given EVPN instance. As a reminder, EVPN Route Type 3 is encoded as follows:

EVPN Route Type 3 +---------------------------------------+ | RD (8 octets) | +---------------------------------------+ | Ethernet Tag ID (4 octets) | +---------------------------------------+ | IP Address Length (1 octet) | +---------------------------------------+ | Originating Router's IP Address | | (4 or 16 octets) | +---------------------------------------+

NLRI encoding over SRv6 core is similar to what is described in . The P-Multicast Service Interface (PMSI) Tunnel Attribute is used to identify the Provider tunnel (P-tunnel) used for sending Broadcast, Unknown Unicast, or Multicast (BUM) traffic. The format of the PMSI Tunnel Attribute is encoded as follows over SRv6 core:

PMSI Tunnel Attribute +---------------------------------------+ | Flag (1 octet) | +---------------------------------------+ | Tunnel Type (1 octet) | +---------------------------------------+ | MPLS label (3 octets) | +---------------------------------------+ | Tunnel Identifier (variable) | +---------------------------------------+

Flag:

This field has a value of 0, as defined per .

Tunnel Type:

This field is defined per .

MPLS label:

This 24-bit field carries the whole or a portion of the Function part of the SRv6 SID when ingress replication is used and the Transposition Scheme of encoding () is used; otherwise, it is set as defined in . When using the Transposition Scheme, the Transposition Length MUST be less than or equal to 24 and less than or equal to the FL.

Tunnel Identifier:

This field is the IP address of egress PE.

A Service SID enclosed in an SRv6 L2 Service TLV within the BGP Prefix-SID attribute is advertised along with the route. The SRv6 Endpoint Behavior SHOULD be End.DT2M.

• When ESI-based filtering is used for multihoming or Ethernet Tree (E-Tree) procedures, the ESI Filtering Argument (the Arg.FE2 notation introduced in ) of the Service SID carried along with EVPN Route Type 1 SHOULD be merged with the applicable End.DT2M SID of Route Type 3 advertised by the remote PE by doing a bitwise logical-OR operation to create a single SID on the ingress PE. Details of split-horizon, ESI-based filtering mechanisms for multihoming are described in . Details of filtering mechanisms for Leaf-originated BUM traffic in EVPN E-Tree services are provided in .
• When "local-bias" is used as the multihoming split-horizon method, the ESI Filtering Argument SHOULD NOT be merged with the corresponding End.DT2M SID on the ingress PE. Details of the local-bias procedures are described in .

Usage of multicast trees as P-tunnels is outside the scope of this document.

Ethernet Segment Route over SRv6 Core As a reminder, an Ethernet Segment route (i.e., EVPN Route Type 4) is encoded as follows:

EVPN Route Type 4 +---------------------------------------+ | RD (8 octets) | +---------------------------------------+ | Ethernet Tag ID (4 octets) | +---------------------------------------+ | IP Address Length (1 octet) | +---------------------------------------+ | Originating Router's IP Address | | (4 or 16 octets) | +---------------------------------------+

NLRI encoding over SRv6 core is similar to what is described in . SRv6 Service TLVs within the BGP Prefix-SID attribute are not advertised along with this route. The processing of the route has not changed -- it remains as described in .

IP Prefix Route over SRv6 Core EVPN Route Type 5 is used to advertise IP address reachability through MP-BGP to all other PEs in a given EVPN instance. The IP address may include a host IP prefix or any specific subnet. As a reminder, EVPN Route Type 5 is encoded as follows:

EVPN Route Type 5 +-----------------------------------------+ | RD (8 octets) | +-----------------------------------------+ | Ethernet Segment Identifier (10 octets)| +-----------------------------------------+ | Ethernet Tag ID (4 octets) | +-----------------------------------------+ | IP Prefix Length (1 octet) | +-----------------------------------------+ | IP Prefix (4 or 16 octets) | +-----------------------------------------+ | GW IP Address (4 or 16 octets) | +-----------------------------------------+ | MPLS Label (3 octets) | +-----------------------------------------+

NLRI encoding over SRv6 core is similar to what is described in with the following change:

MPLS Label:

This 24-bit field carries the whole or a portion of the Function part of the SRv6 SID when the Transposition Scheme of encoding () is used; otherwise, it is set to Implicit NULL in the higher-order 20 bits (i.e., as 0x000030). In either case, the value is set in the 24 bits. When using the Transposition Scheme, the Transposition Length MUST be less than or equal to 24 and less than or equal to the FL.

The SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The SRv6 Endpoint Behavior SHOULD be one of these: End.DT4, End.DT6, End.DT46, End.DX4, or End.DX6.

EVPN Multicast Routes (Route Types 6, 7, and 8) over SRv6 Core These routes do not require the advertisement of SRv6 Service TLVs along with them. Similar to EVPN Route Type 4, the BGP next hop is equal to the IPv6 address of egress PE.

Error Handling In case of any errors encountered while processing SRv6 Service TLVs, the details of the error SHOULD be logged for further analysis. If multiple instances of the SRv6 L3 Service TLV are encountered, all but the first instance MUST be ignored. If multiple instances of the SRv6 L2 Service TLV are encountered, all but the first instance MUST be ignored. An SRv6 Service TLV is considered malformed in the following cases:

• The TLV Length is less than 1.
• The TLV Length is inconsistent with the length of the BGP Prefix-SID attribute.
• At least one of the constituent Sub-TLVs is malformed.

An SRv6 Service Sub-TLV is considered malformed in the following case:

• The Sub-TLV Length is inconsistent with the length of the enclosing SRv6 Service TLV.

An SRv6 SID Information Sub-TLV is considered malformed in the following cases:

• The Sub-TLV Length is less than 21.
• The Sub-TLV Length is inconsistent with the length of the enclosing SRv6 Service TLV.
• At least one of the constituent Sub-Sub-TLVs is malformed.

An SRv6 Service Data Sub-Sub-TLV is considered malformed in the following case:

• The Sub-Sub-TLV Length is inconsistent with the length of the enclosing SRv6 service Sub-TLV.

Any TLV, Sub-TLV, or Sub-Sub-TLV is not considered malformed because its Type is unrecognized. Any TLV, Sub-TLV, or Sub-Sub-TLV is not considered malformed because of failing any semantic validation of its Value field. The SRv6 overlay service requires the Service SID for forwarding. The treat-as-withdraw action MUST be performed when at least one malformed SRv6 Service TLV is present in the BGP Prefix-SID attribute. The SRv6 SID value in the SRv6 SID Information Sub-TLV is invalid when the SID Structure Sub-Sub-TLV transposition length is greater than the number of bits of the label field or if any of the conditions for the fields of the Sub-Sub-TLV, as specified in , is not met. The transposition offset and length MUST be 0 when the Sub-Sub-TLV is advertised along with routes where the Transposition Scheme is not applicable (e.g., for global IPv6 service where there is no label field). The path having any such Prefix-SID attribute without any valid SRv6 SID information MUST be considered ineligible during the selection of the best path for the corresponding prefix.

IANA Considerations

BGP Prefix-SID TLV Types Registry This document introduces two new TLV Types of the BGP Prefix-SID attribute. IANA has assigned Type values in the "BGP Prefix-SID TLV Types" subregistry as follows: BGP Prefix-SID TLV Types Subregistry

Value	Type	Reference
4	Deprecated	RFC 9252
5	SRv6 L3 Service TLV	RFC 9252
6	SRv6 L2 Service TLV	RFC 9252

Value 4 previously corresponded to the SRv6-VPN SID TLV, which was specified in earlier draft versions of this document and used by early implementations of this specification. It was deprecated and replaced by the SRv6 L3 Service and SRv6 L2 Service TLVs.

SRv6 Service Sub-TLV Types Registry IANA has created and now maintains a new subregistry called "SRv6 Service Sub-TLV Types" under the "Border Gateway Protocol (BGP) Parameters" registry. The registration procedures, per , for this subregistry are according to . SRv6 Service Sub-TLV Types Subregistry Registration Procedures

Range	Registration Procedures
1-127	IETF Review
128-254	First Come First Served
255	IETF Review

IANA has populated this subregistry as follows. Note that the SRv6 SID Information Sub-TLV is defined in this document: SRv6 Service Sub-TLV Types Subregistry Initial Contents

Value	Type	Reference
0	Reserved	RFC 9252
1	SRv6 SID Information Sub-TLV	RFC 9252
255	Reserved	RFC 9252

SRv6 Service Data Sub-Sub-TLV Types Registry IANA has created and now maintains a new subregistry called "SRv6 Service Data Sub-Sub-TLV Types" under the "Border Gateway Protocol (BGP) Parameters" registry. The registration procedures for this subregistry are according to . SRv6 Service Data Sub-Sub-TLV Types Subregistry Registration Procedures

Range	Registration Procedure
1-127	IETF Review
128-254	First Come First Served
255	IETF Review

The following Sub-Sub-TLV Type is defined in this document: SRv6 Service Data Sub-Sub-TLV Types Subregistry Initial Contents

Value	Type	Reference
0	Reserved	RFC 9252
1	SRv6 SID Structure Sub-Sub-TLV	RFC 9252
255	Reserved	RFC 9252

BGP SRv6 Service SID Flags Registry IANA has created and now maintains a new subregistry called "BGP SRv6 Service SID Flags" under the "Border Gateway Protocol (BGP) Parameters" registry. The registration procedure for this subregistry is IETF Review, and all 8-bit positions of the flags are currently unassigned.

SAFI Values Registry IANA has added this document as a reference for value 128 ("MPLS-labeled VPN address") in the "SAFI Values" subregistry under the "Subsequent Address Family Identifiers (SAFI) Parameters" registry.

Security Considerations This document specifies extensions to the BGP protocol for the signaling of services for SRv6. These specifications leverage existing BGP protocol mechanisms for the signaling of various types of services. It also builds upon existing elements of the SR architecture (more specifically, SRv6). As such, this section largely provides pointers (as a reminder) to the security considerations of those existing specifications while also covering certain, newer security aspects for the specifications newly introduced by this document.

Considerations Related to BGP Sessions Techniques related to authentication of BGP sessions for securing messages between BGP peers, as discussed in the BGP specification and in the security analysis for BGP , apply. The discussion of the use of the TCP Authentication Option to protect BGP sessions is found in , while includes an analysis of BGP keying and authentication issues. This document does not introduce any additional BGP session security considerations.

Considerations Related to BGP Services This document does not introduce new services or BGP NLRI types but extends the signaling of existing ones for SRv6. Therefore, the security considerations for the respective BGP services, such as BGP IPv4 over IPv6 NH, BGP IPv6 L3VPN, BGP IPv6, BGP EVPN, and IP EVPN, apply as discussed in their respective documents. discusses mechanisms to prevent the leaking of the BGP Prefix-SID attribute, which carries SR information, outside the SR domain. As a reminder, several of the BGP services (i.e., the AFI/SAFI used for their signaling) were initially introduced for one encapsulation mechanism and later extended for others, e.g., EVPN MPLS was extended for Virtual eXtensible Local Area Network (VXLAN) encapsulation and Network Virtualization Using Generic Routing Encapsulation (NVGRE) . enables the use of various IP encapsulation mechanisms along with different BGP SAFIs for their respective services. The existing filtering mechanisms for preventing the leak of the encapsulation information (carried in BGP attributes) and preventing the advertisement of prefixes from the provider's internal address space (especially the SRv6 Block, as discussed in ) to external peers (or into the Internet) also apply in the case of SRv6. Specific to SRv6, a misconfiguration or error in the BGP filtering mechanisms mentioned above may result in exposing information, such as SRv6 Service SIDs to external peers or other unauthorized entities. However, an attempt to exploit this information or to raise an attack by injecting packets into the network (e.g., customer networks in case of VPN services) is mitigated by the existing SRv6 data plane security mechanisms, as described in the next section.

Considerations Related to SR over IPv6 Data Plane This section provides a brief reminder and an overview of the security considerations related to SRv6 with pointers to existing specifications. This document introduces no new security considerations of its own from the SRv6 data plane perspective. SRv6 operates within a trusted SR domain. The data packets corresponding to service flows between PE routers are encapsulated (using SRv6 SIDs advertised via BGP) and carried within this trusted SR domain (e.g., within a single AS or between multiple ASes within a single provider network). The security considerations of the SR architecture are covered by . More detailed security considerations, specifically of SRv6 and SRH, are covered by as they relate to SR Attacks (Section ), Service Theft (Section ), and Topology Disclosure (Section ). As such, an operator deploying SRv6 MUST follow the considerations described in to implement the infrastructure Access Control Lists (ACLs) and the recommendations described in BCP 38 and BCP 84. The SRv6 deployment and SID allocation guidelines, as described in , simplify the deployment of the ACL filters (e.g., a single ACL corresponding to the SRv6 Block applied to the external interfaces on border nodes is sufficient to block packets destined to any SRv6 SID in the domain from external/unauthorized networks). While there is an assumed trust model within an SR domain, such that any node sending a packet to an SRv6 SID is assumed to be allowed to do so, there is also the option of using an SRH Hashed Message Authentication Code (HMAC) TLV , as described in , for validation. The SRv6 Endpoint Behaviors implementing the services signaled in this document are defined in ; hence, the security considerations of that document apply. These considerations are independent of the protocol used for service deployment, i.e., independent of BGP signaling of SRv6 services. These considerations help protect transit traffic as well as services, such as VPNs, to avoid service theft or injection of traffic into customer VPNs.

References Normative References 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. BGP-4 Multiprotocol Extensions (BGP-MP) defines the format of two BGP attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used to announce and withdraw the announcement of reachability information. This document defines how compliant systems should make use of those attributes for the purpose of conveying IPv6 routing information. [STANDARDS-TRACK] This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK] The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for TCP/IP internets. Typically, all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that Autonomous System (AS). This represents a serious scaling problem that has been well documented with several alternatives proposed. This document describes the use and design of a method known as "route reflection" to alleviate the need for "full mesh" Internal BGP (IBGP). This document obsoletes RFC 2796 and RFC 1966. [STANDARDS-TRACK] This document describes a method by which a Service Provider may use its packet-switched backbone to provide Virtual Private Network (VPN) services for its IPv6 customers. This method reuses, and extends where necessary, the "BGP/MPLS IP VPN" method for support of IPv6. In BGP/MPLS IP VPN, "Multiprotocol BGP" is used for distributing IPv4 VPN routes over the service provider backbone, and MPLS is used to forward IPv4 VPN packets over the backbone. This document defines an IPv6 VPN address family and describes the corresponding IPv6 VPN route distribution in "Multiprotocol BGP". This document defines support of the IPv6 VPN service over both an IPv4 and an IPv6 backbone, and for using various tunneling techniques over the core, including MPLS, IP-in-IP, Generic Routing Encapsulation (GRE) and IPsec protected tunnels. The inter-working between an IPv4 site and an IPv6 site is outside the scope of this document. [STANDARDS-TRACK] This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc.). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK] This document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in RFC 6513. [STANDARDS-TRACK] This document describes procedures for BGP MPLS-based Ethernet VPNs (EVPN). The procedures described here meet the requirements specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)". According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable because a session reset would impact not only routes with the offending attribute but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes. This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760, 5543, 5701, and 6368. 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. This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. This document describes how Ethernet VPN (EVPN) can be used to support the Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN accomplishes the following for VPWS: provides Single-Active as well as All-Active multihoming with flow-based load-balancing, eliminates the need for Pseudowire (PW) signaling, and provides fast protection convergence upon node or link failure. This document specifies a set of procedures for using BGP to advertise that a specified router has bound a specified MPLS label (or a specified sequence of MPLS labels organized as a contiguous part of a label stack) to a specified address prefix. This can be done by sending a BGP UPDATE message whose Network Layer Reachability Information field contains both the prefix and the MPLS label(s) and whose Next Hop field identifies the node at which said prefix is bound to said label(s). This document obsoletes RFC 3107. The MEF Forum (MEF) has defined a rooted-multipoint Ethernet service known as Ethernet-Tree (E-Tree). A solution framework for supporting this service in MPLS networks is described in RFC 7387, "A Framework for Ethernet-Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network". This document discusses how those functional requirements can be met with a solution based on RFC 7432, "BGP MPLS Based Ethernet VPN (EVPN)", with some extensions and a description of how such a solution can offer a more efficient implementation of these functions than that of RFC 7796, "Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)". This document makes use of the most significant bit of the Tunnel Type field (in the P-Multicast Service Interface (PMSI) Tunnel attribute) governed by the IANA registry created by RFC 7385; hence, it updates RFC 7385 accordingly. This document specifies how Ethernet VPN (EVPN) can be used as a Network Virtualization Overlay (NVO) solution and explores the various tunnel encapsulation options over IP and their impact on the EVPN control plane and procedures. In particular, the following encapsulation options are analyzed: Virtual Extensible LAN (VXLAN), Network Virtualization using Generic Routing Encapsulation (NVGRE), and MPLS over GRE. This specification is also applicable to Generic Network Virtualization Encapsulation (GENEVE); however, some incremental work is required, which will be covered in a separate document. This document also specifies new multihoming procedures for split-horizon filtering and mass withdrawal. It also specifies EVPN route constructions for VXLAN/NVGRE encapsulations and Autonomous System Border Router (ASBR) procedures for multihoming of Network Virtualization Edge (NVE) devices. 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 (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. The ingress node prepends an SR header to a packet containing a set of segment identifiers (SIDs). Each SID represents a topological or service-based instruction. Per-flow state is maintained only on the ingress node of the SR domain. An "SR domain" is defined as a single administrative domain for global SID assignment. This document defines an optional, transitive BGP attribute for announcing information about BGP Prefix Segment Identifiers (BGP Prefix-SIDs) and the specification for SR-MPLS SIDs. Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable. Multiprotocol BGP (MP-BGP) specifies that the set of usable next-hop address families is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a next-hop address that belongs to the IPv4 protocol when advertising IPv4 Network Layer Reachability Information (NLRI) or VPN-IPv4 NLRI. This document specifies the extensions necessary to allow the advertising of IPv4 NLRI or VPN-IPv4 NLRI with a next-hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the next hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the next hop to determine which of the protocols the address actually belongs to, and a BGP Capability allowing MP-BGP peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 next hop. This document obsoletes RFC 5549. 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. The BGP MPLS-based Ethernet VPN (EVPN) (RFC 7432) mechanism provides a flexible control plane that allows intra-subnet connectivity in an MPLS and/or Network Virtualization Overlay (NVO) (RFC 7365) network. In some networks, there is also a need for dynamic and efficient inter-subnet connectivity across Tenant Systems and end devices that can be physical or virtual and do not necessarily participate in dynamic routing protocols. This document defines a new EVPN route type for the advertisement of IP prefixes and explains some use-case examples where this new route type is used. This document describes how to support endpoints running the Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) efficiently for the multicast services over an Ethernet VPN (EVPN) network by incorporating IGMP/MLD Proxy procedures on EVPN Provider Edges (PEs). Informative References Cisco Systems Juniper Networks Cisco Systems Arrcus, Inc Edward Jones Work in Progress This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS (Denial of Service) attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering, and delves into the effects on multihoming in particular. This memo updates RFC 2827. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Border Gateway Protocol 4 (BGP-4), along with a host of other infrastructure protocols designed before the Internet environment became perilous, was originally designed with little consideration for protection of the information it carries. There are no mechanisms internal to BGP that protect against attacks that modify, delete, forge, or replay data, any of which has the potential to disrupt overall network routing behavior. This document discusses some of the security issues with BGP routing data dissemination. This document does not discuss security issues with forwarding of packets. This memo provides information for the Internet community. This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK] In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider. These protocols and procedures are specified in this document. [STANDARDS-TRACK] This document analyzes TCP-based routing protocols, the Border Gateway Protocol (BGP), the Label Distribution Protocol (LDP), the Path Computation Element Communication Protocol (PCEP), and the Multicast Source Distribution Protocol (MSDP), according to guidelines set forth in Section 4.2 of "Keying and Authentication for Routing Protocols Design Guidelines", RFC 6518. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. This document defines a BGP path attribute known as the "Tunnel Encapsulation attribute", which can be used with BGP UPDATEs of various Subsequent Address Family Identifiers (SAFIs) to provide information needed to create tunnels and their corresponding encapsulation headers. It provides encodings for a number of tunnel types, along with procedures for choosing between alternate tunnels and routing packets into tunnels. This document obsoletes RFC 5512, which provided an earlier definition of the Tunnel Encapsulation attribute. RFC 5512 was never deployed in production. Since RFC 5566 relies on RFC 5512, it is likewise obsoleted. This document updates RFC 5640 by indicating that the Load-Balancing Block sub-TLV may be included in any Tunnel Encapsulation attribute where load balancing is desired. Cisco Systems Cisco Systems Bell Canada British Telecom Microsoft Work in Progress

Acknowledgements The authors of this document would like to thank , , , , , , , , , , and for their comments and review of this document. The authors would also like to thank Document Shepherd for his review and AD for his review that resulted in helpful comments for improving this document.

Contributors Cisco

cfilsfil@cisco.com

SoftBank

satoru.matsushima@g.softbank.co.jp

Steinberg Consulting

dirk@lapishills.com

Bell Canada

daniel.bernier@bell.ca

Bell Canada

daniel.voyer@bell.ca

Individual

john@leddy.net

Cisco

swaagraw@cisco.com

Cisco

pbrisset@cisco.com

Cisco

sajassi@cisco.com

Proximus

Belgium bart.peirens@proximus.com

Cisco

ddukes@cisco.com

Cisco

pcamaril@cisco.com

Cisco

shyam.ioml@gmail.com

Cisco

zali@cisco.com

Authors' Addresses LinkedIn

United States of America gdawra.ietf@gmail.com

Cisco Systems

India ketant.ietf@gmail.com

NTT Network Innovations

940 Stewart Dr. Sunnyvale CA 94085 United States of America robert@raszuk.net

Orange

France bruno.decraene@orange.com

Huawei Technologies

China zhuangshunwan@huawei.com

Nokia

United States of America jorge.rabadan@nokia.com