idnits 2.17.1 draft-ietf-bess-ipv6-only-pe-design-02.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. 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 (20 March 2022) is 740 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 1024, but no explicit reference was found in the text == Unused Reference: 'RFC5492' is defined on line 1037, but no explicit reference was found in the text == Unused Reference: 'RFC8277' is defined on line 1045, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-dynamic-cap' is defined on line 1051, but no explicit reference was found in the text == Unused Reference: 'RFC4659' is defined on line 1057, but no explicit reference was found in the text == Unused Reference: 'RFC4684' is defined on line 1062, but no explicit reference was found in the text == Unused Reference: 'RFC4798' is defined on line 1069, but no explicit reference was found in the text == Unused Reference: 'RFC4925' is defined on line 1075, but no explicit reference was found in the text == Unused Reference: 'RFC6074' is defined on line 1089, but no explicit reference was found in the text == Unused Reference: 'RFC6513' is defined on line 1095, but no explicit reference was found in the text == Unused Reference: 'RFC6514' is defined on line 1099, but no explicit reference was found in the text == Unused Reference: 'RFC8126' is defined on line 1104, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5549 (Obsoleted by RFC 8950) Summary: 1 error (**), 0 flaws (~~), 14 warnings (==), 2 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 M. Mishra 5 Expires: 21 September 2022 Cisco Systems 6 J. Tantsura 7 Microsoft, Inc. 8 S. Madhavi 9 Juniper Networks, Inc. 10 Q. Yang 11 Arista Networks 12 A. Simpson 13 Nokia 14 S. Chen 15 Huawei Technologies 16 20 March 2022 18 IPv6-Only PE Design for IPv4-NLRI with IPv6-NH 19 draft-ietf-bess-ipv6-only-pe-design-02 21 Abstract 23 As Enterprises and Service Providers upgrade their brown field or 24 green field MPLS/SR core to an IPv6 transport, Multiprotocol BGP (MP- 25 BGP)now plays an important role in the transition of their Provider 26 (P) core network as well as Provider Edge (PE) Edge network from IPv4 27 to IPv6. Operators must be able to continue to support IPv4 28 customers when both the Core and Edge networks are IPv6-Only. 30 This document details an important External BGP (eBGP) PE-CE Edge and 31 Inter-AS IPv6-Only peering design that leverages the MP-BGP 32 capability exchange by using IPv6 peering as pure transport, allowing 33 both IPv4 Network Layer Reachability Information (NLRI) and IPv6 34 Network Layer Reachability Information (NLRI)to be carried over the 35 same (Border Gateway Protocol) BGP TCP session. The design change 36 provides the same Dual Stacking functionality that exists today with 37 separate IPv4 and IPv6 BGP sessions as we have today. With this 38 design change from a control plane perspective a single IPv6 is 39 required for both IPv4 and IPv6 routing updates and from a data plane 40 forwarindg perspective an IPv6 address need only be configured on the 41 PE and CE interface for both IPv4 and IPv6 packet forwarding. 43 This document provides a much needed solution for Internet Exchange 44 Point (IXP) that are facing IPv4 address depletion at large peering 45 points. With this design, IXP can now deploy PE-CE IPv6-Only eBGP 46 Edge or Inter-AS peering design to eliminate IPv4 provisioning at the 47 Edge. This core and edge IPv6-Only peering design paradigm change 48 can apply to any eBGP peering, public internet or private, which can 49 be either Core networks, Data Center networks, Access networks or can 50 be any eBGP peering scenario. This document provides vendor specific 51 test cases for the IPv6-Only peering design as well as test results 52 for the five major vendors stakeholders in the routing and switching 53 indusrty, Cisco, Juniper, Arista, Nokia and Huawei. With the test 54 results provided for the IPv6-Only Edge peering design, the goal is 55 that all other vendors around the world that have not been tested 56 will begin to adopt and implement this new Best Current Practice for 57 eBGP IPv6-Only Edge peering. 59 As this issue with IXP IPv4 address depletion is a critical issue 60 around the world, it is imperative for an immediate solution that can 61 be implemented quickly. This Best Current Practice IPv6-only eBGP 62 peering design specification will help proliferate IPv6-Only 63 deployments at the eBGP Edge network peering points to starting 64 immediately at a minimum with operators around the world using Cisco, 65 Juniper, Arista, Nokia and Huawei. As other vendors start to 66 implement this Best Current Practice, the IXP IPv4 address depletion 67 gap will eventually be eliminated. 69 Status of This Memo 71 This Internet-Draft is submitted in full conformance with the 72 provisions of BCP 78 and BCP 79. 74 Internet-Drafts are working documents of the Internet Engineering 75 Task Force (IETF). Note that other groups may also distribute 76 working documents as Internet-Drafts. The list of current Internet- 77 Drafts is at https://datatracker.ietf.org/drafts/current/. 79 Internet-Drafts are draft documents valid for a maximum of six months 80 and may be updated, replaced, or obsoleted by other documents at any 81 time. It is inappropriate to use Internet-Drafts as reference 82 material or to cite them other than as "work in progress." 84 This Internet-Draft will expire on 21 September 2022. 86 Copyright Notice 88 Copyright (c) 2022 IETF Trust and the persons identified as the 89 document authors. All rights reserved. 91 This document is subject to BCP 78 and the IETF Trust's Legal 92 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 93 license-info) in effect on the date of publication of this document. 94 Please review these documents carefully, as they describe your rights 95 and restrictions with respect to this document. Code Components 96 extracted from this document must include Revised BSD License text as 97 described in Section 4.e of the Trust Legal Provisions and are 98 provided without warranty as described in the Revised BSD License. 100 Table of Contents 102 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 103 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 104 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 105 4. IPv6-Only Edge Peering Architecture . . . . . . . . . . . . . 7 106 4.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 7 107 4.2. IPv6-Only PE-CE Design Solution . . . . . . . . . . . . . 8 108 4.3. IPv6-Only Edge Peering Design . . . . . . . . . . . . . . 9 109 4.3.1. IPv6-Only Edge Peering Packet Walk . . . . . . . . . 9 110 4.3.2. 6to4 Softwire IPv4-Only Core packet walk . . . . . . 10 111 4.3.3. 4to6 Softwire IPv6-Only Core packet walk . . . . . . 11 112 4.4. RFC5549 and RFC8950 Applicability . . . . . . . . . . . . 13 113 4.4.1. IPv6-Only Edge Peering design next-hop encoding . . . 14 114 4.4.2. RFC8950 updates to RFC5549 applicability . . . . . . 14 115 5. IPv6-Only PE Design Edge and Inter-AS Options E2E Test 116 Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 15 117 5.1. Test-1 E2E IPv6-Only PE-CE, Global Table over IPv4-Only 118 Core(6PE), 6to4 softwire . . . . . . . . . . . . . . . . 17 119 5.2. Test-2 E2E IPv6-Only PE-CE, VPN over IPv4-Only Core, 6to4 120 Softwire . . . . . . . . . . . . . . . . . . . . . . . . 17 121 5.3. Test-3 E2E IPv6-Only PE-CE, Global Table over IPv6-Only 122 Core, 4to6 Softwire . . . . . . . . . . . . . . . . . . 18 123 5.4. Test-4 E2E IPv6-Only PE-CE, VPN over IPv6-Only Core, 4to6 124 Softwire . . . . . . . . . . . . . . . . . . . . . . . . 18 125 5.5. Test-5 E2E IPv6-Only PE-CE, Global Table over IPv4-Only 126 Core(6PE), 6to4 softwire -Inter-AS Option-B . . . . . . 19 127 5.6. Test-6 E2E IPv6-Only PE-CE, Global Table over IPv4-Only 128 Core(6PE), 6to4 softwire -Inter-AS Option-C . . . . . . 19 129 5.7. Test-7 E2E IPv6-Only PE-CE, VPN over IPv4-Only, 6to4 130 softwire -Inter-AS Option-B . . . . . . . . . . . . . . 20 131 5.8. Test-8 E2E IPv6-Only PE-CE, VPN over IPv4-Only Core, 6to4 132 softwire -Inter-AS Option-C . . . . . . . . . . . . . . 20 133 5.9. Test-9 E2E IPv6-Only PE-CE, Global Table over IPv6-Only 134 Core, 4to6 softwire -Inter-AS Option-B . . . . . . . . . 21 135 5.10. Test-10 E2E IPv6-Only PE-CE, Global Table over IPv6-Only 136 Core, 4to6 softwire -Inter-AS Option-C . . . . . . . . . 21 137 5.11. Test-11 E2E IPv6-Only PE-CE, VPN over IPv6-Only Core, 4to6 138 softwire -Inter-AS Option-B . . . . . . . . . . . . . . 22 140 5.12. Test-12 E2E IPv6-Only PE-CE, VPN over IPv6-Only Core, 4to6 141 softwire -Inter-AS Option-C . . . . . . . . . . . . . . 22 142 5.13. IPv6-Only PE-CE Operational Considerations Testing . . . 23 143 6. Operational Considerations . . . . . . . . . . . . . . . . . 23 144 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 145 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 146 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 147 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 148 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 149 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 150 11.2. Informative References . . . . . . . . . . . . . . . . . 26 151 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 153 1. Introduction 155 As Enterprises and Service Providers upgrade their brown field or 156 green field MPLS/SR core to an IPv6 transport such as MPLS LDPv6, SR- 157 MPLSv6 or SRv6, Multiprotocol BGP (MP-BGP) now plays an important 158 role in the transition of the Provider (P) core networks and Provider 159 Edge (PE) edge networks from IPv4 to IPv6. Operators have a 160 requirement to support IPv4 customers and must be able to support 161 IPv4 address family and Sub-Address-Family Virtual Private Network 162 (VPN)-IPv4, and Multicast VPN IPv4 customers. 164 IXP are also facing IPv4 address depletion at their peering points, 165 which are large Layer 2 transit backbones that service providers peer 166 and exchange IPv4 and IPv6 Network Layer Reachability Information 167 (NLRI). Today, these transit exchange points are Dual Stacked. With 168 this IPv6-only BGP peering design, only IPv6 is configured on the PE- 169 CE interface, the Provider Edge (PE) - Customer Edge (CE), or Inter- 170 AS ASBR (Autonomous System Boundary Router) to ASBR (Autonomous 171 System Boundary Router) PE-PE Provider Edge (PE) - Provider Edge 172 (PE), the IPv6 BGP peer is now used to carry IPv4 (Network Layer 173 Reachability Information) NLRI over an IPv6 next hop using IPv6 next 174 hop encoding defined in [RFC8950], while continuing to forward both 175 IPv4 and IPv6 packets. In the framework of this design the PE is no 176 longer Dual Stacked. However in the case of the CE, PE-CE link CE 177 side of the link is no longer Dual Stacked, however all other 178 internal links within the CE domain may or maynot be Dual stacked. 179 In the Inter-AS case the ASBR-ASBR PE-PE peering all peerings would 180 be now IPv6-Only for all Inter-AS options Peering Option-A, Option-B, 181 Option-AB and Option-C per [RFC4364]. We now refer to this PE as an 182 "IPv6-Only PE" using the IPv6-Only PE Design framework. 184 MP-BGP specifies that the set of usable next-hop address families is 185 determined by the Address Family Identifier (AFI) and the Subsequent 186 Address Family Identifier (SAFI). Historically the AFI/SAFI 187 definitions for the IPv4 address family only have provisions for 188 advertising a Next Hop address that belongs to the IPv4 protocol when 189 advertising IPv4 or VPN-IPv4. [RFC8950] specifies the extensions 190 necessary to allow advertising IPv4 NLRI, Virtual Private Network 191 Unicast (VPN-IPv4) NLRI, Multicast Virtual Private Network (MVPN- 192 IPv4) NLRI with a Next Hop address that belongs to the IPv6 protocol. 193 This comprises of an extended next hop encoding MP-REACH BGP 194 capability exchange to allow the address of the Next Hop for IPv4 195 NLRI, VPN-IPv4 NLRI and MVPN-IPv4 NLRI to also belong to the IPv6 196 Protocol. [RFC8950] defines the encoding of the Next Hop to 197 determine which of the protocols the address actually belongs to, and 198 a new BGP Capability allowing MP-BGP Peers to discover dynamically 199 whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 200 Next Hop. 202 The current specification for carrying IPv4 NLRI of a given address 203 family via a Next Hop of a different address family is now defined in 204 [RFC8950], and specifies the extended next hop encoding MP-REACH 205 capability extension necessary to do so. This comprises an extension 206 of the AFI/SAFI definitions to allow the address of the Next Hop for 207 IPv4 NLRI or VPN-IPv4 NLRI to belong to either the IPv4 or the IPv6 208 protocol, the encoding of the Next Hop information to determine which 209 of the protocols the address belongs to, and a new BGP Capability 210 allowing MP-BGP peers to dynamically discover whether they can 211 exchange IPv4 NLRI and VPN- IPv4 NLRI with an IPv6 Next Hop. 213 With the new extensions defined in [RFC8950] supporting NLRI and next 214 hop address family mismatch, the BGP peer session can now be treated 215 as a pure TCP transport and carry both IPv4 and IPv6 NLRI at the 216 Provider Edge (PE) - Customer Edge (CE) or Inter-AS ASBR to ASBR PE- 217 PE over a single IPv6 TCP session. This allows for the elimination 218 of dual stack from the PE-CE and Inter-AS ASBR-ASBR PE-PE peering 219 point, and now enable the peering to be IPv6-ONLY. The elimination 220 of IPv4 on the PE-CE and Inter-AS ASBR-ASBR PE-PE peering points 221 translates into OPEX expenditure savings of point-to-point 222 infrastructure links as well as /31 address space savings and 223 administration and network management of both IPv4 and IPv6 BGP 224 peers. This reduction decreases the number of PE-CE BGP peers by 225 fifty percent, which is a tremendous cost savings for operators. 227 While the savings exists at the Edge eBGP PE-CE peering, on the core 228 side PE to Route Reflector (RR) peering carrying IPv4 229 <1/1>, VPN-IPV4 <1/128>, and Multicasat VPN <1/129>, there is no 230 savings as the Provider (P) Core is IPv6 Only and thus can only have 231 an IPv6 peer and must use [RFC8950] extended next hop encoding to 232 carrying IPv4 NLRI IPV4 <2/1>, VPN-IPV4 <2/128>, and Multicasat VPN 233 <2/129> over an IPv6 next hop. 235 This IPv6-Only PE design is applicable to both PE-CE Edge over a 236 IPv4-Only Core, IPv6-Only Core as well as Global table or VPN overlay 237 scenario as well as all Inter-AS Options Option-A, Option-B, Option- 238 AB and Option-C The following Address Family (AFI) / Subsequent 239 Address Family (SAFI) will be tested with both IPv4-Only Core, 240 IPv6-Only Core and Global Routing Table (GRT) and IP Virtual Private 241 Network (VPN) [RFC4364]. IPv4 <1/1>, VPN-IPV4 <1/128>, 242 and Multicasat VPN <1/129>. 244 This document provides a much needed solution for Internet Exchange 245 Point (IXP) that are facing IPv4 address depletion at large peering 246 points. With this design, IXP can now use deploy PE-CE IPv6-Only 247 eBGP Edge and Inter-AS peering design to eliminate IPv4 provisioning 248 at the PE Edge as well as PE Inter-AS. This core and edge IPv6-Only 249 peering design paradigm change can apply to any eBGP peering, public 250 internet or private, which can be either Core networks, Data Center 251 networks, Access networks or can be any eBGP peering scenario. This 252 document provides detailed vendor specific test cases and test 253 results for the IPv6-Only peering design as well as successful test 254 results between five major vendors stakeholders in the routing and 255 switching indusrty, Cisco, Juniper, Arista, Nokia and Huawei. With 256 the test results provided for the IPv6-Only Edge peering design, the 257 goal is that all other vendors around the world that have not been 258 tested will begin to adopt and implement this new best practice for 259 eBGP IPv6-Only Edge peering. This will give confidence to operators 260 to start the proliferation of this IPv6-Only PE design. 262 As this issue with IXP address depletion is a critical issue around 263 the world, it is imperative for an immediate solution that can be 264 implemented quickly. This best practice IPv6-only eBGP peering 265 design specification will help proliferate IPv6-Only deployments at 266 the eBGP Edge and Inter-AS network peering points starting 267 immediately at a minimum with operators around the world using Cisco, 268 Juniper, Arista, Nokia and Huawei. 270 2. Requirements Language 272 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 273 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 274 "OPTIONAL" in this document are to be interpreted as described in BCP 275 14 [RFC2119] [RFC8174] when, and only when, they appear in all 276 capitals, as shown here. 278 3. Terminology 280 Terminolgoy used in defining the IPv6-Only Edge specification. 282 AFBR: Address Family Border Router Provider Edge (PE). 284 Edge: PE-CE Edge Network Provider Edge - Customer Edge 286 Core: P Core Network Provider (P) 288 4to6 Softwire : IPv4 edge over an IPv6-Only core 290 6to4 Softwire: IPv6 edge over an IPv4-Only core 292 E2E: End to End 294 4. IPv6-Only Edge Peering Architecture 296 4.1. Problem Statement 298 This specification addresses a real issue that has been discussed at 299 many operator groups around the world related to IXP major peering 300 points where hundreds of AS's have both IPv4 and IPv6 dual stacked 301 peering. IPv4 address depletion have been a major issue issue for 302 many years now. Operators around the world are clamoring for a 303 solution that can help solve issues related to IPv4 address depletion 304 at these large IXP peering points. With this solution IXPs as well 305 as all infrastructure networks such as Core networks, DC networks, 306 Access networks as well as any PE-CE public or private network can 307 now utilize this IPv6-Only Edge solution and reap the benefits 308 immediately on IPv4 address space saving. 310 IXP Problem Statement 312 Dual Stacked Dual Stacked 313 CE PE 315 +-------+ IPv4 BGP Peer +-------+ 316 | |---------------| | 317 | CE | IPv6 BGP Peer | PE | 318 | |---------------| | 319 +-------+ +-------+ 320 IPv4 forwarding IPv4 forwarding 321 IPv6 forwarding IPv6 forwarding 323 Figure 1: Problem Statement - IXP Dual Stack Peering 324 ________ 325 Dual Stacked _____ / \ Dual Stacked 326 PE / CE / \__/ \___ PE / CE 327 +----+ +----+ / \ +------+ +-----+ 328 | | | | |0====VPN Overlay Tunnel ==0| | | | | 329 | | | | | \ | | | | 330 | CE |--| PE |--\ IPv6-Only Core |----| PE |---| CE | 331 | | | | \0=========Underlay =======0| | | | | 332 +----+ +----+ \ __/ +------+ +-----+ 333 IPv4 IPv6 BGP peer \ IP / MPLS / SR domain / IPv4 and IPv6 BGP peer 334 IPv4 forwarding \__ __ / IPv4 forwarding 335 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 337 Figure 2: Problem Statement - E2E Dual Stack Edge 339 4.2. IPv6-Only PE-CE Design Solution 341 The IPv6-Only Edge design solution provides a means of E2E single 342 protocol design solution extension of [RFC5565] Softwire Mesh 343 framework from the PE-CE Edge to the Core from ingres so egress 344 through the entire operators domain. This solution eliminates all 345 IPv4 addressing from end to end while still providing the same Dual 346 Stack functionality of IPv4 and IPv6 packet forwarding from a data 347 plane perspective by leveraging the [RFC8950] extended next hop 348 encoding so that IPv4 NLRI can be advertised over a single IPv6 pure 349 transport TCP session. This IPv6-Only E2E architecture eliminates 350 all IPv4 peering and IPv4 addressing E2E from the ingress CE to 351 ingress PE to egress PE to egress CE and all hops along the operator 352 E2E path. 354 Solution applicable to 355 any Edge peering scenario - IXP, Core, DC, Access, etc 357 +-------+ +-------+ 358 | | IPv6 Only | | 359 | CE |----------------| PE | 360 | | IPv6 BGP Peer | | 361 +-------+ +-------+ 362 IPv4 forwarding IPv4 forwarding 363 IPv6 forwarding IPv6 forwarding 365 Figure 3: IPv6-Only Solution Applicability 366 ________ 367 IPv6-Only _____ / \ IPv6-Only 368 PE / CE / \__/ \___ PE / CE 369 +----+ +----+ / \ +------+ +-----+ 370 | | | | |0====VPN Overlay Tunnel ==0| | | | | 371 | | | | | \ | | | | 372 | CE |--| PE |--\ IPv6-Only Core |----| PE |---| CE | 373 | | | | \0=========Underlay ===== ==0 | | | | 374 +----+ +----+ \ __/ +------+ +-----+ 375 IPv6 BGP peer \IP / MPLS / SR domain / IPv6 BGP peer 376 IPv4 forwarding \__ __ / IPv4 forwarding 377 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 379 Figure 4: E2E VPN Solution 381 4.3. IPv6-Only Edge Peering Design 383 4.3.1. IPv6-Only Edge Peering Packet Walk 385 The IPv6-Only Edge Peering design utilizes two key E2E Softwire Mesh 386 Framework scenario's, 4to6 softwire and 6to4 softwire. The Softwire 387 mesh framework concept is based on the overlay and underlay MPLS or 388 SR based technology framework, where the underlay is the transport 389 layer and the overlay is a Virtual Private Network (VPN) layer, and 390 is the the tunneled virtualization layer containing the customer 391 payload. The concept of a 6to4 Softwire is based on transmission of 392 IPv6 packets at the edge of the network by tunneling the IPv6 packets 393 over an IPv4-Only Core. The concept of a 4to6 Softwire is also based 394 on transmission of IPv4 packets at the edge of the network by 395 tunneling the IPv4 packets over an IPv6-Only Core. 397 This document describes End to End (E2E) test scenarios that follow a 398 packet flow from IPv6-Only attachment circuit from ingress PE-CE to 399 egress PE-CE tracing the routing protocol control plane and data 400 plane forwarding of IPv4 packets in a 4to6 softwire or 6to4 softwire 401 within the IPv4-Only or IPv6-Only Core network. In both secneario we 402 are focusing on IPv4 packets and the control plane and data plane 403 forwarding aspects of IPv4 packets from the PE-CE Edge network over 404 an IPv6-Only P (Provider) core network or IPv4-Only P (Provider) core 405 network. With this IPv6-Only Edge peering design, the Softwire Mesh 406 Framework is not extended beyond the Provider Edge (PE) and continues 407 to terminate on the PE router. 409 4.3.2. 6to4 Softwire IPv4-Only Core packet walk 411 6to4 softwire where IPv6-Edge eBGP IPv6 peering where IPv4 packets at 412 network Edge traverse a IPv4-Only Core 414 In the scenario where IPv4 packets originating from a PE-CE edge are 415 tunneled over an MPLS or Segment Routing IPv4 underlay core network, 416 the PE and CE only have an IPv6 address configured on the interface. 417 In this scenario the IPv4 packets that ingress the CE from within the 418 CE AS are over an IPv6-Only interface and are forwarded to an IPv4 419 NLRI destination prefix learned from the Pure Transport Single IPv6 420 BGP Peer. In the IPv6-Only Edge peering architecture the PE is 421 IPv6-Only as all PE-CE interfaces are IPv6-Only. However, on the CE, 422 the PE-CE interface is the only interface that is IPv6-Only and all 423 other interfaces may or may not be IPv6-Only. Following the data 424 plane packet flow, IPv4 packets are forwarded from the ingress CE to 425 the IPv6-Only ingress PE where the VPN label imposition push per 426 prefix, per-vrf, per-CE occurs and the labeled packet is forwarded 427 over a 6to4 softwire IPv4-Only core, to the egress PE where the VPN 428 label disposition pop occurs and the native IPv4 packet is forwarded 429 to the egress CE. In the reverse direction IPv4 packets are 430 forwarded from the egress CE to egress PE where the VPN label 431 imposition per prefix, per-vrf, per-CE push occurs and the labeled 432 packet is forwarded back over the 6to4 softwire IPv4-Only core, to 433 the ingress PE where the VPN label disposition pop occurs and the 434 native IPv4 packet is forwarded to the ingress CE. . The 435 functionality of the IPv4 forwarding plane in this scenario is 436 identical from a data plane forwarding perspective to Dual Stack IPv4 437 forwarding scenario. 439 +--------+ +--------+ 440 | IPv4 | | IPv4 | 441 | Client | | Client | 442 | Network| | Network| 443 +--------+ +--------+ 444 | \ / | 445 | \ / | 446 | \ / | 447 | X | 448 | / \ | 449 | / \ | 450 | / \ | 451 +--------+ +--------+ 452 | AFBR | | AFBR | 453 +--| IPv4/6 |---| IPv4/6 |--+ 454 | +--------+ +--------+ | 455 +--------+ | | +--------+ 456 | IPv4 | | | | IPv4 | 457 | Client | | | | Client | 458 | Network|------| IPv4 |-------| Network| 459 +--------+ | only | +--------+ 460 | | 461 | +--------+ +--------+ | 462 +--| AFBR |---| AFBR |--+ 463 | IPv4/6 | | IPv4/6 | 464 +--------+ +--------+ 465 | \ / | 466 | \ / | 467 | \ / | 468 | X | 469 | / \ | 470 | / \ | 471 | / \ | 472 +--------+ +--------+ 473 | IPv6 | | IPv4 | 474 | Client | | Client | 475 | Network| | Network| 476 +--------+ +--------+ 478 Figure 5: 6to4 Softwire - IPv6 Edge over an IPv4-Only Core 480 4.3.3. 4to6 Softwire IPv6-Only Core packet walk 482 4to6 softwire where IPv6-Edge eBGP IPv6 peering where IPv4 packets at 483 network Edge traverse a IPv6-Only Core 484 In the scenario where IPv4 packets originating from a PE-CE edge are 485 tunneled over an MPLS or Segment Routing IPv4 underlay core network, 486 the PE and CE only have an IPv6 address configured on the interface. 487 In this scenario the IPv4 packets that ingress the CE from within the 488 CE AS are over an IPv6-Only interface and are forwarded to an IPv4 489 NLRI destination prefix learned from the Pure Transport Single IPv6 490 BGP Peer. In the IPv6-Only Edge peering architecture the PE is 491 IPv6-Only as all PE-CE interfaces are IPv6-Only. However, on the CE, 492 the PE-CE interface is the only interface that is IPv6-Only and all 493 other interfaces may or may not be IPv6-Only. Following the data 494 plane packet flow, IPv4 packets are forwarded from the ingress CE to 495 the IPv6-Only ingress PE where the VPN label imposition push per 496 prefix, per-vrf, per-CE occurs and the labeled packet is forwarded 497 over a 4to6 softwire IPv6-Only core, to the egress PE where the VPN 498 label disposition pop occurs and the native IPv4 packet is forwarded 499 to the egress CE. In the reverse direction IPv4 packets are 500 forwarded from the egress CE to egress PE where the VPN label 501 imposition per prefix, per-vrf, per-CE push occurs and the labeled 502 packet is forwarded back over the 4to6 softwire IPv6-Only core, to 503 the ingress PE where the VPN label disposition pop occurs and the 504 native IPv4 packet is forwarded to the ingress CE. . The 505 functionality of the IPv4 forwarding plane in this scenario is 506 identical from a data plane forwarding perspective to Dual Stack IPv4 507 forwarding scenario. 509 +--------+ +--------+ 510 | IPv4 | | IPv4 | 511 | Client | | Client | 512 | Network| | Network| 513 +--------+ +--------+ 514 | \ / | 515 | \ / | 516 | \ / | 517 | X | 518 | / \ | 519 | / \ | 520 | / \ | 521 +--------+ +--------+ 522 | AFBR | | AFBR | 523 +--| IPv4/6 |---| IPv4/6 |--+ 524 | +--------+ +--------+ | 525 +--------+ | | +--------+ 526 | IPv6 | | | | IPv6 | 527 | Client | | | | Client | 528 | Network|------| IPv6 |-------| Network| 529 +--------+ | only | +--------+ 530 | | 531 | +--------+ +--------+ | 532 +--| AFBR |---| AFBR |--+ 533 | IPv4/6 | | IPv4/6 | 534 +--------+ +--------+ 535 | \ / | 536 | \ / | 537 | \ / | 538 | X | 539 | / \ | 540 | / \ | 541 | / \ | 542 +--------+ +--------+ 543 | IPv4 | | IPv4 | 544 | Client | | Client | 545 | Network| | Network| 546 +--------+ +--------+ 548 Figure 6: 4to6 Softwire - IPv4 Edge over an IPv6-Only Core 550 4.4. RFC5549 and RFC8950 Applicability 551 4.4.1. IPv6-Only Edge Peering design next-hop encoding 553 This section describes [RFC8950] next hop encoding updates to 554 [RFC5549] applicability to this specification. IPv6-only eBGP Edge 555 PE-CE peering to carry IPv4 Unicast NLRI IPv4 <1/1> over 556 an IPv6 next hop BGP capability extended hop encoding IANA capability 557 codepoint value 5 defined is applicable to both [RFC5549] and 558 [RFC8950] as IPv4 Unicast NLRI IPv4 <1/1> does not change 559 in the RFC updates. 561 IPv4 packets over an IPv6-Only core 4to6 Softwire E2E packet flow is 562 part of the IPv6-Only design vendor interoperaiblity test cases and 563 in that respect is applicable as [RFC8950] updates [RFC5549] for 564 VPN-IPV4 <1/128>, and Multicasat VPN <1/129> 566 4.4.2. RFC8950 updates to RFC5549 applicability 568 This section describes the [RFC8950] next hop encoding updates to 569 [RFC5549] 571 In [RFC5549] when AFI/SAFI 1/128 is used, the next-hop address is 572 encoded as an IPv6 address with a length of 16 or 32 bytes. This 573 document modifies how the next-hop address is encoded to accommodate 574 all existing implementations and bring consistency with VPNv4oIPv4 575 and VPNv6oIPv6. The next-hop address is now encoded as a VPN-IPv6 576 address with a length of 24 or 48 bytes [RFC8950] (see Sections 3 and 577 6.2 of this document). This change addresses Erratum ID 5253 578 (Err5253). As all known and deployed implementations are 579 interoperable today and use the new proposed encoding, the change 580 does not break existing interoperability. Updates to [RFC8950] is 581 applicable to the IPv6-Only PE-CE edge design for the IPv6 next hop 582 encoding E2E test case of IPv4 packets over and IPv6-Only core 4to6 583 Softwire. In this test case IPv4 Unicast NLRI IPv4 <1/1> 584 is advertised over the PE to RR core peering 4to6 softwire in VPN-IPV4 <1/128>. In this test case label allocation mode 586 comes into play which is discussed in section 8.9. 588 [RFC5549] next hop encoding of MP_REACH_NLRI with: 590 * NLRI= NLRI as per current AFI/SAFI definition 592 Advertising with [RFC4760] MP_REACH_NLRI with: 594 * AFI = 1 596 * SAFI = 128 or 129 598 * Length of Next Hop Address = 16 or 32 599 * NLRI= NLRI as per current AFI/SAFI definition 601 [RFC8950] next hop encoding of MP_REACH_NLRI with: 603 * NLRI= NLRI as per current AFI/SAFI definition 605 Advertising with [RFC4760] MP_REACH_NLRI with: 607 * AFI = 1 609 * SAFI = 128 or 129 611 * Length of Next Hop Address = 24 or 48 613 * Next Hop Address = VPN-IPv6 address of next hop with an 8-octet RD 614 set to zero (potentially followed by the link-local VPN-IPv6 615 address of the next hop with an 8-octet RD is set to zero). 617 * NLRI= NLRI as per current AFI/SAFI definition 619 5. IPv6-Only PE Design Edge and Inter-AS Options E2E Test Cases 621 Proof of conept interoperability testing of the 4 test cases between 622 the 5 vendors Cisco, Juniper, Arista, Nokia and Huawei. 624 Cisco, Juniper, Arista, Nokia, Huawei, platform, code revision and 625 test results for all use cases 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 Tested on above Juniper platforms. Completed IPv6-Only PE design 640 functionality test with PE-CE IPv6 peer carrying IPv4 and IPv6 641 prefixes control plane validation and data plane forwarding plane 642 validation and verified end to end reachability CE to CE forwarding 643 plane with Default Per-CE label allocation mode. Tested with 644 IPv4-Only Core and IPv6-Only Core and proved that the IPv6-Only PE 645 design solution works. Both IPv4 and IPv6 packets were forwarded 646 identical functionality of Dual Stack without having IPv4 address 647 configured. 649 Nokia: Edge and Core-7750 Service Router, Release R21 651 Huawei: Edge and Core-VRPv8, Release VRP-V800R020C10 653 Arista: 655 Intra-AS tests PE-CE Edge Peering IPv4-Only Core, IPv6-Only Core, 656 Global Table (GRT) and IP VPN 658 AFI/SAFI IPv4-Unicast SAFI IPv6-Unicast SAFI 660 IPv4 Core: 662 Test-1 Global table (6PE) 664 Test-2 IP VPN 666 Global table IPv6 668 IPv6 Core: 670 Test-3 Global table 672 Test-4 IP VPN 674 Inter-AS Options tests IPv4-Only Core, IPv6-Only Core, Global 675 Table (GRT) and IP VPN 677 AFI/SAFI VPN and MVPN 679 IPv4-Only Core 681 Test-5 Global table 6PE Option-B (Segmented LSP stitched IPv4 Core - 682 Inter-AS Link IPv6-Only PE - IPv4 Core) 684 Test-6 Global table 6PE Option-C (Redistribute IPv4 Loopbacks into 685 BGP-LU AFI/SAFI 2/6) 686 Test-7 IP VPN Inter AS Option-B (Segmented LSP stitched IPv4 Core - 687 Inter-AS Link IPv6-Only PE - IPv4 Core) 689 Test-8 IP VPN Inter AS Option-C (Redistribute IPv4 Loopbacks into 690 BGP-LU AFI/SAFI 2/6) 692 IPv6-Only Core 694 Test-9 Global table Option-B 696 Test-10 Global table Option-C 698 Test-11 IP VPN Inter AS Option-B 700 Test-12 IP VPN Inter AS Option-C 702 5.1. Test-1 E2E IPv6-Only PE-CE, Global Table over IPv4-Only Core(6PE), 703 6to4 softwire 705 ________ 706 IPv6-Only _____ / \ IPv6-Only 707 PE / CE / \__/ \___ PE / CE 708 +----+ +----+ / \ +------+ +-----+ 709 | | | | | |_ | | | | 710 | | | | | \ | | | | 711 | CE |--| PE |--\ IPv4-Only Core |----| PE |---| CE | 712 | | | | \0=========Underlay =======0| | | | | 713 +----+ +----+ \ __/ +------+ +-----+ 714 IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer 715 IPv4 forwarding \__ __ / IPv4 forwarding 716 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 718 Figure 7: Test-1 E2E IPv6-Only PE-CE, Global Table over IPv4-Only 719 Core (6PE) 721 5.2. Test-2 E2E IPv6-Only PE-CE, VPN over IPv4-Only Core, 6to4 Softwire 722 ________ 723 IPv6-Only _____ / \ IPv6-Only 724 PE / CE / \__/ \___ PE / CE 725 +----+ +----+ / \ +------+ +-----+ 726 | | | | | 0====VPN Overlay Tunnel ==0| | | | | 727 | | | | | \ | | | | 728 | CE |--| PE |--\ IPv4-Only Core |----| PE |---| CE | 729 | | | | \0=========Underlay =======0| | | | | 730 +----+ +----+ \ __/ +------+ +-----+ 731 IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer 732 IPv4 forwarding \__ __ / IPv4 forwarding 733 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 735 Figure 8: Test-2 E2E IPv6-Only PE-CE, VPN over IPv4-Only Core 737 5.3. Test-3 E2E IPv6-Only PE-CE, Global Table over IPv6-Only Core, 4to6 738 Softwire 740 ________ 741 IPv6-Only _____ / \ IPv6-Only 742 PE / CE / \__/ \___ PE / CE 743 +----+ +----+ / \ +------+ +-----+ 744 | | | | | |_ | | | | 745 | | | | | \ | | | | 746 | CE |--| PE |--\ IPv6-Only Core |----| PE |---| CE | 747 | | | | \0=========Underlay =======0| | | | | 748 +----+ +----+ \ __/ +------+ +-----+ 749 IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer 750 IPv4 forwarding \__ __ / IPv4 forwarding 751 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 753 Figure 9: Test-3 E2E IPv6-Only PE-CE, Global Table over IPv6-Only 754 Core 756 5.4. Test-4 E2E IPv6-Only PE-CE, VPN over IPv6-Only Core, 4to6 Softwire 757 ________ 758 IPv6-Only _____ / \ IPv6-Only 759 PE / CE / \__/ \___ PE / CE 760 +----+ +----+ / \ +------+ +-----+ 761 | | | | | 0====VPN Overlay Tunnel ==0| | | | | 762 | | | | | \ | | | | 763 | CE |--| PE |--\ IPv6-Only Core |----| PE |---| CE | 764 | | | | \0=========Underlay =======0| | | | | 765 +----+ +----+ \ __/ +------+ +-----+ 766 IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer 767 IPv4 forwarding \__ __ / IPv4 forwarding 768 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 770 Figure 10: Test-4 E2E IPv6-Only PE-CE, VPN over IPv6-Only Core 772 5.5. Test-5 E2E IPv6-Only PE-CE, Global Table over IPv4-Only Core(6PE), 773 6to4 softwire -Inter-AS Option-B 775 Inter-AS ASBR-ASBR link is IPv6-Only PE 776 IPv6-Only __________ __________ IPv6-Only 777 PE / CE / \ / \ PE / CE 778 +--+ +----+ / \ / \ +--+ +--+ 779 | | | | | AS 1 \ | AS 2 \ | | | | 780 | | | | | \IPv6| \ | | | | 781 |CE|-| PE |--| IPv4-Only Core|----|IPv4-Only Core|--|PE|-|CE| 782 | | | | |0=Underlay==0 | |0==Underlay==0| | | | | 783 +--+ +----+ \ / \ / +--+ +--+ 784 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 785 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 786 IPv6 forwarding IPv6 forwarding 788 Figure 11: Test-5 E2E IPv6-Only PE-CE, Global Table over 789 IPv4-Only Core (6PE) - Inter-AS Option-B 791 5.6. Test-6 E2E IPv6-Only PE-CE, Global Table over IPv4-Only Core(6PE), 792 6to4 softwire -Inter-AS Option-C 793 Inter-AS ASBR-ASBR link is IPv6-Only PE 794 IPv6-Only __________ __________ IPv6-Only 795 PE / CE / \ / \ PE / CE 796 +--+ +----+ / \ / \ +--+ +--+ 797 | | | | | AS 1 \ | AS 2 \ | | | | 798 | | | | | \IPv6| \ | | | | 799 |CE|-| PE |--| IPv4-Only Core|----|IPv4-Only Core|--|PE|-|CE| 800 | | | | |0=Underlay==0 | |0==Underlay==0| | | | | 801 +--+ +----+ \ / \ / +--+ +--+ 802 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 803 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 804 IPv6 forwarding IPv6 forwarding 806 Figure 12: Test-6 E2E IPv6-Only PE-CE, Global Table over 807 IPv4-Only Core (6PE) - Inter-AS Option-C 809 5.7. Test-7 E2E IPv6-Only PE-CE, VPN over IPv4-Only, 6to4 softwire - 810 Inter-AS Option-B 812 Inter-AS ASBR-ASBR link is IPv6-Only PE 813 IPv6-Only __________ __________ IPv6-Only 814 PE / CE / \ / \ PE / CE 815 +--+ +----+ / \ / \ +--+ +--+ 816 | | | | | AS 1 \ | AS 2 \ | | | | 817 | | | | | \IPv6| \ | | | | 818 |CE|-| PE |--| IPv4-Only Core|----|IPv4-Only Core|--|PE|-|CE| 819 | | | | |0=Overlay===0 | |0==Overlay===0| | | | | 820 +--+ +----+ \ / \ / +--+ +--+ 821 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 822 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 823 IPv6 forwarding IPv6 forwarding 825 Figure 13: Test-7 E2E IPv6-Only PE-CE, VPN over IPv4-Only Core - 826 Inter-AS Option-B 828 5.8. Test-8 E2E IPv6-Only PE-CE, VPN over IPv4-Only Core, 6to4 softwire 829 -Inter-AS Option-C 830 Inter-AS ASBR-ASBR link is IPv6-Only PE 831 IPv6-Only __________ __________ IPv6-Only 832 PE / CE / \ / \ PE / CE 833 +--+ +----+ / \ / \ +--+ +--+ 834 | | | | | AS 1 \ | AS 2 \ | | | | 835 | | | | | \IPv6| \ | | | | 836 |CE|-| PE |--| IPv4-Only Core|----|IPv4-Only Core|--|PE|-|CE| 837 | | | | |0=Overlay===0 | |0==Overlay===0| | | | | 838 +--+ +----+ \ / \ / +--+ +--+ 839 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 840 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 841 IPv6 forwarding IPv6 forwarding 843 Figure 14: Test-8 E2E IPv6-Only PE-CE, VPN over IPv4-Only Core - 844 Inter-AS Option-C 846 5.9. Test-9 E2E IPv6-Only PE-CE, Global Table over IPv6-Only Core, 4to6 847 softwire -Inter-AS Option-B 849 Inter-AS ASBR-ASBR link is IPv6-Only PE 850 IPv6-Only __________ __________ IPv6-Only 851 PE / CE / \ / \ PE / CE 852 +--+ +----+ / \ / \ +--+ +--+ 853 | | | | | AS 1 \ | AS 2 \ | | | | 854 | | | | | \IPv6| \ | | | | 855 |CE|-| PE |--| IPv6-Only Core|----|IPv6-Only Core|--|PE|-|CE| 856 | | | | |0=Underlay==0 | |0==Underlay==0| | | | | 857 +--+ +----+ \ / \ / +--+ +--+ 858 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 859 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 860 IPv6 forwarding IPv6 forwarding 862 Figure 15: Test-9 E2E IPv6-Only PE-CE, Global Table over 863 IPv6-Only Core - Inter- AS Option-B 865 5.10. Test-10 E2E IPv6-Only PE-CE, Global Table over IPv6-Only Core, 866 4to6 softwire -Inter-AS Option-C 867 Inter-AS ASBR-ASBR link is IPv6-Only PE 868 IPv6-Only __________ __________ IPv6-Only 869 PE / CE / \ / \ PE / CE 870 +--+ +----+ / \ / \ +--+ +--+ 871 | | | | | AS 1 \ | AS 2 \ | | | | 872 | | | | | \IPv6| \ | | | | 873 |CE|-| PE |--| IPv6-Only Core|--- |IPv6-Only Core|--|PE|-|CE| 874 | | | | |0=Underlay==0 | |0==Underlay==0| | | | | 875 +--+ +----+ \ / \ / +--+ +--+ 876 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 877 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 878 IPv6 forwarding IPv6 forwarding 880 Figure 16: Test-10 E2E IPv6-Only PE-CE, Global Table over 881 IPv6-Only Core - Inter-AS Option-C 883 5.11. Test-11 E2E IPv6-Only PE-CE, VPN over IPv6-Only Core, 4to6 884 softwire -Inter-AS Option-B 886 Inter-AS ASBR-ASBR link is IPv6-Only PE 887 IPv6-Only __________ __________ IPv6-Only 888 PE / CE / \ / \ PE / CE 889 +--+ +----+ / \ / \ +--+ +--+ 890 | | | | | AS 1 \ | AS 2 \ | | | | 891 | | | | | \IPv6| \ | | | | 892 |CE|-| PE |--| IPv6-Only Core|--- |IPv6-Only Core|--|PE|-|CE| 893 | | | | |0=Overlay===0 | |0==Overlay===0| | | | | 894 +--+ +----+ \ / \ / +--+ +--+ 895 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 896 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 897 IPv6 forwarding IPv6 forwarding 899 Figure 17: Test-11 E2E IPv6-Only PE-CE, VPN over IPv6-Only Core - 900 Inter-AS Option-B 902 5.12. Test-12 E2E IPv6-Only PE-CE, VPN over IPv6-Only Core, 4to6 903 softwire -Inter-AS Option-C 904 Inter-AS ASBR-ASBR link is IPv6-Only PE 905 IPv6-Only __________ __________ IPv6-Only 906 PE / CE / \ / \ PE / CE 907 +--+ +----+ / \ / \ +--+ +--+ 908 | | | | | AS 1 \ | AS 2 \ | | | | 909 | | | | | \IPv6| \ | | | | 910 |CE|-| PE |--| IPv6-Only Core|--- |IPv6-Only Core|--|PE|-|CE| 911 | | | | |0=Overlay===0 | |0==Overlay===0| | | | | 912 +--+ +----+ \ / \ / +--+ +--+ 913 IPv6 BGP peer \ MPLS/SR / \ MPLS/SR / IPv6 BGP peer 914 IPv4 forwarding \_________/ \_________/ IPv4 forwarding 915 IPv6 forwarding IPv6 forwarding 917 Figure 18: Test-12 E2E IPv6-Only PE-CE, VPN over IPv6-Only Core - 918 Inter-AS Option-C 920 5.13. IPv6-Only PE-CE Operational Considerations Testing 922 Ping CE to PE when destination prefix is withdrawn 923 Traceroute CE to PE and test all ICMPv4 and ICMPv6 type codes 925 +-------+ +-------+ 926 | | IPv6 Only | | 927 | CE |----------------| PE | 928 | | IPv6 BGP Peer | | 929 +-------+ +-------+ 930 IPv4 forwarding IPv4 forwarding 931 IPv6 forwarding IPv6 forwarding 933 Figure 19: Ping and Trace Test Case 935 6. Operational Considerations 937 With a single IPv6 Peer carrying both IPv4 and IPv6 NLRI there are 938 some operational considerations in terms of what changes and what 939 does not change. 941 What does not change with a single IPv6 transport peer carrying IPv4 942 NLRI and IPv6 NLRI below: 944 Routing Policy configuration is still separate for IPv4 and IPv6 945 configured by capability as previously. 947 Layer 1, Layer 2 issues such as one-way fiber or fiber cut will 948 impact both IPv4 and IPv6 as previously. 950 If the interface is in the Admin Down state, the IPv6 peer would go 951 down, and IPv4 NLRI and IPv6 NLRI would be withdrawn as previously. 953 Changes resulting from a single IPv6 transport peer carrying IPv4 954 NLRI and IPv6 NLRI below: 956 Physical interface is no longer dual stacked. 958 Any change in IPv6 address or DAD state will impact both IPv4 and 959 IPv6 NLRI exchange. 961 Single BFD session for both IPv4 and IPv6 NLRI fate sharing as the 962 session is now tied to the transport, which now is only IPv6 address 963 family. 965 Both IPv4 and IPv6 peer now exists under the IPv6 address family 966 configuration. 968 Fate sharing of IPv4 and IPv6 address family from a logical 969 perspective now carried over a single physical IPv6 peer. 971 From an operations perspective, prior to elimination of IPv4 peers, 972 an audit is recommended to identify and IPv4 and IPv6 peering 973 incongruencies that may exist and to rectify them. No operational 974 impacts or issues are expected with this change. 976 With MPLS VPN overlay, per-CE next-hop label allcoation mode where 977 both IPv4 and IPv6 prefixes have the same label in no table lookup 978 pop-n-forward mode should be taken into consideration. 980 7. IANA Considerations 982 There are not any IANA considerations. 984 8. Security Considerations 986 The extensions defined in this document allow BGP to propagate 987 reachability information about IPv4 prefixes over an MPLS or SR 988 IPv6-Only core network. As such, no new security issues are raised 989 beyond those that already exist in BGP-4 and the use of MP-BGP for 990 IPv6. Both IPv4 and IPv6 peers exist under the IPv6 address family 991 configuration. The security features of BGP and corresponding 992 security policy defined in the ISP domain are applicable. For the 993 inter-AS distribution of IPv6 routes according to case (a) of 994 Section 4 of this document, no new security issues are raised beyond 995 those that already exist in the use of eBGP for IPv6 [RFC2545]. 997 9. Acknowledgments 999 Thanks to Kaliraj Vairavakkalai, Linda Dunbar, Aijun Wang, Eduardfor 1000 Vasilenko, Joel Harlpern, Michael McBride, Ketan Talaulikar for 1001 review comments. 1003 10. Contributors 1005 The following people contributed substantive text to this document: 1007 Mohana Sundari 1008 EMail: mohanas@juniper.net 1010 11. References 1012 11.1. Normative References 1014 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1015 Requirement Levels", BCP 14, RFC 2119, 1016 DOI 10.17487/RFC2119, March 1997, 1017 . 1019 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 1020 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 1021 DOI 10.17487/RFC2545, March 1999, 1022 . 1024 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1025 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1026 2006, . 1028 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1029 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1030 2006, . 1032 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1033 "Multiprotocol Extensions for BGP-4", RFC 4760, 1034 DOI 10.17487/RFC4760, January 2007, 1035 . 1037 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 1038 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 1039 2009, . 1041 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1042 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1043 May 2017, . 1045 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 1046 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 1047 . 1049 11.2. Informative References 1051 [I-D.ietf-idr-dynamic-cap] 1052 Chen, E. and S. R. Sangli, "Dynamic Capability for BGP-4", 1053 Work in Progress, Internet-Draft, draft-ietf-idr-dynamic- 1054 cap-16, 21 October 2021, . 1057 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 1058 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 1059 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 1060 . 1062 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 1063 R., Patel, K., and J. Guichard, "Constrained Route 1064 Distribution for Border Gateway Protocol/MultiProtocol 1065 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 1066 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 1067 November 2006, . 1069 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 1070 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 1071 Provider Edge Routers (6PE)", RFC 4798, 1072 DOI 10.17487/RFC4798, February 2007, 1073 . 1075 [RFC4925] Li, X., Ed., Dawkins, S., Ed., Ward, D., Ed., and A. 1076 Durand, Ed., "Softwire Problem Statement", RFC 4925, 1077 DOI 10.17487/RFC4925, July 2007, 1078 . 1080 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 1081 Layer Reachability Information with an IPv6 Next Hop", 1082 RFC 5549, DOI 10.17487/RFC5549, May 2009, 1083 . 1085 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 1086 Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, 1087 . 1089 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 1090 "Provisioning, Auto-Discovery, and Signaling in Layer 2 1091 Virtual Private Networks (L2VPNs)", RFC 6074, 1092 DOI 10.17487/RFC6074, January 2011, 1093 . 1095 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 1096 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 1097 2012, . 1099 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 1100 Encodings and Procedures for Multicast in MPLS/BGP IP 1101 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 1102 . 1104 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1105 Writing an IANA Considerations Section in RFCs", BCP 26, 1106 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1107 . 1109 [RFC8950] Litkowski, S., Agrawal, S., Ananthamurthy, K., and K. 1110 Patel, "Advertising IPv4 Network Layer Reachability 1111 Information (NLRI) with an IPv6 Next Hop", RFC 8950, 1112 DOI 10.17487/RFC8950, November 2020, 1113 . 1115 Authors' Addresses 1117 Gyan Mishra 1118 Verizon Inc. 1119 Email: gyan.s.mishra@verizon.com 1121 Mankamana Mishra 1122 Cisco Systems 1123 821 Alder Drive, 1124 MILPITAS 1125 Email: mankamis@cisco.com 1127 Jeff Tantsura 1128 Microsoft, Inc. 1129 Email: jefftant.ietf@gmail.com 1131 Sudha Madhavi 1132 Juniper Networks, Inc. 1133 Email: smadhavi@juniper.net 1134 Qing Yang 1135 Arista Networks 1136 Email: qyang@arista.com 1138 Adam Simpson 1139 Nokia 1140 Email: adam.1.simpson@nokia.com 1142 Shuanglong Chen 1143 Huawei Technologies 1144 Email: chenshuanglong@huawei.com