| Internet-Draft | IPv4-Only PE IPv4 DESIGN ALL SAFI | July 2022 |
| Mishra, et al. | Expires 8 January 2023 | [Page] |
As Enterprises and Service Providers try to decide whether or not to 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) Edge network from IPv4 to IPv6. Operators must be able to continue to support IPv4 customers when both the Core and Edge networks are IPv4-Only.¶
[I-D.mishra-bess-ipv4-only-pe-design] details an important External BGP (eBGP) PE-CE Edge IPv4-Only peering design that leverages the MP-BGP capability exchange by using IPv4 peering as pure transport, allowing both 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. 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 design change from a control plane perspective a single IPv4 is required for both IPv4 and IPv6 routing updates and from a data plane forwarindg perspective an IPv4 address need only be configured on the PE and CE interface for both IPv4 and IPv6 packet forwarding.¶
[I-D.mishra-bess-ipv4-only-pe-design] provides a IPv4-Only PE design solution for use cases where operators are not yet ready to migrate to IPv6 or SRv6 core and would like to stay on IPv4-Only Core short to long term and maybe even indefinitely. With this design, operators can now remain with an IPv4-Only Core and do not have to migrate to an IPv6-Only Core. From a technical standpoint the underlay can remain IPv4 and still transport IPv6 NLRI to support IPv6 customers, and so does not need to be migrated to IPv6-Only underlay. With this IPv4-Only PE Design solution , IPv4 addressing only needs to be provisioned for the IPv4-Only PE-CE eBGP Edge peering design, thereby eliminating IPv6 provisioning at the Edge. This core and edge IPv4-Only peering design can apply to any eBGP peering, public internet or private, which can be either Core networks, Data Center networks, Access networks or can be any eBGP peering scenario.¶
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 IPv4-Only PE Design, IPv6 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 IPv4-Only peer is required for both IPv4 and IPv6 routing updates and from a data plane forwarindg perspective an IPv4 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 IPv4-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 [I-D.mishra-bess-ipv4-only-pe-design] 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 IPv4-Only peering architecure extension to Inter-AS peering is very relevant to Segment Routing as well.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 8 January 2023.¶
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 (https://trustee.ietf.org/license-info) 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.¶
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 IPv6 customers and must be able to support IPv6 address family and Sub-Address-Family Virtual Private Network (VPN)-IPv6, and Multicast VPN IPv6 customers.¶
With this IPv4-only BGP peering design, only IPv4 is configured on the PE-CE interface, the Provider Edge (PE) - Customer Edge (CE), the IPv4 BGP peer is now used to carry IPv6 (Network Layer Reachability Information) NLRI over an IPv4 next hop using 4 byte IPv4 next hop encoding while continuing to forward both IPv4 and IPv6 packets. In the framework of this design the PE is no longer Dual Stacked. However in the case of the CE, PE-CE link CE side of the link is no longer Dual Stacked, however all other internal links within the CE domain may or maynot be Dual stacked.¶
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. [RFC8950] 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. [RFC8950] 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.¶
With the IPv4-Only PE design, IPv6 NLRI will be carried over an IPv4 Next-hop. [RFC4798] and [RFC4659] specify how an IPv4 address can be encoded inside the next-hop IPv6 address field when IPv6 NLRI needs to be advertised with an IPv4 next hop. [RFC4798] defines how the IPv4-mapped IPv6 address format specified in the IPv6 addressing architecture [RFC4798] can be used for that purpose when the <AFI/SAFI> is IPv6-Unicast <2/1>, Multicast <2/2>, and Labeled Unicast <2/4>. [RFC4659] defines how the IPv4-mapped IPv6 address format as well as a null Route Distinguisher as ::FFFF:192.168.1.1 (RD) can be used for that purpose when the <AFI/SAFI> is VPN-IPv6 <2/128> MVPN-IPv6 <2/129>. This IPv4-Only PE specification utilizes IPv6 NLRI over IPv4 Next hop encoding adopted by the industy to not use IPv4 mapped IPv6 address defined above, and instead use 4 byte IPv4 address for the next hop which ultimately set the precedence for the adoption of [RFC8950] for 4to6 Softwire IPv4 NLRI over IPv6 next-hop using an IPv6 address for the next hop and not a IPv6 mapped IPv4 address. The IPv4 next hop encoding for cases where the NLRI advertised is different from the next hop encoding such as where IPv6 NLRI is advertied with IPv4 next hop for for <AFI/SAFI> is IPv6-Unicast <2/1>, Multicast <2/2>, and Labeled Unicast <2/4>. [RFC4659] defines Null(RD) for <AFI/SAFI> is VPN-IPv6 <2/128> MVPN-IPv6 <2/129> but now with a an official new IANA Capability code TBD as value 10 "IPv4 Next Hop Encoding". The IETF standards have not been updated with an IANA allocation Capability code for the IPv4 next hop encoding so this specification fixes that problem with an IANA allocated capability codepoint which will now be used for any eBGP or iBGP peering as well as the IPv4-Only PE design defined in this specification.¶
With this IPv4-Only PE Design, 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 IPv4 TCP session. This allows for the elimination of dual stack from the PE-CE peering point, and now enable the peering to be IPv4-ONLY. The elimination of IPv6 on the PE-CE peering points translates into OPEX expenditure savings of point-to-point infrastructure links as well as /127 address space savings and administration and network management of both IPv4 and IPv6 BGP peers. This reduction decreases the number of PE-CE BGP peers by fifty percent, which is a tremendous cost savings for operators. This also translates into Major CAPEX savings as now operators do not have to migrate their underlay to IPv6 and can remain indefinitely on IPv4-Only Core.¶
This document defines the IPv4-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, IPv6 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 IPv4-Only peer MUST be configured for both IPv4 and IPv6 routing updates, and from a data plane forwarindg perspective only an IPv4 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 IPv4-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, [I-D.mishra-bess-ipv4-only-pe-design] 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 IPv4-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 IPv4-Only PE ALL SAFI Design details an important External BGP (eBGP) PE-PE Inter-AS IPv4-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 IPv4-Only Inter-AS peerings: <AFI/SAFI> MCAST-VPN [RFC6514] <1/5>, NLRI Multi-Segment Pseudowires [RFC7267] <1/6>, BGP Tunnel Encapsulation SAFI [RFC9012] <1/7>, MCAST-VPLS [RFC7117] <1/8>, BGP SFC [RFC9015] <1/9>, Tunnel SAFI [I-D.nalawade-kapoor-tunnel-safi] <1/6>, Virtual Private LAN Service (VPLS) [RFC4761] and [RFC6074] <1/5>, BGP MDT SAFI [RFC6037] <1/66>, BGP 4to6 SAFI [RFC5747] <1/67>, BGP 6to4 SAFI draft xx <1/8>, Layer 1 VPN Auto-Discovery [RFC5195] <1/69>, BGP EVPNs [RFC7432] <1/70>, BGP-LS (VPLS) [RFC7752] <1/71>, BGP-LS-EVPN [RFC7752] <72/>, SR-TE Policy SAFI draftxx <1/73>, BGP 6to4 SAFI draft xx <1/8>, SDN WAN Capabilities draftxx <1/74>, Routing Policy SAFI draftxx <1/75>, Classful-Transport SAFI draftxx <1/76>, Tunneled Traffic FlowSpec draftxx <1/77>, MCAST-TREE SAFI draft xx <1/78>, Route Target Constraints [RFC4684] <1/132>, Dissemination of Flow Specification Rules [RFC8955] <1/133>, L3 VPN Dissemination of Flow Specification Rules [RFC8955] <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 [RFC2119] [RFC8174] 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¶
The IPv4-Only Edge design solution applies to any and all IPv4 Network Layer Reachability Information (NLRI) and IPv6 Network Layer Reachability Information (NLRI) over an IPv4-Only BGP Peering session.¶
IPv4-Only PE Design ALL SAFI can be broken up into the following design scenario's below:¶
Edge Customer NLRI IPv4 or IPV6 related AFI/SAFI (PE-CE): 1/1 2/1 (Unicast), 1/2 2/2 (Multicast)¶
Inter-AS Customer NLRI IPv4 or IPV6 related AFI/SAFI (ASBR-ASBR): 1/1 2/1 (Unicast), 1/2 2/2 (Multicast), 1/128 2/128 (VPN), 1/129 2/129 (MVPN), 1/4 2/4 BGP-LU (6PE/4PE), 1/140 2/140 (BGP VPN Auto Discovery)¶
Inter-AS Multicast NLRI IPv4 or IPV6 related AFI/SAFI (ASBR-ASBR): 1/5 2/5 (MCAST-VPN) , 1/8 2/8 (MCAST-VPLS), 1/66 2/66 (BGP MDT-SAFI), 1/78 2/78 (MCAST-TREE)¶
PE to Controller NLRI IPv4 or IPV6 related AFI/SAFI 1/71 2/71 (BGP-LS), 1/72 2/72 (BGP-LS VPN), 1/75 2/75 (Routing Policy SAFI), 1/80 2/80 BGP-LS-SPF¶
Inter-AS L1 VPN, L2 VPN NLRI IPv4 or IPV6 related AFI/SAFI (ASBR-ASBR) 1/65 2/65 (VPLS), 1/70 2/70 (BGP EVPN), 1/69 2/69 (L1 VPN)¶
Inter-AS BGP FlowSpec, Optimizations and SFC NLRI IPv4 or IPV6 related AFI/SAFI (ASBR-ASBR) 1/132 2/132 (RTC), 1/133 2/133 (BGP FlowSpec), 1/134 2/134 (VPN BGP FlowSpec), 1/9 2/9 (BGP SFC)¶
Inter-AS BGP Policy - SR-TE Policy, SD-WAN Policy NLRI IPv4 or IPV6 related AFI/SAFI (ASBR-ASBR) 1/73 2/73 (SR-TE), 1/74 2/74 (SD-WAN Capabilities)¶
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 IPv4-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 IPv4-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 IPv4-Only P (Provider) core network or IPv6-Only P (Provider) core network. With this IPv4-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 IPv4-Edge eBGP IPv4 peering where IPv6 packets at network Edge traverse a IPv4-Only Core¶
In the scenario where IPv6 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 IPv6 packets that ingress the CE from within the CE AS are over an IPv4-Only interface and are forwarded to an IPv6 NLRI destination prefix learned from the Pure Transport Single IPv4 BGP Peer. In the IPv4-Only Edge peering architecture the PE is IPv4-Only as all PE-CE interfaces are IPv4-Only. However, on the CE, the PE-CE interface is the only interface that is IPv4-Only and all other interfaces may or may not be IPv4-Only. Following the data plane packet flow, IPv4 packets are forwarded from the ingress CE to the IPv4-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 IPv4-Edge eBGP IPv4 peering where IPv6 packets at network Edge traverse a IPv6-Only Core¶
In the scenario where IPv6 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 IPv4 address configured on the interface. In this scenario the IPv6 packets that ingress the CE from within the CE AS are over an IPv4-Only interface and are forwarded to an IPv6 NLRI destination prefix learned from the Pure Transport Single IPv4 BGP Peer. In the IPv4-Only Edge peering architecture the PE is IPv4-Only as all PE-CE interfaces are IPv4-Only. However, on the CE, the PE-CE interface is the only interface that is IPv4-Only and all other interfaces may or may not be IPv4-Only. Following the data plane packet flow, IPv6 packets are forwarded from the ingress CE to the IPv4-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 IPv6 packet is forwarded to the egress CE. In the reverse direction IPv6 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 IPv6 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 / IPv6 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 [RFC8950] next hop encoding updates to [RFC5549] applicability to this specification. IPv4-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 [RFC5549] and [RFC8950] 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 PE design and this same style next hop encoding applies to 6to4 Softwire IPv6 NLRI over IPv4 next hop with 4 byte Next hop encoding and not IPv4 mapped IPv6 address. [RFC8950] updates [RFC5549] for <AFI/SAFI> VPN-IPV4 <1/128>, and Multicasat VPN <1/129>¶
This section describes IPv4 Next Hop Encoding for IPv6 NLRI over an IPv4 Next hop.¶
With the IPv4-Only PE design, IPv6 NLRI will be carried over an IPv4 Next-hop. [RFC4798] and [RFC4659] specify how an IPv4 address can be encoded inside the next-hop IPv6 address field when IPv6 NLRI needs to be advertised with an IPv4 next hop. [RFC4798] defines how the IPv4-mapped IPv6 address format specified in the IPv6 addressing architecture [RFC4798] can be used for that purpose when the <AFI/SAFI> is IPv6-Unicast <2/1>, Multicast <2/2>, and Labeled Unicast <2/4>. [RFC4659] defines how the IPv4-mapped IPv6 address format as well as a null Route Distinguisher as ::FFFF:192.168.1.1 (RD) can be used for that purpose when the <AFI/SAFI> is VPN-IPv6 <2/128> MVPN-IPv6 <2/129>. This IPv4-Only PE specification utilizes IPv6 NLRI over IPv4 Next hop encoding adopted by the industy to not use IPv4 mapped IPv6 address defined above, and instead use 4 byte IPv4 address for the next hop which ultimately set the precedence for the adoption of [RFC8950] for 4to6 Softwire IPv4 NLRI over IPv6 next-hop. The IPv4 next hop encoding for cases where the NLRI advertised is different from the next hop encoding such as where IPv6 NLRI is advertied with IPv4 next hop for for <AFI/SAFI> is IPv6-Unicast <2/1>, Multicast <2/2>, and Labeled Unicast <2/4>. [RFC4659] defines Null(RD) for <AFI/SAFI> is VPN-IPv6 <2/128> MVPN-IPv6 <2/129> but now with a an official new IANA Capability code TBD as value 10 "IPv4 Next Hop Encoding". The IETF standards have not been updated with an IANA allocation Capability code for the IPv4 next hop encoding so this specification fixes that with an IANA allocated codepoint which will now be used for any eBGP or iBGP peering as well as the IPv4-Only PE design defined in this specification.¶
With this specification when VPN-IPv6 AFI/SAFI 2/128, MVPN-IPv6 AFI/SAFI 2/129 is used, the next-hop address is encoded as an IPv4 address with a length of 12 bytes. The next-hop address is now encoded for VPN-IPv6 AFI/SAFI with a length of 12 bytes. The 12 byte next hop includes 4 byte IPv4 address plus 8 byte Route Distinguisher. This document modifies how the next-hop address is encoded to accommodate all existing implementations and bring consistency with VPN-IPv6, MVPN-IPv6 and 6PE. As all known and deployed implementations are interoperable today and use the new proposed encoding, the change does not break existing interoperability. This change is applicable to all iBGP and eBGP peering as well as the IPv4-Only PE, PE-CE edge and Inter-AS peering design for the IPv4 next hop encoding E2E test case of IPv4 packets over and IPv4-Only core 6to4 Softwire. In this test case IPv6 Unicast NLRI <AFI/SAFI> IPv4 <1/1> is advertised over the PE to RR core peering 6to4 softwire in <AFI/SAFI> VPN-IPV6 <2/128> MVPN-IPv6 <2/129>. In this test cases label allocation mode comes into play which is discussed in a subsequent section.¶
This document defines with the new IANA BGP Capability codepoint allocation next hop encoding of MP_REACH_NLRI with:¶
Listed below are the following IPv4-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>¶
________
IPv4-Only _____ / \ IPv4-Only
PE / CE / \__/ \___ PE / CE
+----+ +----+ / \ +------+ +-----+
| | | | | |_ | | | |
| | | | | \ | | | |
| CE |--| PE |--\ IPv4-Only Core |----| PE |---| CE |
| | | | \0=========Underlay =======0| | | | |
+----+ +----+ \ __/ +------+ +-----+
IPv4 BGP peer \ MPLS / SR domain / IPv4 BGP peer
IPv4 forwarding \__ __ / IPv4 forwarding
IPv6 forwarding \_______/ \_____/ IPv6 forwarding
________
IPv4-Only _____ / \ IPv4-Only
PE / CE / \__/ \___ PE / CE
+----+ +----+ / \ +------+ +-----+
| | | | | 0====VPN Overlay Tunnel ==0| | | | |
| | | | | \ | | | |
| CE |--| PE |--\ IPv4-Only Core |----| PE |---| CE |
| | | | \0=========Underlay =======0| | | | |
+----+ +----+ \ __/ +------+ +-----+
IPv4 BGP peer \ MPLS / SR domain / IPv4 BGP peer
IPv4 forwarding \__ __ / IPv4 forwarding
IPv6 forwarding \_______/ \_____/ IPv6 forwarding
Huawei: Edge and Core-VRPv8, Release VRP-V800R020C10¶
________
IPv4-Only _____ / \ IPv4-Only
PE / CE / \__/ \___ PE / CE
+----+ +----+ / \ +------+ +-----+
| | | | | |_ | | | |
| | | | | \ | | | |
| CE |--| PE |--\ IPv4-Only Core |----| PE |---| CE |
| | | | \0=========Underlay =======0| | | | |
+----+ +----+ \ __/ +------+ +-----+
IPv4 BGP peer \ MPLS / SR domain / IPv4 BGP peer
IPv4 forwarding \__ __ / IPv4 forwarding
IPv6 forwarding \_______/ \_____/ IPv6 forwarding
________
IPv4-Only _____ / \ IPv4-Only
PE / CE / \__/ \___ PE / CE
+----+ +----+ / \ +------+ +-----+
| | | | | 0====VPN Overlay Tunnel ==0| | | | |
| | | | | \ | | | |
| CE |--| PE |--\ IPv4-Only Core |----| PE |---| CE |
| | | | \0=========Underlay =======0| | | | |
+----+ +----+ \ __/ +------+ +-----+
IPv4 BGP peer \ MPLS / SR domain / IPv4 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=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 |--| 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
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 [RFC2545].¶
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:¶
Mohana Sundari
EMail: mohanas@juniper.net
¶