BGP based Virtual Private Network (VPN) Services over SRm6 enabled IPv6 networks

Virtual Private Network (VPN) technologies allow network providers to emulate private networks with shared infrastructure. For example, assume that a set of red sites, set of blue sites and a set of green sites connect to a provider network. Furthermore, assume that red sites and blue sites wish to interconnect, exchange packets. However, the green sites wish to communicate with green sites only. The provider should allow its infrastructure network to scale to both the requirements without having to create multiple parallel network infrastructures. The IETF has standardized many VPN technologies viz. Layer 3 VPN (L3VPN) , Layer 2 VPN (L2VPN), Virtual Private LAN Service (VPLS) , , Ethernet VPN (EVPN) , Pseudowires to enable Layer 3 and Layer 2 VPN services. The aforementioned technologies leverage MPLS network architecture : to establish a MPLS tunnel from ingress PE to egress PE, thus making all P routers agnostic of VPN state. to provide demultiplexing abstraction in the tunnelled packet so the payload packet can be forwarded at the egress router based on Routing table and/or interface. In pure IPv6 deployments where there may be non-MPLS capable routers, it would be desirable to have alternate mechanism to provide VPN connectivity. This document describes BGP extensions and procedures applicable for SRm6 enabled IPv6 networks, to provide VPN services over BGP.

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.

A SRm6 segment provides unidirectional connectivity from an ingress node to an egress node. A SRm6 path contains one or more such segments. SRm6 introduces the concept of Per-Segment Service Instruction and Per-Path Service Instruction. These instructions describe the additional packet processing performed on a node. The Per-Segment Service Instruction is executed on the segment egress node while the Per-Path Service Instruction is executed on the path egress node. The SR Path egress node advertises the service prefix reachability information to SR Path ingress node via Multi-Protocol extensions in BGP . For providing VPN services, aforementioned BGP extensions rely on MPLS architecture . The BGP extensions specify the new encoding for Network Layer Reachability Information (NLRI) to include the MPLS VPN labels . Such a MPLS VPN label is associated with a forwarding decision in the VPN Routing Instance on the egress BGP Router. The ingress BGP router will push the VPN label on the data packet destined to the egress BGP router. The transport tunnel from ingress router to egress router can be MPLS or GRE or L2TPv3, but inner payload is a MPLS packet as described in , , . The intermediate routers do not process the VPN label [a.k.a.] embedded label as described in . To provide BGP based VPN services on a non-MPLS IPv6 networks, it would be beneficial to retain the benefits of BGP protocol extensions while leveraging the benefits of IPv6 . describes SRm6 paths as programmable with Tunnel Payload Forwarding information (TPF) that determine how egress nodes process SRm6 payloads. The TPF information is carried in the Tunnel Payload Forwarding Option encoded in the IPv6 Destination Option Header . The Tunnel Payload Forwarding (TPF) information is defined as follows: 32 bit quantity. The TPF information have node-local significance and is assigned by the egress BGP router. The value of zero is reserved. The TPF information will serve 2 purposes. It MUST uniquely identify the VPN Routing Instance for L3VPN or identify an Ethernet Segment for EVPN or identify a leaf property for EVPN TREE upon which forwarding decision can be taken. It MAY provide information for special processing before the packet is forwarded. The structure of TPF information will be updated in the next version of this document. The encoding of the Tunnel Payload Forwarding information for VPNs is described in and .

This document defines a new Tunnel type : SRm6. The format is as per below. Tunnel Type (2 Octets) : To be assigned Tunnel Length (2 Octets) : 1 Value : List of Sub-TLVs defines many sub-TLVs for the tunnels. The encoding for them are as follows: Tunnel Endpoint Sub-TLV : As per Encapsulation Sub-TLV : Not needed. IPv4 DS Field Sub-TLV : Not needed. UDP Destination Port Sub-TLV : Not needed. Protocol Type Sub-TLV : As per . Color Sub-TLV : As per . Embedded Label Handling Sub-TLV : 3. MPLS Label Stack Sub-TLV : Not needed. Prefix SID Sub-TLV : Not Needed. The Tunnel Encapsulation Attribute is a an Optional Transitive attribute as described in . This attribute with SRm6 tunnel type MUST be present in the BGP update carrying the Network Layer Reachability Information encoded with the TPF information. This document refers to the NLRI that is associated with SRm6 Tunnel Encapsulation attribute as SRm6_NLRI. The document defines the encoding for sub-TLV as follows. Sub-TLV Type : 1 octet Sub-TLV Length : 1 or 2 octets Sub-TLV Value : defined per Sub-TLV as per below. The Tunnel Endpoint Sub-TLV can specify the IPv6 address of the egress router as the final destination address of SRm6 packet which is also referred to as SR Path destination address. The sub-fields on this sub-TLV is encoded as below. Autonomous System Number : AS number of the IPv6 SR domain. Address Family : 2 (refers to IPv6). Address : IPv6 address of the egress interface present in SRm6 domain. The Value field may be set to 0 which indicates that next hop value in the NLRI should be chosen for the SRm6 Path destination address. The Embedded Label Handling Sub-TLV describes how the label field in the NLRI should be interpreted. Value : MUST be set to 3. The specifies only 2 values. While the value 1 refers to label field as MPLS embedded label that is carried at the top of the label stack of the MPLS payload packet, the value 2 refers to label field to be either ignored or carried in the virtual network field of the encapsulation header. This document defines another behavior for the label field. The value 3 will indicate that value in the label field MUST be inserted in the Destination Options Header of the IPv6 Tunnel header. The Tunnel Encapsulation attribute can carry one or more Tunnel types. The local policy on the ingress router can determine which Tunnel type to be used for the NLRI. The Tunnel Endpoint address MUST be set only by the egress BGP router that is the endpoint of the SRm6 path.

The TPF information instructs the egress router to de-encapsulate the packet and forward the newly exposed payload inner packet through the specified interface or forward using the specified Routing Instance. The TPF information described in will be assigned by the egress BGP Router. When the egress BGP Speaker advertises the NLRI, it will include the TPF information in the encoding described in and . The egress BGP Speaker MUST include the Tunnel Encapsulation Attribute with Route type SRm6 as described in in such BGP updates. By tagging the BGP update with Tunnel Encapsulation attribute of SRm6 type, the BGP Speaker informs how the SRm6_NLRI should be decoded and processed by the receiving BGP Speaker. Via the Remote Tunnel Endpoint Sub-TLV encoding, the egress BGP router may specify the SRm6 Path Destination Address. The Protocol type Sub-TLV and the Color Sub-TLV may be used by the egress BGP router to influence the payload packets to be put on SRm6 path. The Embedded Label Handling Sub-TLV MUST be set to 3 to inform that the label field MUST be used to form the TPF option that is inserted in the Destination Options Header at the ingress router as described in . A single TPF information may be associated with all the prefixes in a Routing Instance or a unique TPF information may be associated for each prefix in the Routing Instance. Similarly, a TPF information may be assigned to identify an Ethernet segment or leaf AC property by EVPN. The choice is left to the Network Operator and is outside the scope of this document.

Upon receiving a BGP update, the receiving BGP Speaker will look for Tunnel Encapsulation attribute. If the tunnel type carried in the Tunnel Encapsulation attribute is SRm6, the BGP updates is said to be carrying the SRm6_NLRI and the Label field in the Network Layer Reachability Information is treated as Tunnel Payload Forwarding information (TPF). The tuple (TPF information, Prefix) is programmed in the forwarding infrastructure of the router. The manner in which this tuple is stored in the router is outside the scope of this document. If SRm6 has been enabled on the router, such a tuple SHOULD be used for encoding the Destination Options Header as described in . The describes how Tunnel Endpoint Sub-TLV has to be processed. It also describes the usage of the Protocol type Sub-TLV and the Color Sub-TLV. This may be used by the ingress BGP router to select the payload packets that should be put on SRm6 path. The Embedded Label Handling Sub-TLV value that is set to 3 indicates that ingress BGP router to use the value of label field to construct the Tunnel Payload Forwarding Option that is inserted in the Destination Options Header of the Tunnel IPv6 packet.

The BGP Nexthop attribute handling procedures are described in while describe the handling procedures for the Nexthop field in the MP_REACH attribute. The target="I-D.ietf-idr-tunnel-encaps"/> describes the Tunnel Endpoint sub-TLV in the Tunnel Encapsulation Attribute as the next hop address to which the prefix should be forwarded to. If a BGP update has such a Tunnel Encapsulation Attribute it prescribes that the Tunnel Endpoint Sub-TLV if non-zero, MUST be used as the next hop to send the packet to. There may be instances where the BGP update carrying the SRm6 NLRI will cross Autonomous boundary. The BGP update with SRm6 NLRI MUST always carry the Tunnel Encapsulation Attribute. If any router along the path wishes to change the Tunnel Endpoint Sub-TLV next hop address, it MUST also update the TPF information field of the The BGP update carrying the SRm6 NLRI. It should be noted that router that modifies the Tunnel Endpoint sub-TLV of the Tunnel Encapsulation attribute present in the SRm6 update must be able to stitch the egress tunnel and ingress tunnel.

The Egress and Ingress BGP speakers form a BGP peering session to exchange a set of prefixes described in and Multi-Protocol extensions . The BGP Router capable of SRm6 that is enabled to carry L3 VPN services over IPv6 networks should follow the procedures mentioned in and . The manner in which a BGP Router is configured for SRm6 underlay and L3 VPN overlay is outside the scope of this document.

The IPv4 L3 VPN over IPv6 is defined in . The MP_REACH NLRI and Tunnel Encapsulation attribute encoding is as per below: AFI : 1; SAFI : 128 Length of the Next Hop : 16 (or 32 if Link Local) Network address of the Next Hop : IPv6 address of the egress BGP Router NLRI : IPv4-VPN routes Label : Low order 24 bits of Tunnel Payload Forwarding (TPF) information Tunnel Encapsulation Path Attribute : SRm6 Type as described in The TPF information is associated with VPN Routing Instance on the Egress PE. The Tunnel Encapsulation attribute with SRm6 type MUST be appended to the Path attributes associated with the NLRI.

The IPv6 L3 VPN over IPv6 is defined in . The MP_REACH NLRI and Tunnel Encapsulation attribute encoding is as per below: AFI : 2; SAFI : 128 Length of the Next Hop : 16 (or 32 if Link Local) Network address of the Next Hop : IPv6 address of the egress BGP Router NLRI : IPv6-VPN routes Label : Low order 24 bits of Tunnel Payload Forwarding (TPF) information Tunnel Encapsulation Path Attribute : SRm6 Type as described in The TPF information is associated with VPN Routing Instance on the Egress PE. The Tunnel Encapsulation attribute with SRm6 type MUST be appended to the Path attribute associated with the NLRI.

The IPv4 L3 VPN over IPv6 is defined in . The MP_REACH NLRI and Tunnel Encapsulation attribute encoding is per below: AFI : 1; SAFI : 1 Length of the Next Hop : 16 (or 32 if Link Local) Network address of the Next Hop : IPv6 address of the egress BGP Router NLRI : IPv4 routes Label : Low order 24 bits of Tunnel Payload Forwarding (TPF) information Tunnel Encapsulation Path Attribute : SRm6 Type as described in The TPF information is associated with VPN Routing Instance on the Egress PE. The Tunnel Encapsulation attribute with SRm6 type MUST be appended to the Path attribute associated with the NLRI.

The describes the BGP extensions for carrying the Ethernet Virtual Private Network Overlay on MPLS network. It defines 4 types of EVPN NLRI. This document specifies changes to certain fields for those NLRIs. Ethernet Auto-Discovery (A-D) route MAC/IP Advertisement route Inclusive Multicast Ethernet Tag route IP Prefix route

The MP_REACH and MP_UNREACH attributes will carry this route in the NLRI encoding described in . In addition to Tunnel Encapsulation attribute encoding, this document recommends to follow the encoding except the following. For MPLS label carried in the Ethernet A-D per ESI route: MPLS label : Per , it is set to zero. Tunnel Encapsulation Path Attribute : SRm6 Type as described in The MPLS label field is not part of the route but treated as route attribute. For procedures and usage of this route, refer to . The Tunnel Encapsulation attribute with SRm6 type MUST be appended to the Path attribute associated with the NLRI. An EVPN Ethernet per ES A-D route is usually signaled together with an ESI label extended community. For ESI Label carried in the ESI label extended community: ESI Label: Low order 24 bits of the Tunnel Payload Forwarding (TPF) information The TPF information is used to identify an Ethernet segment attached to the BGP PE for EVPN.

The MP_REACH and MP_UNREACH attributes will carry this route in the NLRI encoding described in . In addition to Tunnel Encapsulation attribute encoding, this document recommends to follow the encoding except the following: MPLS label : Low order 24 bits of Tunnel Payload Forwarding (TPF) information Tunnel Encapsulation Path Attribute : SRm6 Type as described in The MPLS label field is not part of the route but treated as route attribute. For procedures and usage of this route, refer to . The Tunnel Encapsulation attribute with SRm6 type MUST be appended to the Path attribute associated with the NLRI. In addition, for EVPN E-tree service, this route may be signaled together with an E-Tree Extended Community as it is specified in . For the leaf label carried in the E-Tree Extended Community: Leaf Label: Low order 24 bits of the Tunnel Payload Forwarding (TPF) information In case of EVPN E-tree service, the TPF information carried in the E-Tree extended community is used to signal a leaf AC property. In the data plane, this TPF information specified in the Destination Option header is used by an egress router to identify that a data packet is ingressed from a leaf AC such that appropriate forwarding decision can be made.

The MP_REACH and MP_UNREACH attributes will carry this route in the NLRI encoding described in [RFC7432]. In addition to Tunnel Encapsulation attribute encoding, this document recommends to follow the [RFC7432] encoding except the following. If MPLS label field in the PMSI Tunnel Attributed is non-zero, it is set to Low order 24 bits of the Tunnel Payload Forwarding (TPF) information. Tunnel Encapsulation Path Attribute : SRm6 Type as described in The Tunnel Encapsulation attribute with SRm6 type MUST be appended to the Path attribute associated with the NLRI.

This document proposes to reuse the NLRI encoding for BGP L3VPN and EVPN Network Layer Routing Information. However, care should be taken when BGP VPN overlay services are enabled on SRm6 underlay such that Tunnel Encapsulation Path attribute with SRm6 type MUST be appended. When a BGP router advertises SRm6_NLRI, it MUST NOT remove the Tunnel Encapsulation Path attribute. The SRm6 underlay is similar to other "tunnel" technologies viz MPLS, GRE, IP-in-IP, L2TPv3. The egress and ingress BGP routers can be connected via one or more such underlay technologies. A BGP speaker can advertise the VPN NLRI with the nexthop reachable via one or more such underlay paths. Each such mechanism can co-exist together as ships-in-night. However, when SRm6_NLRI is advertised by a egress BGP speaker and received by an ingress BGP speaker, they MUST follow the procedures mentioned in this document. For migrating a BGP router to SRm6 the following procedures can be followed. Operator will enable SRm6 underlay on the ingress and egress routers identifying the SRm6 path from ingress router's interface to egress router's interface. The way to configure the ingress and egress routers are outside the scope of this document. SRm6 enabled ingress BGP router will setup the additional information in the forwarding table such that it can append an IPv6 tunnel header and encode the TPF Option in the Destination Options Header. SRm6 enabled egress BGP router will setup the additional information in the forwarding table such that TPF information can be used to lookup to find the Routing Instance and make the forwarding decision. Operator will enable BGP VPN overlay over SRm6 underlay on ingress router. This means that ingress router will start looking for SRm6_NLRI in the BGP updates. The way to enable the BGP VPN overlay over SRm6 underlay is outside the scope of this document. The operator will enable BGP VPN overlay over SRm6 underlay on egress router. With this, the egress router will create TPF information and associate it with Routing Instances. It then advertises the SRm6_NLRIs to the ingress BGP router. The ingress router will interpret the SRm6_NLRIs and use TPF information and follow the procedures in to encode the Destination Options Header to forward the data packet. Now that SRm6 path is setup between ingress and egress BGP routers, on the egress BGP router the Operator can migrate the Routing Instances from MPLS VPN set of Instances to SRm6 enabled set of Instances. The way to configure Routing Instances to achieve the above is outside the scope of this document.

The extension proposed in this document is backward compatible with procedures described for BGP enabled services.

This document does not introduce any new security considerations beyond those already specified in , and .

IANA is requested to assign a code point for SRm6 Route Type for BGP Tunnel Encapsulation Path Attribute from BGP Tunnel Encapsulation Attribute Tunnel Types Registry.

The authors would like to thank Jeff Haas, Wen Lin and Shraddha Hegde for careful review and suggestions.