IPv6-Only PE Design All SAFI

IPv6-Only PE Design All SAFI Verizon Inc.

gyan.s.mishra@verizon.com

Cisco Systems

821 Alder Drive, MILPITAS CALIFORNIA 95035 mankamis@cisco.com

Microsoft, Inc.

jefftant.ietf@gmail.com

Juniper Networks, Inc.

smadhavi@juniper.net

Arista Networks

qyang@arista.com

Nokia

adam.1.simpson@nokia.com

Huawei Technologies

chenshuanglong@huawei.com

BESS Working Group As Enterprises and Service Providers upgrade their brown field or green field MPLS/SR core to an IPv6 transport, Multiprotocol BGP (MP-BGP)now plays an important role in the transition of their Provider (P) core network as well as Provider Edge (PE) Inter-AS peering network from IPv4 to IPv6. Operators must be able to continue to support IPv4 customers when both the Core and Edge networks are IPv6-Only. This document details an important External BGP (eBGP) PE-PE Inter-AS IPv6-Only peering design that leverages the MP-BGP capability exchange by using IPv6 peering as pure transport, allowing all and any IPv4 Network Layer Reachability Information (NLRI) and IPv6 Network Layer Reachability Information (NLRI)to be carried over the same (Border Gateway Protocol) BGP TCP session for all Address Family Identifiers (AFI) and Subsequent Address Family Identifiers(SAFI). The design change provides the same Dual Stacking functionality that exists today with separate IPv4 and IPv6 BGP sessions as we have today. With this IPv6-Only PE Design, IPv4 address MUST not be configured on the the Provider Edge (PE) - Customer Edge (CE), or Inter-AS ASBR (Autonomous System Boundary Router) to ASBR (Autonomous System Boundary Router) PE-PE Provider Edge (PE) - Provider Edge (PE). From a control plane perspective a single IPv6-Only peer is required for both IPv4 and IPv6 routing updates and from a data plane forwarindg perspective an IPv6 address need only be configured on the PE to PE Inter-AS peering interface for both IPv4 and IPv6 packet forwarding. This document defines the IPv6-Only PE Design as a new PE-CE Edge and ASBR-ASBR PE-PE Inter-AS BGP peering Standard which is described in the POC testing document which is now extended to support to all AFI/SAFI ubiquitously. As service providers migrate to Segment Routing architecture SR-MPLS and SRv6, VPN overlay exsits as well, and thus Inter-AS options Option-A, Option-B, Option-AB and Option-C are still applicable and thus this extension of IPv6-Only peering architecure extension to Inter-AS peering is very relevant to Segment Routing as well.

As Enterprises and Service Providers upgrade their brown field or green field MPLS/SR core to an IPv6 transport such as MPLS LDPv6, SR-MPLSv6 or SRv6, Multiprotocol BGP (MP-BGP) now plays an important role in the transition of the Provider (P) core networks and Provider Edge (PE) edge networks from IPv4 to IPv6. Operators have a requirement to support IPv4 customers and must be able to support IPv4 address family and Sub-Address-Family Virtual Private Network (VPN)-IPv4, and Multicast VPN IPv4 customers. IXP are also facing IPv4 address depletion at their peering points, which are large Layer 2 transit backbones that service providers peer and exchange IPv4 and IPv6 Network Layer Reachability Information (NLRI). Today, these transit exchange points are Dual Stacked. With this IPv6-only BGP peering design, only IPv6 MUST be configured on the PE-PE inter-as peering interface, the Inter-AS Provider Edge (PE) - Provider Edge (PE), the IPv6 BGP peer is now used to carry IPv4 (Network Layer Reachability Information) NLRI over an IPv6 next hop using IPv6 next hop encoding defined in , while continuing to forward both IPv4 and IPv6 packets. With this IPv6-Only PE Design, ASBRs providing Inter-AS options peering PE to PE extending L3 VPN services is now no longer Dual Stacked and as well can support ALL AFI/SAFI. 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). Historically 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 or VPN-IPv4. specifies the extensions necessary to allow advertising IPv4 NLRI, Virtual Private Network Unicast (VPN-IPv4) NLRI, Multicast Virtual Private Network (MVPN-IPv4) NLRI with a Next Hop address that belongs to the IPv6 protocol. This comprises of an extended next hop encoding MP-REACH BGP capability exchange to allow the address of the Next Hop for IPv4 NLRI, VPN-IPv4 NLRI and MVPN-IPv4 NLRI to also belong to the IPv6 Protocol. defines the encoding of the Next Hop to determine which of the protocols the address actually belongs to, and a new BGP Capability allowing MP-BGP Peers to discover dynamically whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. The current specification for carrying IPv4 NLRI of a given address family via a Next Hop of a different address family is now defined in , and specifies the extended next hop encoding MP-REACH capability extension necessary to do so. 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 belong to either the IPv4 or the IPv6 protocol, the encoding of the Next Hop information to determine which of the protocols the address belongs to, and a new BGP Capability allowing MP-BGP peers to dynamically discover whether they can exchange IPv4 NLRI and VPN- IPv4 NLRI with an IPv6 Next Hop. With the new extensions defined in supporting NLRI and next hop address family mismatch, the BGP peer session can now be treated as a pure TCP transport and carry both IPv4 and IPv6 NLRI at the Provider Edge (PE) - Customer Edge (CE) over a single IPv6 TCP session. This allows for the elimination of dual stack from the PE-PE Inter-AS peering point, and now enable the Inter-AS peering to be IPv6-ONLY. The elimination of IPv4 Inter Provider ASBR tie point, PE-PE Inter-AS peering points translates into OPEX expenditure savings of point-to-point infrastructure links as well as /31 address space savings and administration and network management of both IPv4 and IPv6 BGP peers. This reduction decreases the number of PE-PE Inter-AS options BGP peers by fifty percent, which is a tremendous cost savings for operators. While the savings exists at the Edge eBGP PE-PE Inter-AS peering, on the core side PE to Route Reflector (RR) peering carrying <AFI/SAFI> IPv4 <1/1>, VPN-IPV4 <1/128>, and Multicasat VPN <1/129>, there is no savings as the Provider (P) Core is IPv6 Only and thus can only have an IPv6 peer and must use extended next hop encoding to carrying IPv4 NLRI IPV4 <2/1>, VPN-IPV4 <2/128>, and Multicast VPN <2/129> over an IPv6 next hop. This document defines the IPv6-Only PE Design Architecture details for External BGP (eBGP) PE-PE Inter-AS IPv6-Only peering design that leverages the MP-BGP capability exchange by using IPv6 peering as pure transport, allowing all and any IPv4 Network Layer Reachability Information (NLRI) and IPv6 Network Layer Reachability Information (NLRI)to be carried over the same (Border Gateway Protocol) BGP TCP session for all Address Family Identifiers (AFI) and Subsequent Address Family Identifiers(SAFI). The design change provides the same Dual Stacking functionality that exists today with separate IPv4 and IPv6 BGP sessions as we have today. With this IPv6-Only PE Design, IPv4 address MUST not be configured on the the Provider Edge (PE) - Customer Edge (CE), or Inter-AS ASBR (Autonomous System Boundary Router) to ASBR (Autonomous System Boundary Router) PE-PE Provider Edge (PE) - Provider Edge (PE). From a control plane perspective a single IPv6-Only peer MUST be configured for both IPv4 and IPv6 routing updates, and from a data plane forwarindg perspective only an IPv6 address MUST be configured on the PE-CE Edge or ASBR-ASBR, PE to PE Inter-AS peering interface for both IPv4 and IPv6 packet forwarding for all AFI/SAFI. This document defines the IPv6-Only PE Design as a new Intra-AS PE-CE Edge and Inter-AS PE-PE BGP peering Standard which is described in the POC testing document in detail, which is now extended for applicability to to all AFI/SAFI ubiquitously. As service providers migrate to Segment Routing architecture SR-MPLS and SRv6, VPN overlay exsits as well, and thus Inter-AS options Option-A, Option-AB and Option-C are still applicable and thus this extension of IPv6-Only peering architecure extension to Inter-AS peering is very relevant to Segment Routing as well as well as any other applicable AFI/SAFI is now as well relevant. This IPv6-Only PE ALL SAFI Design details an important External BGP (eBGP) PE-PE Inter-AS IPv6-Only peering design that leverages the MP-BGP capability exchange by using IPv6 peering as pure transport, allowing all and any IPv4 Network Layer Reachability Information (NLRI) and IPv6 Network Layer Reachability Information (NLRI) to be carried over the same (Border Gateway Protocol) BGP TCP session for all remaining Address Family Identifiers (AFI) and Subsequent Address Family Identifiers(SAFI) below as well that can be carried over IPv6-Only Inter-AS peerings: <AFI/SAFI> MCAST-VPN <1/5>, NLRI Multi-Segment Pseudowires <1/6>, BGP Tunnel Encapsulation SAFI <1/7>, MCAST-VPLS <1/8>, Tunnel SAFI <1/6>, BGP MDT SAFI <1/66>, BGP 4to6 SAFI <1/67>, BGP 6to4 SAFI draft xx <1/8>, Layer 1 VPN Auto-Discovery <1/69>, SR-TE Policy SAFI draft <1/73>, BGP 6to4 SAFI draft <1/8>, SDN WAN Capabilities draft <1/74>, Classful-Transport SAFI draftxx <1/76>, Tunneled Traffic FlowSpec draftxx <1/77>, MCAST-TREE SAFI draft xx <1/78>, Route Target Constraints <1/132>, Dissemination of Flow Specification Rules <1/133>, L3 VPN Dissemination of Flow Specification Rules <1/1344>, VPN Auto-Discovery SAFI draftxx <1/140>

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.

Terminolgoy used in defining the IPv6-Only Edge specification. AFBR: Address Family Border Router Provider Edge (PE). Edge: PE-CE Edge Network Provider Edge - Customer Edge Core: P Core Network Provider (P) 4to6 Softwire : IPv4 edge over an IPv6-Only core 6to4 Softwire: IPv6 edge over an IPv4-Only core E2E: End to End

This specification addresses a real issue that has been discussed at many operator with extremely large core networks around the world related migration to IPv6 underlay transport which can be put off indefinitely. Operators around the world are clamoring for a solution that can help solve issues related to IPv4 address depletion at these large IXP peering points. With this solution, infrastructure networks such as Core networks, DC networks, Access networks as well as any PE-CE public or private network can now utilize this IPv4-Only Edge solution and reap the benefits immediately on IPv6 address space saving and CAPEX and OPEX savings.

Problem Statement Dual Stacked Dual Stacked CE PE +-------+ IPv4 BGP Peer +-------+ | |---------------| | | CE | IPv6 BGP Peer | PE | | |---------------| | +-------+ +-------+ IPv4 forwarding IPv4 forwarding IPv6 forwarding IPv6 forwarding

________ Dual Stacked _____ / \ Dual Stacked PE / CE / \__/ \___ PE / CE +----+ +----+ / \ +------+ +-----+ | | | | |0====VPN Overlay Tunnel ==0| | | | | | | | | | \ | | | | | CE |--| PE |--\ IPv6-Only Core |----| PE |---| CE | | | | | \0=========Underlay =======0| | | | | +----+ +----+ \ __/ +------+ +-----+ IPv4 IPv6 BGP peer \ IP / MPLS / SR domain / IPv4 and IPv6 BGP peer IPv4 forwarding \__ __ / IPv4 forwarding IPv6 forwarding \_______/ \_____/ IPv6 forwarding

The IPv6-Only Edge design solution applies to any and all IPv4 Network Layer Reachability Information (NLRI) and IPv6 Network Layer Reachability Information (NLRI) over an IPv6-Only BGP Peering session. 2 Main scenario groupings for the IPv6-Only PE Design ALL SAFI Group-1 PE-CE Group-2 PE-PE Inter-AS Group-1 Edge Customer IPv4/IPv6 NLRI PE-CE AFI / SAFI grouping (CP-DP) Unicast AFI/SAFI 1/1 IPv4 Unicast 2/1 IPv6 Unicast Multicast AFI/SAFI 1/2 IPv4 Multicast 2/2 IPv6 Multicast AFI/SAFI 1/78 IPv4 MCAST-TREE SAFI 2/78 MCAST-TREE SAFI Group-2 ASBR-ASBR Inter AS Customer IPv4/IPv6 NLRI AFI/SAFI grouping (CP-DP) Unicast Global Table AFI/SAFI 1/4 4PE L3 VPN AFI/SAFI 1/128 IPv4 VPN 2/128 IPv6 VPN AFI/SAFI 1/132 IPv4 RTC 2/132 IPv6 RTC AFI/SAFI 1/140 IPv4 VPN Auto Discovery 2/140 IPv6 VPN Auto Discovery Multicast Global Table AFI/SAFI 1/2 IPv4 Multicast 2/2 IPv6 Multicast L3 VPN AFI/SAFI 1/129 IPv4 MVPN 2/129 IPv6 MVPN AFI/SAFI 1/5 IPv4 MCAST-VPN 2/5 IPv6 MCAST-VPN AFI/SAFI 1/66 IPv4 BGP MDT SAFI 2/66 IPv6 BGP MDT SAFI AFI/SAFI 1/78 IPv4 MCAST-TREE SAFI 2/78 MCAST-TREE SAFI L1 and L2 VPN L2 VPN related NLRI control plane in BGP AFI/SAFI 1/6 IPv4 Multi Segment PW 2/6 IPv6 Multi Segment PW AFI/SAFI 1/69 L1 VPN Auto Discovery 2/69 L1 VPN Auto Discovery Multicast AFI/SAFI 1/8 IPv4 MCAST-VPLS 2/8 IPv6 MCAST-VPLS Tunnel AFI/SAFI 1/64 Tunnel-SAFI 2/64 Tunnel-SAFI AFI/SAFI 1/67 BGP 4over6 Tunnel SAFI 2/67 BGP 4over6 Tunnel SAFI AFI/SAFI 1/68 BGP 6over4 Tunnel SAFI 2/68 BGP 6over4 Tunnel SAFI BGP Policy and Flowspec Policy and Misc Policy AFI/SAFI 1/73 SR-TE Policy SAFI 2/73 SR-TE Policy SAFI AFI/SAFI 1/74 SD-WAN Capabilities 2/74 SD-WAN Capabilities AFI/SAFI 1/77 Tunneled Traffic Flowspec 2/77 Tunneled Traffic Flowspec AFI/SAFI 1/133 Dissemination of Flowspec Rules 2/133 133 Dissemination of Flowspec Rules AFI/SAFI 1/134 L3 VPN 133 Dissemination of Flowspec Rules 2/134 L3VPN Dissemination of Flowspec Rules AFI/SAFI 1/79 BGP-DPS Arista 2/79 BGP-DPS Arista AFI/SAFI 1/83 BGP CAR 2/83 BGP CAR AFI/SAFI 1/84 BGP VPN CAR 2/84 BGP VPN CAR AFI/SAFI 1/85 BGP MUP SAFI 2/85 BGP MUP SAFI

Solution applicable to all AFI/SAFI AFI/SAFI 1/X 2/X Where X = ALL SAFI +-------+ +-------+ | AS1 | IPv6 Only | AS2 | | PE1 |----------------| PE2 | | (ASBR)| IPv6 BGP Peer |(ASBR) | +-------+ +-------+ IPv4 forwarding IPv4 forwarding IPv6 forwarding IPv6 forwarding

The IPv6-Only Edge Peering design utilizes two key E2E Softwire Mesh Framework scenario's, 4to6 softwire and 6to4 softwire. The Softwire mesh framework concept is based on the overlay and underlay MPLS or SR based technology framework, where the underlay is the transport layer and the overlay is a Virtual Private Network (VPN) layer, and is the the tunneled virtualization layer containing the customer payload. The concept of a 6to4 Softwire is based on transmission of IPv6 packets at the edge of the network by tunneling the IPv6 packets over an IPv4-Only Core. The concept of a 4to6 Softwire is also based on transmission of IPv4 packets at the edge of the network by tunneling the IPv4 packets over an IPv6-Only Core. This document describes End to End (E2E) test scenarios that follow a packet flow from IPv6-Only attachment circuit from ingress PE-CE to egress PE-CE tracing the routing protocol control plane and data plane forwarding of IPv4 packets in a 4to6 softwire or 6to4 softwire within the IPv4-Only or IPv6-Only Core network. In both secneario we are focusing on IPv4 packets and the control plane and data plane forwarding aspects of IPv4 packets from the PE-CE Edge network over an IPv6-Only P (Provider) core network or IPv4-Only P (Provider) core network. With this IPv6-Only Edge peering design, the Softwire Mesh Framework is not extended beyond the Provider Edge (PE) and continues to terminate on the PE router.

6to4 softwire where IPv6-Edge eBGP IPv6 peering where IPv4 packets at network Edge traverse a IPv4-Only Core In the scenario where IPv4 packets originating from a PE-CE edge are tunneled over an MPLS or Segment Routing IPv4 underlay core network, the PE and CE only have an IPv6 address configured on the interface. In this scenario the IPv4 packets that ingress the CE from within the CE AS are over an IPv6-Only interface and are forwarded to an IPv4 NLRI destination prefix learned from the Pure Transport Single IPv6 BGP Peer. In the IPv6-Only Edge peering architecture the PE is IPv6-Only as all PE-CE interfaces are IPv6-Only. However, on the CE, the PE-CE interface is the only interface that is IPv6-Only and all other interfaces may or may not be IPv6-Only. Following the data plane packet flow, IPv4 packets are forwarded from the ingress CE to the IPv6-Only ingress PE where the VPN label imposition push per prefix, per-vrf, per-CE occurs and the labeled packet is forwarded over a 6to4 softwire IPv4-Only core, to the egress PE where the VPN label disposition pop occurs and the native IPv4 packet is forwarded to the egress CE. In the reverse direction IPv4 packets are forwarded from the egress CE to egress PE where the VPN label imposition per prefix, per-vrf, per-CE push occurs and the labeled packet is forwarded back over the 6to4 softwire IPv4-Only core, to the ingress PE where the VPN label disposition pop occurs and the native IPv4 packet is forwarded to the ingress CE. . The functionality of the IPv4 forwarding plane in this scenario is identical from a data plane forwarding perspective to Dual Stack IPv4 forwarding scenario.

+--------+ +--------+ | IPv4 | | IPv4 | | Client | | Client | | Network| | Network| +--------+ +--------+ | \ / | | \ / | | \ / | | X | | / \ | | / \ | | / \ | +--------+ +--------+ | AFBR | | AFBR | +--| IPv4/6 |---| IPv4/6 |--+ | +--------+ +--------+ | +--------+ | | +--------+ | IPv4 | | | | IPv4 | | Client | | | | Client | | Network|------| IPv4 |-------| Network| +--------+ | only | +--------+ | | | +--------+ +--------+ | +--| AFBR |---| AFBR |--+ | IPv4/6 | | IPv4/6 | +--------+ +--------+ | \ / | | \ / | | \ / | | X | | / \ | | / \ | | / \ | +--------+ +--------+ | IPv6 | | IPv4 | | Client | | Client | | Network| | Network| +--------+ +--------+

4to6 softwire where IPv6-Edge eBGP IPv6 peering where IPv4 packets at network Edge traverse a IPv6-Only Core In the scenario where IPv4 packets originating from a PE-CE edge are tunneled over an MPLS or Segment Routing IPv4 underlay core network, the PE and CE only have an IPv6 address configured on the interface. In this scenario the IPv4 packets that ingress the CE from within the CE AS are over an IPv6-Only interface and are forwarded to an IPv4 NLRI destination prefix learned from the Pure Transport Single IPv6 BGP Peer. In the IPv6-Only Edge peering architecture the PE is IPv6-Only as all PE-CE interfaces are IPv6-Only. However, on the CE, the PE-CE interface is the only interface that is IPv6-Only and all other interfaces may or may not be IPv6-Only. Following the data plane packet flow, IPv4 packets are forwarded from the ingress CE to the IPv6-Only ingress PE where the VPN label imposition push per prefix, per-vrf, per-CE occurs and the labeled packet is forwarded over a 4to6 softwire IPv6-Only core, to the egress PE where the VPN label disposition pop occurs and the native IPv4 packet is forwarded to the egress CE. In the reverse direction IPv4 packets are forwarded from the egress CE to egress PE where the VPN label imposition per prefix, per-vrf, per-CE push occurs and the labeled packet is forwarded back over the 4to6 softwire IPv6-Only core, to the ingress PE where the VPN label disposition pop occurs and the native IPv4 packet is forwarded to the ingress CE. . The functionality of the IPv4 forwarding plane in this scenario is identical from a data plane forwarding perspective to Dual Stack IPv4 forwarding scenario.

+--------+ +--------+ | IPv4 | | IPv4 | | Client | | Client | | Network| | Network| +--------+ +--------+ | \ / | | \ / | | \ / | | X | | / \ | | / \ | | / \ | +--------+ +--------+ | AFBR | | AFBR | +--| IPv4/6 |---| IPv4/6 |--+ | +--------+ +--------+ | +--------+ | | +--------+ | IPv6 | | | | IPv6 | | Client | | | | Client | | Network|------| IPv6 |-------| Network| +--------+ | only | +--------+ | | | +--------+ +--------+ | +--| AFBR |---| AFBR |--+ | IPv4/6 | | IPv4/6 | +--------+ +--------+ | \ / | | \ / | | \ / | | X | | / \ | | / \ | | / \ | +--------+ +--------+ | IPv4 | | IPv4 | | Client | | Client | | Network| | Network| +--------+ +--------+

This section describes next hop encoding updates to applicability to this specification. IPv6-only eBGP Edge PE-CE peering to carry IPv4 Unicast NLRI <AFI/SAFI> IPv4 <1/1> over an IPv6 next hop BGP capability extended hop encoding IANA capability codepoint value 5 defined is applicable to both and as IPv4 Unicast NLRI <AFI/SAFI> IPv4 <1/1> does not change in the RFC updates. IPv4 packets over an IPv6-Only core 4to6 Softwire E2E packet flow is part of the IPv6-Only design vendor interoperaiblity test cases and in that respect is applicable as updates for <AFI/SAFI> VPN-IPV4 <1/128>, and Multicasat VPN <1/129>

This section describes the next hop encoding updates to In when AFI/SAFI 1/128 is used, the next-hop address is encoded as an IPv6 address with a length of 16 or 32 bytes. This document modifies how the next-hop address is encoded to accommodate all existing implementations and bring consistency with VPNv4oIPv4 and VPNv6oIPv6. The next-hop address is now encoded as a VPN-IPv6 address with a length of 24 or 48 bytes (see Sections 3 and 6.2 of this document). This change addresses Erratum ID 5253 (Err5253). As all known and deployed implementations are interoperable today and use the new proposed encoding, the change does not break existing interoperability. Updates to is applicable to the IPv6-Only PE-CE edge design for the IPv6 next hop encoding E2E test case of IPv4 packets over and IPv6-Only core 4to6 Softwire. In this test case IPv4 Unicast NLRI <AFI/SAFI> IPv4 <1/1> is advertised over the PE to RR core peering 4to6 softwire in <AFI/SAFI> VPN-IPV4 <1/128>. In this test case label allocation mode comes into play which is discussed in section 8.9. next hop encoding of MP_REACH_NLRI with: NLRI= NLRI as per current AFI/SAFI definition Advertising with [RFC4760] MP_REACH_NLRI with: AFI = 1 SAFI = 128 or 129 Length of Next Hop Address = 16 or 32 NLRI= NLRI as per current AFI/SAFI definition next hop encoding of MP_REACH_NLRI with: NLRI= NLRI as per current AFI/SAFI definition Advertising with [RFC4760] MP_REACH_NLRI with: AFI = 1 SAFI = 128 or 129 Length of Next Hop Address = 24 or 48 Next Hop Address = VPN-IPv6 address of next hop with an 8-octet RD set to zero (potentially followed by the link-local VPN-IPv6 address of the next hop with an 8-octet RD is set to zero). NLRI= NLRI as per current AFI/SAFI definition

Listed below are the following IPv6-Only PE Design ALL SAFI design scenario's: <AFI/SAFI> IPv4 Unicast <1/1>, IPv6 Unicast <2/1>, VPN-IPV4 <1/128>, VPN-IPV6 <2/128>, Multicasat VPN <1/129>, Multicasat VPN <2/129>,BGP-LU IPV4 (GRT) <1/4>

________ IPv6-Only _____ / \ IPv6-Only PE / CE / \__/ \___ PE / CE +----+ +----+ / \ +------+ +-----+ | | | | | |_ | | | | | | | | | \ | | | | | CE |--| PE |--\ IPv4-Only Core |----| PE |---| CE | | | | | \0=========Underlay =======0| | | | | +----+ +----+ \ __/ +------+ +-----+ IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer IPv4 forwarding \__ __ / IPv4 forwarding IPv6 forwarding \_______/ \_____/ IPv6 forwarding

________ IPv6-Only _____ / \ IPv6-Only PE / CE / \__/ \___ PE / CE +----+ +----+ / \ +------+ +-----+ | | | | | 0====VPN Overlay Tunnel ==0| | | | | | | | | | \ | | | | | CE |--| PE |--\ IPv4-Only Core |----| PE |---| CE | | | | | \0=========Underlay =======0| | | | | +----+ +----+ \ __/ +------+ +-----+ IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer IPv4 forwarding \__ __ / IPv4 forwarding IPv6 forwarding \_______/ \_____/ IPv6 forwarding

________ IPv6-Only _____ / \ IPv6-Only PE / CE / \__/ \___ PE / CE +----+ +----+ / \ +------+ +-----+ | | | | | |_ | | | | | | | | | \ | | | | | CE |--| PE |--\ IPv6-Only Core |----| PE |---| CE | | | | | \0=========Underlay =======0| | | | | +----+ +----+ \ __/ +------+ +-----+ IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer IPv4 forwarding \__ __ / IPv4 forwarding IPv6 forwarding \_______/ \_____/ IPv6 forwarding

________ IPv6-Only _____ / \ IPv6-Only PE / CE / \__/ \___ PE / CE +----+ +----+ / \ +------+ +-----+ | | | | | 0====VPN Overlay Tunnel ==0| | | | | | | | | | \ | | | | | CE |--| PE |--\ IPv6-Only Core |----| PE |---| CE | | | | | \0=========Underlay =======0| | | | | +----+ +----+ \ __/ +------+ +-----+ IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer IPv4 forwarding \__ __ / IPv4 forwarding IPv6 forwarding \_______/ \_____/ IPv6 forwarding

Inter-AS ASBR-ASBR link is IPv6-Only PE IPv6-Only __________ __________ IPv6-Only PE / CE / \ / \ PE / CE +--+ +----+ / \ / \ +--+ +--+ | | | | | AS 1 \ | AS 2 \ | | | | | | | | | \IPv6| \ | | | | |CE|-| PE |--| IPv4-Only Core|----|IPv4-Only Core|--|PE|-|CE| | | | | |0=Underlay==0 | |0==Underlay==0| | | | | +--+ +----+ \ / \ / +--+ +--+ IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer IPv4 forwarding \_________/ \_________/ IPv4 forwarding IPv6 forwarding IPv6 forwarding

Inter-AS ASBR-ASBR link is IPv6-Only PE IPv6-Only __________ __________ IPv6-Only PE / CE / \ / \ PE / CE +--+ +----+ / \ / \ +--+ +--+ | | | | | AS 1 \ | AS 2 \ | | | | | | | | | \IPv6| \ | | | | |CE|-| PE |--| IPv4-Only Core|----|IPv4-Only Core|--|PE|-|CE| | | | | |0=Overlay===0 | |0==Overlay===0| | | | | +--+ +----+ \ / \ / +--+ +--+ IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer IPv4 forwarding \_________/ \_________/ IPv4 forwarding IPv6 forwarding IPv6 forwarding

Inter-AS ASBR-ASBR link is IPv6-Only PE IPv6-Only __________ __________ IPv6-Only PE / CE / \ / \ PE / CE +--+ +----+ / \ / \ +--+ +--+ | | | | | AS 1 \ | AS 2 \ | | | | | | | | | \IPv6| \ | | | | |CE|-| PE |--| IPv6-Only Core|----|IPv6-Only Core|--|PE|-|CE| | | | | |0=Underlay==0 | |0==Underlay==0| | | | | +--+ +----+ \ / \ / +--+ +--+ IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer IPv4 forwarding \_________/ \_________/ IPv4 forwarding IPv6 forwarding IPv6 forwarding

Inter-AS ASBR-ASBR link is IPv6-Only PE IPv6-Only __________ __________ IPv6-Only PE / CE / \ / \ PE / CE +--+ +----+ / \ / \ +--+ +--+ | | | | | AS 1 \ | AS 2 \ | | | | | | | | | \IPv6| \ | | | | |CE|-| PE |--| IPv6-Only Core|--- |IPv6-Only Core|--|PE|-|CE| | | | | |0=Underlay==0 | |0==Underlay==0| | | | | +--+ +----+ \ / \ / +--+ +--+ IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer IPv4 forwarding \_________/ \_________/ IPv4 forwarding IPv6 forwarding IPv6 forwarding

Inter-AS ASBR-ASBR link is IPv6-Only PE IPv6-Only __________ __________ IPv6-Only PE / CE / \ / \ PE / CE +--+ +----+ / \ / \ +--+ +--+ | | | | | AS 1 \ | AS 2 \ | | | | | | | | | \IPv6| \ | | | | |CE|-| PE |--| IPv6-Only Core|--- |IPv6-Only Core|--|PE|-|CE| | | | | |0=Overlay===0 | |0==Overlay===0| | | | | +--+ +----+ \ / \ / +--+ +--+ IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer IPv4 forwarding \_________/ \_________/ IPv4 forwarding IPv6 forwarding IPv6 forwarding

With a single IPv6 Peer carrying both IPv4 and IPv6 NLRI there are some operational considerations in terms of what changes and what does not change. What does not change with a single IPv6 transport peer carrying IPv4 NLRI and IPv6 NLRI below: Routing Policy configuration is still separate for IPv4 and IPv6 configured by capability as previously. Layer 1, Layer 2 issues such as one-way fiber or fiber cut will impact both IPv4 and IPv6 as previously. If the interface is in the Admin Down state, the IPv6 peer would go down, and IPv4 NLRI and IPv6 NLRI would be withdrawn as previously. Changes resulting from a single IPv6 transport peer carrying IPv4 NLRI and IPv6 NLRI below: Physical interface is no longer dual stacked. Any change in IPv6 address or DAD state will impact both IPv4 and IPv6 NLRI exchange. Single BFD session for both IPv4 and IPv6 NLRI fate sharing as the session is now tied to the transport, which now is only IPv6 address family. Both IPv4 and IPv6 peer now exists under the IPv6 address family configuration. Fate sharing of IPv4 and IPv6 address family from a logical perspective now carried over a single physical IPv6 peer. From an operations perspective, prior to elimination of IPv4 peers, an audit is recommended to identify and IPv4 and IPv6 peering incongruencies that may exist and to rectify them. No operational impacts or issues are expected with this change. With MPLS VPN overlay, per-CE next-hop label allcoation mode where both IPv4 and IPv6 prefixes have the same label in no table lookup pop-n-forward mode should be taken into consideration.

There are not any IANA considerations.

The extensions defined in this document allow BGP to propagate reachability information about IPv4 prefixes over an MPLS or SR IPv6-Only core network. As such, no new security issues are raised beyond those that already exist in BGP-4 and the use of MP-BGP for IPv6. Both IPv4 and IPv6 peers exist under the IPv6 address family configuration. The security features of BGP and corresponding security policy defined in the ISP domain are applicable. For the inter-AS distribution of IPv6 routes according to case (a) of Section 4 of this document, no new security issues are raised beyond those that already exist in the use of eBGP for IPv6 .

Thanks to Kaliraj Vairavakkalai, Linda Dunbar, Aijun Wang, Eduardfor Vasilenko, Joel Harlpern, Michael McBride, Ketan Talaulikar for review comments.

The following people contributed substantive text to this document:

&RFC2119; &RFC2545; &RFC4291; &RFC4364; &RFC4760; &RFC5492; &RFC8174; &RFC8277; &RFC7267; &RFC9012; &RFC7117; &RFC9015; &RFC4761; &RFC6037; &RFC5747; &RFC5195; &RFC7432; &RFC7752; &RFC8955; &I-D.ietf-bess-ipv6-only-pe-design; &I-D.nalawade-kapoor-tunnel-safi; &I-D.ietf-l3vpn-bgpvpn-auto; &I-D.ietf-idr-bgp-car; &I-D.mpmz-bess-mup-safi; &I-D.ietf-bess-bgp-multicast; &I-D.ietf-idr-flowspec-nvo3; &I-D.ietf-idr-sdwan-edge-discovery; &I-D.ietf-idr-segment-routing-te-policy; &I-D.ietf-lsvr-bgp-spf; &I-D.ietf-idr-rpd; &I-D.ietf-idr-dynamic-cap; &RFC4659; &RFC4684; &RFC4798; &RFC4925; &RFC8126; &RFC5549; &RFC5565; &RFC6074; &RFC6513; &RFC6514; &RFC8950;

IPv6-Only PE Design listing of PE-CE Edge ALL applicable SAFI. Here we showing the catagorization grouping by columns of the SAFI into 2 use case categories. Unicst Multicast IPv4-Only PE DESIGN ALL SAFI's PE-CE Edge Scenario

SAFI Value	Description	Unicast	Multicast
1	Unicast	Yes	No
2	Multicast	No	Yes
78	MCAST-TREE SAFI	No	Yes

IPv4-Only PE design supports 25 / 32 IANA SAFI's of which the 7 not supported do not use AFI=1 IPv4 or AFI=2 IPv6.

IPv6-Only PE Design listing of Inter-AS PE-PE ALL applicable SAFI. Here we show the catagorization grouping by columns of the SAFI into 5 use case categories. Unicst Multicast L1-L2 VPN Tunnel BGP Policy IPv4-Only PE DESIGN ALL SAFI's Inter-AS PE-PE Scenario

SAFI Value	Description	Unicast	Multicast	L1-L2 VPN	Tunnel	BGP Policy	Reference
1	NLRI Unicast	Yes	No	No	No	No
2	NLRI Multicast	No	Yes	No	No	No
4	NLRI MPLS Laels	Yes	No	No	No	No
5	MCAST-VPN	No	Yes	No	No	No
6	Dynamic Multi Segment PW	No	No	Yes	No	No
8	MCAST-VPLS	No	Yes	No	No	No
9	BGP-SFC	No	No	No	No	No
64	Tunnel SAFI	No	No	No	Yes	No
65	VPLS	No	No	No	No	No
66	BGP MDT SAFI	NO	Yes	No	No	No
67	BGP 4to6 SAFI	No	No	No	Yes	No
68	BGP 6to4 SAFI	No	No	No	Yes	No
69	L1 VPN Auto Discovery	No	No	Yes	No	No
70	BGP EVPN	No	No	No	No	No
71	BGP-LS	No	No	No	No	No
72	BGP-LS-VPN	No	No	No	No	No
73	SR-TE Policy SAFI	No	No	No	No	Yes
74	SD-WAN Capabilities	No	No	No	No	Yes
75	Routing Policy SAFI	No	No	No	No	No
77	Tunneled Traffic Flowspec	No	No	No	Yes	No
78	MCAST-TREE SAFI	No	Yes	No	No	No
79	BGP-DPS	No	No	No	No	Yes	Arista Dynamic Path Selection
80	BGP-LS-SPF	No	No	No	No	No
83	BGP CAR	No	No	No	No	Yes
84	BGP CAR VPN	No	No	No	No	Yes
85	BGP MUP SAFI	No	No	No	No	Yes
128	MPLS VPN	Yes	No	No	No	No
129	MPLS Multicast VPN	No	Yes	No	No	No
132	Route Target Constrains	Yes	No	No	No	No
133	Dissemination of Flowspec Rules	No	No	No	No	Yes
134	L3VPN Dissemination of Flowspec Rules	No	No	No	No	Yes
140	VPN Auto Discovery	No	No	No	No	Yes

IPv6-Only PE design supports 25 / 32 IANA SAFI's of which the 7 not supported do not use AFI=1 IPv4 or AFI=2 IPv6.