idnits 2.17.1 draft-mishra-bess-ipv4nlri-all-safi-ipv6nh-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 12 characters in excess of 72. ** The abstract seems to contain references ([I-D.ietf-bess-ipv6-only-pe-design]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (11 January 2022) is 828 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4291' is defined on line 841, but no explicit reference was found in the text == Unused Reference: 'RFC4364' is defined on line 845, but no explicit reference was found in the text == Unused Reference: 'RFC5492' is defined on line 864, but no explicit reference was found in the text == Unused Reference: 'RFC8277' is defined on line 903, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-dynamic-cap' is defined on line 925, but no explicit reference was found in the text == Unused Reference: 'RFC4659' is defined on line 931, but no explicit reference was found in the text == Unused Reference: 'RFC4798' is defined on line 943, but no explicit reference was found in the text == Unused Reference: 'RFC4925' is defined on line 949, but no explicit reference was found in the text == Unused Reference: 'RFC6513' is defined on line 969, but no explicit reference was found in the text == Unused Reference: 'RFC8126' is defined on line 978, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-bess-ipv6-only-pe-design-00 -- Possible downref: Normative reference to a draft: ref. 'I-D.nalawade-kapoor-tunnel-safi' ** Downref: Normative reference to an Experimental RFC: RFC 5747 ** Downref: Normative reference to an Historic RFC: RFC 6037 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) -- Obsolete informational reference (is this intentional?): RFC 5549 (Obsoleted by RFC 8950) Summary: 5 errors (**), 0 flaws (~~), 13 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group G. Mishra 3 Internet-Draft Verizon Inc. 4 Intended status: Best Current Practice 11 January 2022 5 Expires: 15 July 2022 7 IPv6-Only PE Design for IPv4-NLRI All SAFI over IPv6-NH 8 draft-mishra-bess-ipv4nlri-all-safi-ipv6nh-00 10 Abstract 12 As Enterprises and Service Providers upgrade their brown field or 13 green field MPLS/SR core to an IPv6 transport, Multiprotocol BGP (MP- 14 BGP)now plays an important role in the transition of their Provider 15 (P) core network as well as Provider Edge (PE) Inter-AS peering 16 network from IPv4 to IPv6. Operators must be able to continue to 17 support IPv4 customers when both the Core and Edge networks are 18 IPv6-Only. 20 This document details an important External BGP (eBGP) PE-PE Inter-AS 21 IPv6-Only peering design that leverages the MP-BGP capability 22 exchange by using IPv6 peering as pure transport, allowing both IPv4 23 Network Layer Reachability Information (NLRI) and IPv6 Network Layer 24 Reachability Information (NLRI)to be carried over the same (Border 25 Gateway Protocol) BGP TCP session for all Address Family Identifiers 26 (AFI) and Subsequent Address Family Identifiers(SAFI). The design 27 change provides the same Dual Stacking functionality that exists 28 today with separate IPv4 and IPv6 BGP sessions as we have today. 29 With this design change from a control plane perspective a single 30 IPv6-Only peer is required for both IPv4 and IPv6 routing updates and 31 from a data plane forwarindg perspective an IPv6 address need only be 32 configured on the PE to PE Inter-AS peering interface for both IPv4 33 and IPv6 packet forwarding. This document extends the IPv6-Only PE- 34 CE peering architecture defined in 35 [I-D.ietf-bess-ipv6-only-pe-design] to PE-PE inter-as peering 36 architecture where the 4to6 softwire is now extended to Inter-AS L3 37 VPN options Option-A, Option-AB and Option-C and now applies to all 38 AFI/SAFI ubiquitously. As service providers migrate to Segment 39 Routing architecture SR-MPLS and SRv6, VPN overlay exsits as well, 40 and thus Inter-AS options Option-A, Option-AB and Option-C are still 41 applicable and thus this extension of IPv6-Only peering architecure 42 extension to Inter-AS peering is very relevant to Segment Routing as 43 well. 45 Status of This Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at https://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on 15 July 2022. 62 Copyright Notice 64 Copyright (c) 2022 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 69 license-info) in effect on the date of publication of this document. 70 Please review these documents carefully, as they describe your rights 71 and restrictions with respect to this document. Code Components 72 extracted from this document must include Revised BSD License text as 73 described in Section 4.e of the Trust Legal Provisions and are 74 provided without warranty as described in the Revised BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 79 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 80 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 81 4. IPv6-Only Edge Peering Architecture . . . . . . . . . . . . . 6 82 4.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 6 83 4.2. IPv6-Only PE-CE Design Solution . . . . . . . . . . . . . 7 84 4.3. IPv6-Only Edge Peering Design . . . . . . . . . . . . . . 8 85 4.3.1. IPv6-Only Edge Peering Packet Walk . . . . . . . . . 8 86 4.3.2. 6to4 Softwire IPv4-Only Core packet walk . . . . . . 9 87 4.3.3. 4to6 Softwire IPv6-Only Core packet walk . . . . . . 10 88 4.4. RFC5549 and RFC8950 Applicability . . . . . . . . . . . . 12 89 4.4.1. IPv6-Only Edge Peering design next-hop encoding . . . 13 90 4.4.2. RFC8950 updates to RFC5549 applicability . . . . . . 13 91 5. IPv6-Only PE Design Edge E2E Design for all AFI/SAFI . . . . 14 92 5.1. Design Solution-1 E2E IPv6-Only PE-CE, Global Table over 93 IPv4-Only Core(6PE), 6to4 softwire . . . . . . . . . . . 14 94 5.2. Design Solution-2 E2E IPv6-Only PE-CE, VPN over IPv4-Only 95 Core, 6to4 Softwire . . . . . . . . . . . . . . . . . . . 15 96 5.3. Design Solution-3 E2E IPv6-Only PE-CE, Global Table over 97 IPv6-Only Core (4PE), 4to6 Softwire . . . . . . . . . . . 15 99 5.4. Design Solution-4 E2E IPv6-Only PE-CE, VPN over IPv6-Only 100 Core, 4to6 Softwire . . . . . . . . . . . . . . . . . . . 16 101 5.5. Design Solution-5 E2E Inter-AS Option B and AB, 4to6 102 Softwire . . . . . . . . . . . . . . . . . . . . . . . . 16 103 5.6. IPv6-Only PE-CE Operational Considerations Testing . . . 17 104 6. IPv6-Only PE ALL AFI/SFI Operational Considerations . . . . . 17 105 7. Vendor Implementations and Operator Deployments . . . . . . . 18 106 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 107 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 108 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 109 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 110 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 111 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 112 12.2. Informative References . . . . . . . . . . . . . . . . . 21 113 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 115 1. Introduction 117 As Enterprises and Service Providers upgrade their brown field or 118 green field MPLS/SR core to an IPv6 transport such as MPLS LDPv6, SR- 119 MPLSv6 or SRv6, Multiprotocol BGP (MP-BGP) now plays an important 120 role in the transition of the Provider (P) core networks and Provider 121 Edge (PE) edge networks from IPv4 to IPv6. Operators have a 122 requirement to support IPv4 customers and must be able to support 123 IPv4 address family and Sub-Address-Family Virtual Private Network 124 (VPN)-IPv4, and Multicast VPN IPv4 customers. 126 IXP are also facing IPv4 address depletion at their peering points, 127 which are large Layer 2 transit backbones that service providers peer 128 and exchange IPv4 and IPv6 Network Layer Reachability Information 129 (NLRI). Today, these transit exchange points are Dual Stacked. With 130 this IPv6-only BGP peering design, only IPv6 is configured on the PE- 131 PE inter-as peering interface, the Inter-AS Provider Edge (PE) - 132 Provider Edge (PE), the IPv6 BGP peer is now used to carry IPv4 133 (Network Layer Reachability Information) NLRI over an IPv6 next hop 134 using IPv6 next hop encoding defined in [RFC8950], while continuing 135 to forward both IPv4 and IPv6 packets. In the framework of this 136 design the ASBRs providing Inter-AS options peering PE to PE 137 extending L3 VPN services is now no longer Dual Stacked. 139 MP-BGP specifies that the set of usable next-hop address families is 140 determined by the Address Family Identifier (AFI) and the Subsequent 141 Address Family Identifier (SAFI). Historically the AFI/SAFI 142 definitions for the IPv4 address family only have provisions for 143 advertising a Next Hop address that belongs to the IPv4 protocol when 144 advertising IPv4 or VPN-IPv4. [RFC8950] specifies the extensions 145 necessary to allow advertising IPv4 NLRI, Virtual Private Network 146 Unicast (VPN-IPv4) NLRI, Multicast Virtual Private Network (MVPN- 147 IPv4) NLRI with a Next Hop address that belongs to the IPv6 protocol. 148 This comprises of an extended next hop encoding MP-REACH BGP 149 capability exchange to allow the address of the Next Hop for IPv4 150 NLRI, VPN-IPv4 NLRI and MVPN-IPv4 NLRI to also belong to the IPv6 151 Protocol. [RFC8950] defines the encoding of the Next Hop to 152 determine which of the protocols the address actually belongs to, and 153 a new BGP Capability allowing MP-BGP Peers to discover dynamically 154 whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 155 Next Hop. 157 The current specification for carrying IPv4 NLRI of a given address 158 family via a Next Hop of a different address family is now defined in 159 [RFC8950], and specifies the extended next hop encoding MP-REACH 160 capability extension necessary to do so. This comprises an extension 161 of the AFI/SAFI definitions to allow the address of the Next Hop for 162 IPv4 NLRI or VPN-IPv4 NLRI to belong to either the IPv4 or the IPv6 163 protocol, the encoding of the Next Hop information to determine which 164 of the protocols the address belongs to, and a new BGP Capability 165 allowing MP-BGP peers to dynamically discover whether they can 166 exchange IPv4 NLRI and VPN- IPv4 NLRI with an IPv6 Next Hop. 168 With the new extensions defined in [RFC8950] supporting NLRI and next 169 hop address family mismatch, the BGP peer session can now be treated 170 as a pure TCP transport and carry both IPv4 and IPv6 NLRI at the 171 Provider Edge (PE) - Customer Edge (CE) over a single IPv6 TCP 172 session. This allows for the elimination of dual stack from the PE- 173 PE Inter-AS peering point, and now enable the Inter-AS peering to be 174 IPv6-ONLY. The elimination of IPv4 Inter Provider ASBR tie point, 175 PE-PE Inter-AS peering points translates into OPEX expenditure 176 savings of point-to-point infrastructure links as well as /31 address 177 space savings and administration and network management of both IPv4 178 and IPv6 BGP peers. This reduction decreases the number of PE-PE 179 Inter-AS options BGP peers by fifty percent, which is a tremendous 180 cost savings for operators. 182 While the savings exists at the Edge eBGP PE-PE Inter-AS peering, on 183 the core side PE to Route Reflector (RR) peering carrying 184 IPv4 <1/1>, VPN-IPV4 <1/128>, and Multicasat VPN <1/129>, there is no 185 savings as the Provider (P) Core is IPv6 Only and thus can only have 186 an IPv6 peer and must use [RFC8950] extended next hop encoding to 187 carrying IPv4 NLRI IPV4 <2/1>, VPN-IPV4 <2/128>, and Multicast VPN 188 <2/129> over an IPv6 next hop. 190 This document details an important External BGP (eBGP) PE-PE Inter-AS 191 IPv6-Only peering design that leverages the MP-BGP capability 192 exchange by using IPv6 peering as pure transport, allowing both IPv4 193 Network Layer Reachability Information (NLRI) and IPv6 Network Layer 194 Reachability Information (NLRI)to be carried over the same (Border 195 Gateway Protocol) BGP TCP session for all Address Family Identifiers 196 (AFI) and Subsequent Address Family Identifiers(SAFI). The design 197 change provides the same Dual Stacking functionality that exists 198 today with separate IPv4 and IPv6 BGP sessions as we have today. 199 With this design change from a control plane perspective a single 200 IPv6-Only peer is required for both IPv4 and IPv6 routing updates and 201 from a data plane forwarindg perspective an IPv6 address need only be 202 configured on the PE to PE Inter-AS peering interface for both IPv4 203 and IPv6 packet forwarding. This document extends the IPv6-Only PE- 204 CE peering architecture defined in 205 [I-D.ietf-bess-ipv6-only-pe-design] to PE-PE inter-as peering 206 architecture where the 4to6 softwire is now extended to Inter-AS L3 207 VPN options Option-A, Option-AB and Option-C and now applies to all 208 AFI/SAFI ubiquitously. As service providers migrate to Segment 209 Routing architecture SR-MPLS and SRv6, VPN overlay exsits as well, 210 and thus Inter-AS options Option-A, Option-AB and Option-C are still 211 applicable and thus this extension of IPv6-Only peering architecure 212 extension to Inter-AS peering is relevant to Segment Routing. 214 This document details an important External BGP (eBGP) PE-PE Inter-AS 215 IPv6-Only peering design that leverages the MP-BGP capability 216 exchange by using IPv6 peering as pure transport, allowing both IPv4 217 Network Layer Reachability Information (NLRI) and IPv6 Network Layer 218 Reachability Information (NLRI)to be carried over the same (Border 219 Gateway Protocol) BGP TCP session for the following Address Family 220 Identifiers (AFI) and Subsequent Address Family Identifiers(SAFI) to 221 be carried over IPv6-Only Inter-AS peerings described in detail in 222 this document: IPv4 Unicast <1/1>, IPv4 Multicast 223 <1/2>,VPN-IPV4 <1/128>, Multicasat VPN <1/129>, BGP-LU IPV4 (4PE) 224 <1/4>, BGP-LU IPV4 <1/4> 226 This document details an important External BGP (eBGP) PE-PE Inter-AS 227 IPv6-Only peering design that leverages the MP-BGP capability 228 exchange by using IPv6 peering as pure transport, allowing both IPv4 229 Network Layer Reachability Information (NLRI) and IPv6 Network Layer 230 Reachability Information (NLRI)to be carried over the same (Border 231 Gateway Protocol) BGP TCP session for all remaining Address Family 232 Identifiers (AFI) and Subsequent Address Family Identifiers(SAFI) 233 below as well that can be carried over IPv6-Only Inter-AS peerings: 234 MCAST-VPN [RFC6514] <1/5>, NLRI Multi-Segment Pseudowires 235 [RFC7267] <1/6>, BGP Tunnel Encapsulation SAFI [RFC9012] <1/7>, 236 MCAST-VPLS [RFC7117] <1/8>, BGP SFC [RFC9015] <1/9>, Tunnel SAFI 237 [I-D.nalawade-kapoor-tunnel-safi] <1/6>, Virtual Private LAN Service 238 (VPLS) [RFC4761] and [RFC6074] <1/5>, BGP MDT SAFI [RFC6037] <1/66>, 239 BGP 4to6 SAFI [RFC5747] <1/67>, BGP 6to4 SAFI draft xx <1/8>, Layer 1 240 VPN Auto-Discovery [RFC5195] <1/69>, BGP EVPNs [RFC7432] <1/70>, BGP- 241 LS (VPLS) [RFC7752] <1/71>, BGP-LS-EVPN [RFC7752] <72/>, SR-TE Policy 242 SAFI draftxx <1/73>, BGP 6to4 SAFI draft xx <1/8>, SDN WAN 243 Capabilities draftxx <1/74>, Routing Policy SAFI draftxx <1/75>, 244 Classful-Transport SAFI draftxx <1/76>, Tunneled Traffic FlowSpec 245 draftxx <1/77>, MCAST-TREE SAFI draft xx <1/78>, Route Target 246 Constraints [RFC4684] <1/132>, Dissemination of Flow Specification 247 Rules [RFC8955] <1/133>, L3 VPN Dissemination of Flow Specification 248 Rules [RFC8955] <1/1344>, VPN Auto-Discovery SAFI draftxx <1/140> 250 2. Requirements Language 252 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 253 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 254 "OPTIONAL" in this document are to be interpreted as described in BCP 255 14 [RFC2119] [RFC8174] when, and only when, they appear in all 256 capitals, as shown here. 258 3. Terminology 260 Terminolgoy used in defining the IPv6-Only Edge specification. 262 AFBR: Address Family Border Router Provider Edge (PE). 264 Edge: PE-CE Edge Network Provider Edge - Customer Edge 266 Core: P Core Network Provider (P) 268 4to6 Softwire : IPv4 edge over an IPv6-Only core 270 6to4 Softwire: IPv6 edge over an IPv4-Only core 272 E2E: End to End 274 4. IPv6-Only Edge Peering Architecture 276 4.1. Problem Statement 278 This specification addresses a real issue that has been discussed at 279 many operator groups around the world related to IXP major peering 280 points where hundreds of AS's have both IPv4 and IPv6 dual stacked 281 peering. IPv4 address depletion have been a major issue issue for 282 many years now. Operators around the world are clamoring for a 283 solution that can help solve issues related to IPv4 address depletion 284 at these large IXP peering points. With this solution IXPs as well 285 as all infrastructure networks such as Core networks, DC networks, 286 Access networks as well as any PE-CE public or private network can 287 now utilize this IPv6-Only Edge solution and reap the benefits 288 immediately on IPv4 address space saving. 290 IXP Problem Statement 292 Dual Stacked Dual Stacked 293 CE PE 295 +-------+ IPv4 BGP Peer +-------+ 296 | |---------------| | 297 | CE | IPv6 BGP Peer | PE | 298 | |---------------| | 299 +-------+ +-------+ 300 IPv4 forwarding IPv4 forwarding 301 IPv6 forwarding IPv6 forwarding 303 Figure 1: Problem Statement - IXP Dual Stack Peering 305 ________ 306 Dual Stacked _____ / \ Dual Stacked 307 PE / CE / \__/ \___ PE / CE 308 +----+ +----+ / \ +------+ +-----+ 309 | | | | |0====VPN Overlay Tunnel ==0| | | | | 310 | | | | | \ | | | | 311 | CE |--| PE |--\ IPv6-Only Core |----| PE |---| CE | 312 | | | | \0=========Underlay =======0| | | | | 313 +----+ +----+ \ __/ +------+ +-----+ 314 IPv4 IPv6 BGP peer \ IP / MPLS / SR domain / IPv4 and IPv6 BGP peer 315 IPv4 forwarding \__ __ / IPv4 forwarding 316 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 318 Figure 2: Problem Statement - E2E Dual Stack Edge 320 4.2. IPv6-Only PE-CE Design Solution 322 The IPv6-Only Edge design solution provides a means of E2E single 323 protocol design solution extension of [RFC5565] Softwire Mesh 324 framework from the PE-CE Edge to the Core from ingres so egress 325 through the entire operators domain. This solution eliminates all 326 IPv4 addressing from end to end while still providing the same Dual 327 Stack functionality of IPv4 and IPv6 packet forwarding from a data 328 plane perspective by leveraging the [RFC8950] extended next hop 329 encoding so that IPv4 NLRI can be advertised over a single IPv6 pure 330 transport TCP session. This IPv6-Only E2E architecture eliminates 331 all IPv4 peering and IPv4 addressing E2E from the ingress CE to 332 ingress PE to egress PE to egress CE and all hops along the operator 333 E2E path. 335 Solution applicable to 336 any Edge peering scenario - IXP, Core, DC, Access, etc 338 +-------+ +-------+ 339 | | IPv6 Only | | 340 | CE |----------------| PE | 341 | | IPv6 BGP Peer | | 342 +-------+ +-------+ 343 IPv4 forwarding IPv4 forwarding 344 IPv6 forwarding IPv6 forwarding 346 Figure 3: IPv6-Only Solution Applicability 348 ________ 349 IPv6-Only _____ / \ IPv6-Only 350 PE / CE / \__/ \___ PE / CE 351 +----+ +----+ / \ +------+ +-----+ 352 | | | | |0====VPN Overlay Tunnel ==0| | | | | 353 | | | | | \ | | | | 354 | CE |--| PE |--\ IPv6-Only Core |----| PE |---| CE | 355 | | | | \0=========Underlay ===== ==0 | | | | 356 +----+ +----+ \ __/ +------+ +-----+ 357 IPv6 BGP peer \IP / MPLS / SR domain / IPv6 BGP peer 358 IPv4 forwarding \__ __ / IPv4 forwarding 359 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 361 Figure 4: E2E VPN Solution 363 4.3. IPv6-Only Edge Peering Design 365 4.3.1. IPv6-Only Edge Peering Packet Walk 367 The IPv6-Only Edge Peering design utilizes two key E2E Softwire Mesh 368 Framework scenario's, 4to6 softwire and 6to4 softwire. The Softwire 369 mesh framework concept is based on the overlay and underlay MPLS or 370 SR based technology framework, where the underlay is the transport 371 layer and the overlay is a Virtual Private Network (VPN) layer, and 372 is the the tunneled virtualization layer containing the customer 373 payload. The concept of a 6to4 Softwire is based on transmission of 374 IPv6 packets at the edge of the network by tunneling the IPv6 packets 375 over an IPv4-Only Core. The concept of a 4to6 Softwire is also based 376 on transmission of IPv4 packets at the edge of the network by 377 tunneling the IPv4 packets over an IPv6-Only Core. 379 This document describes End to End (E2E) test scenarios that follow a 380 packet flow from IPv6-Only attachment circuit from ingress PE-CE to 381 egress PE-CE tracing the routing protocol control plane and data 382 plane forwarding of IPv4 packets in a 4to6 softwire or 6to4 softwire 383 within the IPv4-Only or IPv6-Only Core network. In both secneario we 384 are focusing on IPv4 packets and the control plane and data plane 385 forwarding aspects of IPv4 packets from the PE-CE Edge network over 386 an IPv6-Only P (Provider) core network or IPv4-Only P (Provider) core 387 network. With this IPv6-Only Edge peering design, the Softwire Mesh 388 Framework is not extended beyond the Provider Edge (PE) and continues 389 to terminate on the PE router. 391 4.3.2. 6to4 Softwire IPv4-Only Core packet walk 393 6to4 softwire where IPv6-Edge eBGP IPv6 peering where IPv4 packets at 394 network Edge traverse a IPv4-Only Core 396 In the scenario where IPv4 packets originating from a PE-CE edge are 397 tunneled over an MPLS or Segment Routing IPv4 underlay core network, 398 the PE and CE only have an IPv6 address configured on the interface. 399 In this scenario the IPv4 packets that ingress the CE from within the 400 CE AS are over an IPv6-Only interface and are forwarded to an IPv4 401 NLRI destination prefix learned from the Pure Transport Single IPv6 402 BGP Peer. In the IPv6-Only Edge peering architecture the PE is 403 IPv6-Only as all PE-CE interfaces are IPv6-Only. However, on the CE, 404 the PE-CE interface is the only interface that is IPv6-Only and all 405 other interfaces may or may not be IPv6-Only. Following the data 406 plane packet flow, IPv4 packets are forwarded from the ingress CE to 407 the IPv6-Only ingress PE where the VPN label imposition push per 408 prefix, per-vrf, per-CE occurs and the labeled packet is forwarded 409 over a 6to4 softwire IPv4-Only core, to the egress PE where the VPN 410 label disposition pop occurs and the native IPv4 packet is forwarded 411 to the egress CE. In the reverse direction IPv4 packets are 412 forwarded from the egress CE to egress PE where the VPN label 413 imposition per prefix, per-vrf, per-CE push occurs and the labeled 414 packet is forwarded back over the 6to4 softwire IPv4-Only core, to 415 the ingress PE where the VPN label disposition pop occurs and the 416 native IPv4 packet is forwarded to the ingress CE. . The 417 functionality of the IPv4 forwarding plane in this scenario is 418 identical from a data plane forwarding perspective to Dual Stack IPv4 419 forwarding scenario. 421 +--------+ +--------+ 422 | IPv4 | | IPv4 | 423 | Client | | Client | 424 | Network| | Network| 425 +--------+ +--------+ 426 | \ / | 427 | \ / | 428 | \ / | 429 | X | 430 | / \ | 431 | / \ | 432 | / \ | 433 +--------+ +--------+ 434 | AFBR | | AFBR | 435 +--| IPv4/6 |---| IPv4/6 |--+ 436 | +--------+ +--------+ | 437 +--------+ | | +--------+ 438 | IPv4 | | | | IPv4 | 439 | Client | | | | Client | 440 | Network|------| IPv4 |-------| Network| 441 +--------+ | only | +--------+ 442 | | 443 | +--------+ +--------+ | 444 +--| AFBR |---| AFBR |--+ 445 | IPv4/6 | | IPv4/6 | 446 +--------+ +--------+ 447 | \ / | 448 | \ / | 449 | \ / | 450 | X | 451 | / \ | 452 | / \ | 453 | / \ | 454 +--------+ +--------+ 455 | IPv6 | | IPv4 | 456 | Client | | Client | 457 | Network| | Network| 458 +--------+ +--------+ 460 Figure 5: 6to4 Softwire - IPv6 Edge over an IPv4-Only Core 462 4.3.3. 4to6 Softwire IPv6-Only Core packet walk 464 4to6 softwire where IPv6-Edge eBGP IPv6 peering where IPv4 packets at 465 network Edge traverse a IPv6-Only Core 466 In the scenario where IPv4 packets originating from a PE-CE edge are 467 tunneled over an MPLS or Segment Routing IPv4 underlay core network, 468 the PE and CE only have an IPv6 address configured on the interface. 469 In this scenario the IPv4 packets that ingress the CE from within the 470 CE AS are over an IPv6-Only interface and are forwarded to an IPv4 471 NLRI destination prefix learned from the Pure Transport Single IPv6 472 BGP Peer. In the IPv6-Only Edge peering architecture the PE is 473 IPv6-Only as all PE-CE interfaces are IPv6-Only. However, on the CE, 474 the PE-CE interface is the only interface that is IPv6-Only and all 475 other interfaces may or may not be IPv6-Only. Following the data 476 plane packet flow, IPv4 packets are forwarded from the ingress CE to 477 the IPv6-Only ingress PE where the VPN label imposition push per 478 prefix, per-vrf, per-CE occurs and the labeled packet is forwarded 479 over a 4to6 softwire IPv6-Only core, to the egress PE where the VPN 480 label disposition pop occurs and the native IPv4 packet is forwarded 481 to the egress CE. In the reverse direction IPv4 packets are 482 forwarded from the egress CE to egress PE where the VPN label 483 imposition per prefix, per-vrf, per-CE push occurs and the labeled 484 packet is forwarded back over the 4to6 softwire IPv6-Only core, to 485 the ingress PE where the VPN label disposition pop occurs and the 486 native IPv4 packet is forwarded to the ingress CE. . The 487 functionality of the IPv4 forwarding plane in this scenario is 488 identical from a data plane forwarding perspective to Dual Stack IPv4 489 forwarding scenario. 491 +--------+ +--------+ 492 | IPv4 | | IPv4 | 493 | Client | | Client | 494 | Network| | Network| 495 +--------+ +--------+ 496 | \ / | 497 | \ / | 498 | \ / | 499 | X | 500 | / \ | 501 | / \ | 502 | / \ | 503 +--------+ +--------+ 504 | AFBR | | AFBR | 505 +--| IPv4/6 |---| IPv4/6 |--+ 506 | +--------+ +--------+ | 507 +--------+ | | +--------+ 508 | IPv6 | | | | IPv6 | 509 | Client | | | | Client | 510 | Network|------| IPv6 |-------| Network| 511 +--------+ | only | +--------+ 512 | | 513 | +--------+ +--------+ | 514 +--| AFBR |---| AFBR |--+ 515 | IPv4/6 | | IPv4/6 | 516 +--------+ +--------+ 517 | \ / | 518 | \ / | 519 | \ / | 520 | X | 521 | / \ | 522 | / \ | 523 | / \ | 524 +--------+ +--------+ 525 | IPv4 | | IPv4 | 526 | Client | | Client | 527 | Network| | Network| 528 +--------+ +--------+ 530 Figure 6: 4to6 Softwire - IPv4 Edge over an IPv6-Only Core 532 4.4. RFC5549 and RFC8950 Applicability 533 4.4.1. IPv6-Only Edge Peering design next-hop encoding 535 This section describes [RFC8950] next hop encoding updates to 536 [RFC5549] applicability to this specification. IPv6-only eBGP Edge 537 PE-CE peering to carry IPv4 Unicast NLRI IPv4 <1/1> over 538 an IPv6 next hop BGP capability extended hop encoding IANA capability 539 codepoint value 5 defined is applicable to both [RFC5549] and 540 [RFC8950] as IPv4 Unicast NLRI IPv4 <1/1> does not change 541 in the RFC updates. 543 IPv4 packets over an IPv6-Only core 4to6 Softwire E2E packet flow is 544 part of the IPv6-Only design vendor interoperaiblity test cases and 545 in that respect is applicable as [RFC8950] updates [RFC5549] for 546 VPN-IPV4 <1/128>, and Multicasat VPN <1/129> 548 4.4.2. RFC8950 updates to RFC5549 applicability 550 This section describes the [RFC8950] next hop encoding updates to 551 [RFC5549] 553 In [RFC5549] when AFI/SAFI 1/128 is used, the next-hop address is 554 encoded as an IPv6 address with a length of 16 or 32 bytes. This 555 document modifies how the next-hop address is encoded to accommodate 556 all existing implementations and bring consistency with VPNv4oIPv4 557 and VPNv6oIPv6. The next-hop address is now encoded as a VPN-IPv6 558 address with a length of 24 or 48 bytes [RFC8950] (see Sections 3 and 559 6.2 of this document). This change addresses Erratum ID 5253 560 (Err5253). As all known and deployed implementations are 561 interoperable today and use the new proposed encoding, the change 562 does not break existing interoperability. Updates to [RFC8950] is 563 applicable to the IPv6-Only PE-CE edge design for the IPv6 next hop 564 encoding E2E test case of IPv4 packets over and IPv6-Only core 4to6 565 Softwire. In this test case IPv4 Unicast NLRI IPv4 <1/1> 566 is advertised over the PE to RR core peering 4to6 softwire in VPN-IPV4 <1/128>. In this test case label allocation mode 568 comes into play which is discussed in section 8.9. 570 [RFC5549] next hop encoding of MP_REACH_NLRI with: 572 * NLRI= NLRI as per current AFI/SAFI definition 574 Advertising with [RFC4760] MP_REACH_NLRI with: 576 * AFI = 1 578 * SAFI = 128 or 129 580 * Length of Next Hop Address = 16 or 32 581 * NLRI= NLRI as per current AFI/SAFI definition 583 [RFC8950] next hop encoding of MP_REACH_NLRI with: 585 * NLRI= NLRI as per current AFI/SAFI definition 587 Advertising with [RFC4760] MP_REACH_NLRI with: 589 * AFI = 1 591 * SAFI = 128 or 129 593 * Length of Next Hop Address = 24 or 48 595 * Next Hop Address = VPN-IPv6 address of next hop with an 8-octet RD 596 set to zero (potentially followed by the link-local VPN-IPv6 597 address of the next hop with an 8-octet RD is set to zero). 599 * NLRI= NLRI as per current AFI/SAFI definition 601 5. IPv6-Only PE Design Edge E2E Design for all AFI/SAFI 603 Proof of conept interoperability testing of the 4 test cases bet 605 5.1. Design Solution-1 E2E IPv6-Only PE-CE, Global Table over IPv4-Only 606 Core(6PE), 6to4 softwire 608 ________ 609 IPv6-Only _____ / \ IPv6-Only 610 PE / CE / \__/ \___ PE / CE 611 +----+ +----+ / \ +------+ +-----+ 612 | | | | | |_ | | | | 613 | | | | | \ | | | | 614 | CE |--| PE |--\ IPv4-Only Core |----| PE |---| CE | 615 | | | | \0=========Underlay =======0| | | | | 616 +----+ +----+ \ __/ +------+ +-----+ 617 IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer 618 IPv4 forwarding \__ __ / IPv4 forwarding 619 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 621 Figure 7: Design Solution-1 E2E IPv6-Only PE-CE, Global 622 Table over IPv4-Only Core (6PE) 624 Cisco, Juniper, Arista, Nokia, Huawei code and platform and test 625 results. 627 Cisco: Edge Router- XR ASR 9910 IOS XR 7.4.1, Core Router- NCS 6000 628 7.2.2, CRS-X 6.7.4 630 Juniper: Edge Router- MX platform MX480, MX960, Core Router- PTX 631 Platform PTX5000, PTC10K8 (JUNOS and EVO) Release 20.4R2 633 Tested v4 edge over v6 core in a virtual setup using vMX platforrm 634 and 20.4R2 and LDPv6 as underlay, but there were some data plane 635 forwarding issues. Tested same setup on latest release 21.4 and it 636 worked. Investigating what the minimum version is for this setup to 637 work. 639 Arista: 641 Nokia: Edge and Core-7750 Service Router, Release R21 643 Huawei: Edge and Core-VRPv8, Release VRP-V800R020C10 645 5.2. Design Solution-2 E2E IPv6-Only PE-CE, VPN over IPv4-Only Core, 646 6to4 Softwire 648 ________ 649 IPv6-Only _____ / \ IPv6-Only 650 PE / CE / \__/ \___ PE / CE 651 +----+ +----+ / \ +------+ +-----+ 652 | | | | | 0====VPN Overlay Tunnel ==0| | | | | 653 | | | | | \ | | | | 654 | CE |--| PE |--\ IPv4-Only Core |----| PE |---| CE | 655 | | | | \0=========Underlay =======0| | | | | 656 +----+ +----+ \ __/ +------+ +-----+ 657 IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer 658 IPv4 forwarding \__ __ / IPv4 forwarding 659 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 661 Figure 8: Design Solution-2 E2E IPv6-Only PE-CE, VPN over 662 IPv4-Only Core 664 5.3. Design Solution-3 E2E IPv6-Only PE-CE, Global Table over IPv6-Only 665 Core (4PE), 4to6 Softwire 666 ________ 667 IPv6-Only _____ / \ IPv6-Only 668 PE / CE / \__/ \___ PE / CE 669 +----+ +----+ / \ +------+ +-----+ 670 | | | | | |_ | | | | 671 | | | | | \ | | | | 672 | CE |--| PE |--\ IPv6-Only Core |----| PE |---| CE | 673 | | | | \0=========Underlay =======0| | | | | 674 +----+ +----+ \ __/ +------+ +-----+ 675 IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer 676 IPv4 forwarding \__ __ / IPv4 forwarding 677 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 679 Figure 9: Design Solution-3 E2E IPv6-Only PE-CE, Global 680 Table over IPv6-Only Core (4PE) 682 5.4. Design Solution-4 E2E IPv6-Only PE-CE, VPN over IPv6-Only Core, 683 4to6 Softwire 685 ________ 686 IPv6-Only _____ / \ IPv6-Only 687 PE / CE / \__/ \___ PE / CE 688 +----+ +----+ / \ +------+ +-----+ 689 | | | | | 0====VPN Overlay Tunnel ==0| | | | | 690 | | | | | \ | | | | 691 | CE |--| PE |--\ IPv6-Only Core |----| PE |---| CE | 692 | | | | \0=========Underlay =======0| | | | | 693 +----+ +----+ \ __/ +------+ +-----+ 694 IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer 695 IPv4 forwarding \__ __ / IPv4 forwarding 696 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 698 Figure 10: Design Solution-4 E2E IPv6-Only PE-CE, VPN over 699 IPv6-Only Core 701 5.5. Design Solution-5 E2E Inter-AS Option B and AB, 4to6 Softwire 702 ________ 703 IPv6-Only _____ / \ IPv6-Only 704 PE / CE / \__/ \___ PE / CE 705 +----+ +----+ / \ +------+ +-----+ 706 | | | | | 0====VPN Overlay Tunnel ==0| | | | | 707 | | | | | \ | | | | 708 | CE |--| PE |--\ IPv6-Only Core |----| PE |---| CE | 709 | | | | \0=========Underlay =======0| | | | | 710 +----+ +----+ \ __/ +------+ +-----+ 711 IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer 712 IPv4 forwarding \__ __ / IPv4 forwarding 713 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 715 Figure 11: Design Solution-5 E2E E2E Inter-AS Option B and AB 716 over IPv6-Only Core 718 5.6. IPv6-Only PE-CE Operational Considerations Testing 720 Ping CE to PE when destination prefix is withdrawn 721 Traceroute CE to PE and test all ICMPv4 and ICMPv6 type codes 723 +-------+ +-------+ 724 | | IPv6 Only | | 725 | CE |----------------| PE | 726 | | IPv6 BGP Peer | | 727 +-------+ +-------+ 728 IPv4 forwarding IPv4 forwarding 729 IPv6 forwarding IPv6 forwarding 731 Figure 12: Ping and Trace Test Case 733 6. IPv6-Only PE ALL AFI/SFI Operational Considerations 735 With a single IPv6 Peer carrying both IPv4 and IPv6 NLRI there are 736 some operational considerations in terms of what changes and what 737 does not change. 739 What does not change with a single IPv6 transport peer carrying IPv4 740 NLRI and IPv6 NLRI below: 742 Routing Policy configuration is still separate for IPv4 and IPv6 743 configured by capability as previously. 745 Layer 1, Layer 2 issues such as one-way fiber or fiber cut will 746 impact both IPv4 and IPv6 as previously. 748 If the interface is in the Admin Down state, the IPv6 peer would go 749 down, and IPv4 NLRI and IPv6 NLRI would be withdrawn as previously. 751 Changes resulting from a single IPv6 transport peer carrying IPv4 752 NLRI and IPv6 NLRI below: 754 Physical interface is no longer dual stacked. 756 Any change in IPv6 address or DAD state will impact both IPv4 and 757 IPv6 NLRI exchange. 759 Single BFD session for both IPv4 and IPv6 NLRI fate sharing as the 760 session is now tied to the transport, which now is only IPv6 address 761 family. 763 Both IPv4 and IPv6 peer now exists under the IPv6 address family 764 configuration. 766 Fate sharing of IPv4 and IPv6 address family from a logical 767 perspective now carried over a single physical IPv6 peer. 769 From an operations perspective, prior to elimination of IPv4 peers, 770 an audit is recommended to identify and IPv4 and IPv6 peering 771 incongruencies that may exist and to rectify them. No operational 772 impacts or issues are expected with this change. 774 With MPLS VPN overlay, per-CE next-hop label allcoation mode where 775 both IPv4 and IPv6 prefixes have the same label in no table lookup 776 pop-n-forward mode should be taken into consideration. 778 7. Vendor Implementations and Operator Deployments 780 Vendor implementations are with Cisco, Juniper, Nokia, Arista and 781 Huawei 783 8. IANA Considerations 785 There are not any IANA considerations. 787 9. Security Considerations 789 The extensions defined in this document allow BGP to propagate 790 reachability information about IPv4 prefixes over an MPLS or SR 791 IPv6-Only core network. As such, no new security issues are raised 792 beyond those that already exist in BGP-4 and the use of MP-BGP for 793 IPv6. Both IPv4 and IPv6 peers exist under the IPv6 address family 794 configuration. The security features of BGP and corresponding 795 security policy defined in the ISP domain are applicable. For the 796 inter-AS distribution of IPv6 routes according to case (a) of 797 Section 4 of this document, no new security issues are raised beyond 798 those that already exist in the use of eBGP for IPv6 [RFC2545]. 800 10. Acknowledgments 802 Thanks to Kaliraj Vairavakkalai, Linda Dunbar, Aijun Wang, Eduardfor 803 Vasilenko, Joel Harlpern, Michael McBride, Ketan Talaulikar for 804 review comments. 806 11. Contributors 808 The following people contributed substantive text to this document: 810 Mohana Sundari 811 EMail: mohanas@juniper.net 813 12. References 815 12.1. Normative References 817 [I-D.ietf-bess-ipv6-only-pe-design] 818 Mishra, G., Mishra, M., Tantsura, J., Madhavi, S., Yang, 819 Q., Simpson, A., and S. Chen, "IPv6-Only PE Design for 820 IPv4-NLRI with IPv6-NH", Work in Progress, Internet-Draft, 821 draft-ietf-bess-ipv6-only-pe-design-00, 20 September 2021, 822 . 825 [I-D.nalawade-kapoor-tunnel-safi] 826 Nalawade, G., "BGP Tunnel SAFI", Work in Progress, 827 Internet-Draft, draft-nalawade-kapoor-tunnel-safi-05, 29 828 June 2006, . 831 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 832 Requirement Levels", BCP 14, RFC 2119, 833 DOI 10.17487/RFC2119, March 1997, 834 . 836 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 837 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 838 DOI 10.17487/RFC2545, March 1999, 839 . 841 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 842 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 843 2006, . 845 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 846 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 847 2006, . 849 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 850 "Multiprotocol Extensions for BGP-4", RFC 4760, 851 DOI 10.17487/RFC4760, January 2007, 852 . 854 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 855 LAN Service (VPLS) Using BGP for Auto-Discovery and 856 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 857 . 859 [RFC5195] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP-Based 860 Auto-Discovery for Layer-1 VPNs", RFC 5195, 861 DOI 10.17487/RFC5195, June 2008, 862 . 864 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 865 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 866 2009, . 868 [RFC5747] Wu, J., Cui, Y., Li, X., Xu, M., and C. Metz, "4over6 869 Transit Solution Using IP Encapsulation and MP-BGP 870 Extensions", RFC 5747, DOI 10.17487/RFC5747, March 2010, 871 . 873 [RFC6037] Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco 874 Systems' Solution for Multicast in BGP/MPLS IP VPNs", 875 RFC 6037, DOI 10.17487/RFC6037, October 2010, 876 . 878 [RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and 879 C. Kodeboniya, "Multicast in Virtual Private LAN Service 880 (VPLS)", RFC 7117, DOI 10.17487/RFC7117, February 2014, 881 . 883 [RFC7267] Martini, L., Ed., Bocci, M., Ed., and F. Balus, Ed., 884 "Dynamic Placement of Multi-Segment Pseudowires", 885 RFC 7267, DOI 10.17487/RFC7267, June 2014, 886 . 888 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 889 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 890 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 891 2015, . 893 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 894 S. Ray, "North-Bound Distribution of Link-State and 895 Traffic Engineering (TE) Information Using BGP", RFC 7752, 896 DOI 10.17487/RFC7752, March 2016, 897 . 899 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 900 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 901 May 2017, . 903 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 904 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 905 . 907 [RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 908 Bacher, "Dissemination of Flow Specification Rules", 909 RFC 8955, DOI 10.17487/RFC8955, December 2020, 910 . 912 [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, 913 "The BGP Tunnel Encapsulation Attribute", RFC 9012, 914 DOI 10.17487/RFC9012, April 2021, 915 . 917 [RFC9015] Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. 918 Jalil, "BGP Control Plane for the Network Service Header 919 in Service Function Chaining", RFC 9015, 920 DOI 10.17487/RFC9015, June 2021, 921 . 923 12.2. Informative References 925 [I-D.ietf-idr-dynamic-cap] 926 Chen, E. and S. R. Sangli, "Dynamic Capability for BGP-4", 927 Work in Progress, Internet-Draft, draft-ietf-idr-dynamic- 928 cap-16, 21 October 2021, . 931 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 932 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 933 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 934 . 936 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 937 R., Patel, K., and J. Guichard, "Constrained Route 938 Distribution for Border Gateway Protocol/MultiProtocol 939 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 940 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 941 November 2006, . 943 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 944 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 945 Provider Edge Routers (6PE)", RFC 4798, 946 DOI 10.17487/RFC4798, February 2007, 947 . 949 [RFC4925] Li, X., Ed., Dawkins, S., Ed., Ward, D., Ed., and A. 950 Durand, Ed., "Softwire Problem Statement", RFC 4925, 951 DOI 10.17487/RFC4925, July 2007, 952 . 954 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 955 Layer Reachability Information with an IPv6 Next Hop", 956 RFC 5549, DOI 10.17487/RFC5549, May 2009, 957 . 959 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 960 Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, 961 . 963 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 964 "Provisioning, Auto-Discovery, and Signaling in Layer 2 965 Virtual Private Networks (L2VPNs)", RFC 6074, 966 DOI 10.17487/RFC6074, January 2011, 967 . 969 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 970 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 971 2012, . 973 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 974 Encodings and Procedures for Multicast in MPLS/BGP IP 975 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 976 . 978 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 979 Writing an IANA Considerations Section in RFCs", BCP 26, 980 RFC 8126, DOI 10.17487/RFC8126, June 2017, 981 . 983 [RFC8950] Litkowski, S., Agrawal, S., Ananthamurthy, K., and K. 984 Patel, "Advertising IPv4 Network Layer Reachability 985 Information (NLRI) with an IPv6 Next Hop", RFC 8950, 986 DOI 10.17487/RFC8950, November 2020, 987 . 989 Author's Address 991 Gyan Mishra 992 Verizon Inc. 994 Email: gyan.s.mishra@verizon.com