idnits 2.17.1 draft-ietf-bess-ipv6-only-pe-design-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. 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 (14 August 2021) is 985 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 869, but no explicit reference was found in the text == Unused Reference: 'RFC4364' is defined on line 873, but no explicit reference was found in the text == Unused Reference: 'RFC5492' is defined on line 882, but no explicit reference was found in the text == Unused Reference: 'RFC8277' is defined on line 890, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-dynamic-cap' is defined on line 896, but no explicit reference was found in the text == Unused Reference: 'RFC4659' is defined on line 902, but no explicit reference was found in the text == Unused Reference: 'RFC4684' is defined on line 907, but no explicit reference was found in the text == Unused Reference: 'RFC4798' is defined on line 914, but no explicit reference was found in the text == Unused Reference: 'RFC4925' is defined on line 920, but no explicit reference was found in the text == Unused Reference: 'RFC6074' is defined on line 934, but no explicit reference was found in the text == Unused Reference: 'RFC6513' is defined on line 940, but no explicit reference was found in the text == Unused Reference: 'RFC6514' is defined on line 944, but no explicit reference was found in the text == Unused Reference: 'RFC8126' is defined on line 949, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-idr-dynamic-cap-14 -- Obsolete informational reference (is this intentional?): RFC 5549 (Obsoleted by RFC 8950) Summary: 1 error (**), 0 flaws (~~), 16 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: 15 February 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 14 August 2021 18 IPv6-Only PE Design for IPv4-NLRI with IPv6-NH 19 draft-ietf-bess-ipv6-only-pe-design-00 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 31 IPv6-Only peering design that leverages the MP-BGP capability 32 exchange by using IPv6 peering as pure transport, allowing both IPv4 33 Network Layer Reachability Information (NLRI) and IPv6 Network Layer 34 Reachability Information (NLRI)to be carried over the same (Border 35 Gateway Protocol) BGP TCP session. The design change provides the 36 same Dual Stacking functionality that exists today with separate IPv4 37 and IPv6 BGP sessions as we have today. With this design change from 38 a control plane perspective a single IPv6 is required for both IPv4 39 and IPv6 routing updates and from a data plane forwarindg perspective 40 an IPv6 address need only be configured on the PE and CE interface 41 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 peering design to eliminate IPv4 provisioning at the Edge. This 47 core and edge IPv6-Only peering design paradigm change can apply to 48 any eBGP peering, public internet or private, which can be either 49 Core networks, Data Center networks, Access networks or can be any 50 eBGP peering scenario. This document provides vendor specific test 51 cases for the IPv6-Only peering design as well as test results for 52 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 15 February 2022. 86 Copyright Notice 88 Copyright (c) 2021 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 Simplified BSD License text 97 as described in Section 4.e of the Trust Legal Provisions and are 98 provided without warranty as described in the Simplified 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 . . . . . . . . . . . . . 6 106 4.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . 9 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 Design Edge E2E Test Cases . . . . . . . . . . . . 15 116 5.1. Test-1 E2E IPv6-Only PE-CE, Global Table over IPv4-Only 117 Core(6PE), 6to4 softwire . . . . . . . . . . . . . . . . 15 118 5.2. Test-2 E2E IPv6-Only PE-CE, VPN over IPv4-Only Core, 6to4 119 Softwire . . . . . . . . . . . . . . . . . . . . . . . . 16 120 5.3. Test-3 E2E IPv6-Only PE-CE, Global Table over IPv6-Only 121 Core (4PE), 4to6 Softwire . . . . . . . . . . . . . . . . 17 122 5.4. Test-4 E2E IPv6-Only PE-CE, VPN over IPv6-Only Core, 4to6 123 Softwire . . . . . . . . . . . . . . . . . . . . . . . . 18 124 5.5. IPv6-Only PE-CE Operational Considerations Testing . . . 19 125 6. Operational Considerations . . . . . . . . . . . . . . . . . 20 126 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 127 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 128 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 129 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 130 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 131 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 132 11.2. Informative References . . . . . . . . . . . . . . . . . 22 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 135 1. Introduction 137 As Enterprises and Service Providers upgrade their brown field or 138 green field MPLS/SR core to an IPv6 transport such as MPLS LDPv6, SR- 139 MPLSv6 or SRv6, Multiprotocol BGP (MP-BGP) now plays an important 140 role in the transition of the Provider (P) core networks and Provider 141 Edge (PE) edge networks from IPv4 to IPv6. Operators have a 142 requirement to support IPv4 customers and must be able to support 143 IPv4 address family and Sub-Address-Family Virtual Private Network 144 (VPN)-IPv4, and Multicast VPN IPv4 customers. 146 IXP are also facing IPv4 address depletion at their peering points, 147 which are large Layer 2 transit backbones that service providers peer 148 and exchange IPv4 and IPv6 Network Layer Reachability Information 149 (NLRI). Today, these transit exchange points are Dual Stacked. With 150 this IPv6-only BGP peering design, only IPv6 is configured on the PE- 151 CE interface, the Provider Edge (PE) - Customer Edge (CE), the IPv6 152 BGP peer is now used to carry IPv4 (Network Layer Reachability 153 Information) NLRI over an IPv6 next hop using IPv6 next hop encoding 154 defined in [RFC8950], while continuing to forward both IPv4 and IPv6 155 packets. In the framework of this design the PE is no longer Dual 156 Stacked. However in the case of the CE, PE-CE link CE side of the 157 link is no longer Dual Stacked, however all other internal links 158 within the CE domain may or maynot be Dual stacked. 160 MP-BGP specifies that the set of usable next-hop address families is 161 determined by the Address Family Identifier (AFI) and the Subsequent 162 Address Family Identifier (SAFI). Historically the AFI/SAFI 163 definitions for the IPv4 address family only have provisions for 164 advertising a Next Hop address that belongs to the IPv4 protocol when 165 advertising IPv4 or VPN-IPv4. [RFC8950] specifies the extensions 166 necessary to allow advertising IPv4 NLRI, Virtual Private Network 167 Unicast (VPN-IPv4) NLRI, Multicast Virtual Private Network (MVPN- 168 IPv4) NLRI with a Next Hop address that belongs to the IPv6 protocol. 169 This comprises of an extended next hop encoding MP-REACH BGP 170 capability exchange to allow the address of the Next Hop for IPv4 171 NLRI, VPN-IPv4 NLRI and MVPN-IPv4 NLRI to also belong to the IPv6 172 Protocol. [RFC8950] defines the encoding of the Next Hop to 173 determine which of the protocols the address actually belongs to, and 174 a new BGP Capability allowing MP-BGP Peers to discover dynamically 175 whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 176 Next Hop. 178 The current specification for carrying IPv4 NLRI of a given address 179 family via a Next Hop of a different address family is now defined in 180 [RFC8950], and specifies the extended next hop encoding MP-REACH 181 capability extension necessary to do so. This comprises an extension 182 of the AFI/SAFI definitions to allow the address of the Next Hop for 183 IPv4 NLRI or VPN-IPv4 NLRI to belong to either the IPv4 or the IPv6 184 protocol, the encoding of the Next Hop information to determine which 185 of the protocols the address belongs to, and a new BGP Capability 186 allowing MP-BGP peers to dynamically discover whether they can 187 exchange IPv4 NLRI and VPN- IPv4 NLRI with an IPv6 Next Hop. 189 With the new extensions defined in [RFC8950] supporting NLRI and next 190 hop address family mismatch, the BGP peer session can now be treated 191 as a pure TCP transport and carry both IPv4 and IPv6 NLRI at the 192 Provider Edge (PE) - Customer Edge (CE) over a single IPv6 TCP 193 session. This allows for the elimination of dual stack from the PE- 194 CE peering point, and now enable the peering to be IPv6-ONLY. The 195 elimination of IPv4 on the PE-CE peering points translates into OPEX 196 expenditure savings of point-to-point infrastructure links as well as 197 /31 address space savings and administration and network management 198 of both IPv4 and IPv6 BGP peers. This reduction decreases the number 199 of PE-CE BGP peers by fifty percent, which is a tremendous cost 200 savings for operators. 202 While the savings exists at the Edge eBGP PE-CE peering, on the core 203 side PE to Route Reflector (RR) peering carrying IPv4 204 <1/1>, VPN-IPV4 <1/128>, and Multicasat VPN <1/129>, there is no 205 savings as the Provider (P) Core is IPv6 Only and thus can only have 206 an IPv6 peer and must use [RFC8950] extended next hop encoding to 207 carrying IPv4 NLRI IPV4 <2/1>, VPN-IPV4 <2/128>, and Multicasat VPN 208 <2/129> over an IPv6 next hop. 210 This document provides a much needed solution for Internet Exchange 211 Point (IXP) that are facing IPv4 address depletion at large peering 212 points. With this design, IXP can now use deploy PE-CE IPv6-Only 213 eBGP Edge peering design to eliminate IPv4 provisioning at the Edge. 214 This core and edge IPv6-Only peering design paradigm change can apply 215 to any eBGP peering, public internet or private, which can be either 216 Core networks, Data Center networks, Access networks or can be any 217 eBGP peering scenario. This document provides detailed vendor 218 specific test cases and test results for the IPv6-Only peering design 219 as well as successful test results between five major vendors 220 stakeholders in the routing and switching indusrty, Cisco, Juniper, 221 Arista, Nokia and Huawei. With the test results provided for the 222 IPv6-Only Edge peering design, the goal is that all other vendors 223 around the world that have not been tested will begin to adopt and 224 implement this new best practice for eBGP IPv6-Only Edge peering. 226 As this issue with IXP address depletion is a critical issue around 227 the world, it is imperative for an immediate solution that can be 228 implemented quickly. This best practice IPv6-only eBGP peering 229 design specification will help proliferate IPv6-Only deployments at 230 the eBGP Edge network peering points starting immediately at a 231 minimum with operators around the world using Cisco, Juniper, Arista, 232 Nokia and Huawei. 234 2. Requirements Language 236 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 237 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 238 "OPTIONAL" in this document are to be interpreted as described in BCP 239 14 [RFC2119] [RFC8174] when, and only when, they appear in all 240 capitals, as shown here. 242 3. Terminology 244 Terminolgoy used in defining the IPv6-Only Edge specification. 246 AFBR: Address Family Border Router Provider Edge (PE). 248 Edge: PE-CE Edge Network Provider Edge - Customer Edge 250 Core: P Core Network Provider (P) 252 4to6 Softwire : IPv4 edge over an IPv6-Only core 254 6to4 Softwire: IPv6 edge over an IPv4-Only core 256 E2E: End to End 258 4. IPv6-Only Edge Peering Architecture 260 4.1. Problem Statement 262 This specification addresses a real issue that has been discussed at 263 many operator groups around the world related to IXP major peering 264 points where hundreds of AS's have both IPv4 and IPv6 dual stacked 265 peering. IPv4 address depletion have been a major issue issue for 266 many years now. Operators around the world are clamoring for a 267 solution that can help solve issues related to IPv4 address depletion 268 at these large IXP peering points. With this solution IXPs as well 269 as all infrastructure networks such as Core networks, DC networks, 270 Access networks as well as any PE-CE public or private network can 271 now utilize this IPv6-Only Edge solution and reap the benefits 272 immediately on IPv4 address space saving. 274 IXP Problem Statement 276 Dual Stacked Dual Stacked 277 CE PE 279 +-------+ IPv4 BGP Peer +-------+ 280 | |---------------| | 281 | CE | IPv6 BGP Peer | PE | 282 | |---------------| | 283 +-------+ +-------+ 284 IPv4 forwarding IPv4 forwarding 285 IPv6 forwarding IPv6 forwarding 287 Figure 1: Problem Statement - IXP Dual Stack Peering 289 ________ 290 Dual Stacked _____ / \ Dual Stacked 291 PE / CE / \__/ \___ PE / CE 292 +----+ +----+ / \ +------+ +-----+ 293 | | | | |0====VPN Overlay Tunnel ==0| | | | | 294 | | | | | \ | | | | 295 | CE |--| PE |--\ IPv6-Only Core |----| PE |---| CE | 296 | | | | \0=========Underlay =======0| | | | | 297 +----+ +----+ \ __/ +------+ +-----+ 298 IPv4 IPv6 BGP peer \ IP / MPLS / SR domain / IPv4 and IPv6 BGP peer 299 IPv4 forwarding \__ __ / IPv4 forwarding 300 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 302 Figure 2: Problem Statement - E2E Dual Stack Edge 304 4.2. IPv6-Only PE-CE Design Solution 306 The IPv6-Only Edge design solution provides a means of E2E single 307 protocol design solution extension of [RFC5565] Softwire Mesh 308 framework from the PE-CE Edge to the Core from ingres so egress 309 through the entire operators domain. This solution eliminates all 310 IPv4 addressing from end to end while still providing the same Dual 311 Stack functionality of IPv4 and IPv6 packet forwarding from a data 312 plane perspective by leveraging the [RFC8950] extended next hop 313 encoding so that IPv4 NLRI can be advertised over a single IPv6 pure 314 transport TCP session. This IPv6-Only E2E architecture eliminates 315 all IPv4 peering and IPv4 addressing E2E from the ingress CE to 316 ingress PE to egress PE to egress CE and all hops along the operator 317 E2E path. 319 Solution applicable to 320 any Edge peering scenario - IXP, Core, DC, Access, etc 322 +-------+ +-------+ 323 | | IPv6 Only | | 324 | CE |----------------| PE | 325 | | IPv6 BGP Peer | | 326 +-------+ +-------+ 327 IPv4 forwarding IPv4 forwarding 328 IPv6 forwarding IPv6 forwarding 330 Figure 3: IPv6-Only Solution Applicability 332 ________ 333 IPv6-Only _____ / \ IPv6-Only 334 PE / CE / \__/ \___ PE / CE 335 +----+ +----+ / \ +------+ +-----+ 336 | | | | |0====VPN Overlay Tunnel ==0| | | | | 337 | | | | | \ | | | | 338 | CE |--| PE |--\ IPv6-Only Core |----| PE |---| CE | 339 | | | | \0=========Underlay ===== ==0 | | | | 340 +----+ +----+ \ __/ +------+ +-----+ 341 IPv6 BGP peer \IP / MPLS / SR domain / IPv6 BGP peer 342 IPv4 forwarding \__ __ / IPv4 forwarding 343 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 345 Figure 4: E2E VPN Solution 347 4.3. IPv6-Only Edge Peering Design 349 4.3.1. IPv6-Only Edge Peering Packet Walk 351 The IPv6-Only Edge Peering design utilizes two key E2E Softwire Mesh 352 Framework scenario's, 4to6 softwire and 6to4 softwire. The Softwire 353 mesh framework concept is based on the overlay and underlay MPLS or 354 SR based technology framework, where the underlay is the transport 355 layer and the overlay is a Virtual Private Network (VPN) layer, and 356 is the the tunneled virtualization layer containing the customer 357 payload. The concept of a 6to4 Softwire is based on transmission of 358 IPv6 packets at the edge of the network by tunneling the IPv6 packets 359 over an IPv4-Only Core. The concept of a 4to6 Softwire is also based 360 on transmission of IPv4 packets at the edge of the network by 361 tunneling the IPv4 packets over an IPv6-Only Core. 363 This document describes End to End (E2E) test scenarios that follow a 364 packet flow from IPv6-Only attachment circuit from ingress PE-CE to 365 egress PE-CE tracing the routing protocol control plane and data 366 plane forwarding of IPv4 packets in a 4to6 softwire or 6to4 softwire 367 within the IPv4-Only or IPv6-Only Core network. In both secneario we 368 are focusing on IPv4 packets and the control plane and data plane 369 forwarding aspects of IPv4 packets from the PE-CE Edge network over 370 an IPv6-Only P (Provider) core network or IPv4-Only P (Provider) core 371 network. With this IPv6-Only Edge peering design, the Softwire Mesh 372 Framework is not extended beyond the Provider Edge (PE) and continues 373 to terminate on the PE router. 375 4.3.2. 6to4 Softwire IPv4-Only Core packet walk 377 6to4 softwire where IPv6-Edge eBGP IPv6 peering where IPv4 packets at 378 network Edge traverse a IPv4-Only Core 380 In the scenario where IPv4 packets originating from a PE-CE edge are 381 tunneled over an MPLS or Segment Routing IPv4 underlay core network, 382 the PE and CE only have an IPv6 address configured on the interface. 383 In this scenario the IPv4 packets that ingress the CE from within the 384 CE AS are over an IPv6-Only interface and are forwarded to an IPv4 385 NLRI destination prefix learned from the Pure Transport Single IPv6 386 BGP Peer. In the IPv6-Only Edge peering architecture the PE is 387 IPv6-Only as all PE-CE interfaces are IPv6-Only. However, on the CE, 388 the PE-CE interface is the only interface that is IPv6-Only and all 389 other interfaces may or may not be IPv6-Only. Following the data 390 plane packet flow, IPv4 packets are forwarded from the ingress CE to 391 the IPv6-Only ingress PE where the VPN label imposition push per 392 prefix, per-vrf, per-CE occurs and the labeled packet is forwarded 393 over a 6to4 softwire IPv4-Only core, to the egress PE where the VPN 394 label disposition pop occurs and the native IPv4 packet is forwarded 395 to the egress CE. In the reverse direction IPv4 packets are 396 forwarded from the egress CE to egress PE where the VPN label 397 imposition per prefix, per-vrf, per-CE push occurs and the labeled 398 packet is forwarded back over the 6to4 softwire IPv4-Only core, to 399 the ingress PE where the VPN label disposition pop occurs and the 400 native IPv4 packet is forwarded to the ingress CE. . The 401 functionality of the IPv4 forwarding plane in this scenario is 402 identical from a data plane forwarding perspective to Dual Stack IPv4 403 forwarding scenario. 405 +--------+ +--------+ 406 | IPv4 | | IPv4 | 407 | Client | | Client | 408 | Network| | Network| 409 +--------+ +--------+ 410 | \ / | 411 | \ / | 412 | \ / | 413 | X | 414 | / \ | 415 | / \ | 416 | / \ | 417 +--------+ +--------+ 418 | AFBR | | AFBR | 419 +--| IPv4/6 |---| IPv4/6 |--+ 420 | +--------+ +--------+ | 421 +--------+ | | +--------+ 422 | IPv4 | | | | IPv4 | 423 | Client | | | | Client | 424 | Network|------| IPv4 |-------| Network| 425 +--------+ | only | +--------+ 426 | | 427 | +--------+ +--------+ | 428 +--| AFBR |---| AFBR |--+ 429 | IPv4/6 | | IPv4/6 | 430 +--------+ +--------+ 431 | \ / | 432 | \ / | 433 | \ / | 434 | X | 435 | / \ | 436 | / \ | 437 | / \ | 438 +--------+ +--------+ 439 | IPv6 | | IPv4 | 440 | Client | | Client | 441 | Network| | Network| 442 +--------+ +--------+ 444 Figure 5: 6to4 Softwire - IPv6 Edge over an IPv4-Only Core 446 4.3.3. 4to6 Softwire IPv6-Only Core packet walk 448 4to6 softwire where IPv6-Edge eBGP IPv6 peering where IPv4 packets at 449 network Edge traverse a IPv6-Only Core 450 In the scenario where IPv4 packets originating from a PE-CE edge are 451 tunneled over an MPLS or Segment Routing IPv4 underlay core network, 452 the PE and CE only have an IPv6 address configured on the interface. 453 In this scenario the IPv4 packets that ingress the CE from within the 454 CE AS are over an IPv6-Only interface and are forwarded to an IPv4 455 NLRI destination prefix learned from the Pure Transport Single IPv6 456 BGP Peer. In the IPv6-Only Edge peering architecture the PE is 457 IPv6-Only as all PE-CE interfaces are IPv6-Only. However, on the CE, 458 the PE-CE interface is the only interface that is IPv6-Only and all 459 other interfaces may or may not be IPv6-Only. Following the data 460 plane packet flow, IPv4 packets are forwarded from the ingress CE to 461 the IPv6-Only ingress PE where the VPN label imposition push per 462 prefix, per-vrf, per-CE occurs and the labeled packet is forwarded 463 over a 4to6 softwire IPv6-Only core, to the egress PE where the VPN 464 label disposition pop occurs and the native IPv4 packet is forwarded 465 to the egress CE. In the reverse direction IPv4 packets are 466 forwarded from the egress CE to egress PE where the VPN label 467 imposition per prefix, per-vrf, per-CE push occurs and the labeled 468 packet is forwarded back over the 4to6 softwire IPv6-Only core, to 469 the ingress PE where the VPN label disposition pop occurs and the 470 native IPv4 packet is forwarded to the ingress CE. . The 471 functionality of the IPv4 forwarding plane in this scenario is 472 identical from a data plane forwarding perspective to Dual Stack IPv4 473 forwarding scenario. 475 +--------+ +--------+ 476 | IPv4 | | IPv4 | 477 | Client | | Client | 478 | Network| | Network| 479 +--------+ +--------+ 480 | \ / | 481 | \ / | 482 | \ / | 483 | X | 484 | / \ | 485 | / \ | 486 | / \ | 487 +--------+ +--------+ 488 | AFBR | | AFBR | 489 +--| IPv4/6 |---| IPv4/6 |--+ 490 | +--------+ +--------+ | 491 +--------+ | | +--------+ 492 | IPv6 | | | | IPv6 | 493 | Client | | | | Client | 494 | Network|------| IPv6 |-------| Network| 495 +--------+ | only | +--------+ 496 | | 497 | +--------+ +--------+ | 498 +--| AFBR |---| AFBR |--+ 499 | IPv4/6 | | IPv4/6 | 500 +--------+ +--------+ 501 | \ / | 502 | \ / | 503 | \ / | 504 | X | 505 | / \ | 506 | / \ | 507 | / \ | 508 +--------+ +--------+ 509 | IPv4 | | IPv4 | 510 | Client | | Client | 511 | Network| | Network| 512 +--------+ +--------+ 514 Figure 6: 4to6 Softwire - IPv4 Edge over an IPv6-Only Core 516 4.4. RFC5549 and RFC8950 Applicability 517 4.4.1. IPv6-Only Edge Peering design next-hop encoding 519 This section describes [RFC8950] next hop encoding updates to 520 [RFC5549] applicability to this specification. IPv6-only eBGP Edge 521 PE-CE peering to carry IPv4 Unicast NLRI IPv4 <1/1> over 522 an IPv6 next hop BGP capability extended hop encoding IANA capability 523 codepoint value 5 defined is applicable to both [RFC5549] and 524 [RFC8950] as IPv4 Unicast NLRI IPv4 <1/1> does not change 525 in the RFC updates. 527 IPv4 packets over an IPv6-Only core 4to6 Softwire E2E packet flow is 528 part of the IPv6-Only design vendor interoperaiblity test cases and 529 in that respect is applicable as [RFC8950] updates [RFC5549] for 530 VPN-IPV4 <1/128>, and Multicasat VPN <1/129> 532 4.4.2. RFC8950 updates to RFC5549 applicability 534 This section describes the [RFC8950] next hop encoding updates to 535 [RFC5549] 537 In [RFC5549] when AFI/SAFI 1/128 is used, the next-hop address is 538 encoded as an IPv6 address with a length of 16 or 32 bytes. This 539 document modifies how the next-hop address is encoded to accommodate 540 all existing implementations and bring consistency with VPNv4oIPv4 541 and VPNv6oIPv6. The next-hop address is now encoded as a VPN-IPv6 542 address with a length of 24 or 48 bytes [RFC8950] (see Sections 3 and 543 6.2 of this document). This change addresses Erratum ID 5253 544 (Err5253). As all known and deployed implementations are 545 interoperable today and use the new proposed encoding, the change 546 does not break existing interoperability. Updates to [RFC8950] is 547 applicable to the IPv6-Only PE-CE edge design for the IPv6 next hop 548 encoding E2E test case of IPv4 packets over and IPv6-Only core 4to6 549 Softwire. In this test case IPv4 Unicast NLRI IPv4 <1/1> 550 is advertised over the PE to RR core peering 4to6 softwire in VPN-IPV4 <1/128>. In this test case label allocation mode 552 comes into play which is discussed in section 8.9. 554 [RFC5549] next hop encoding of MP_REACH_NLRI with: 556 * NLRI= NLRI as per current AFI/SAFI definition 558 Advertising with [RFC4760] MP_REACH_NLRI with: 560 * AFI = 1 562 * SAFI = 128 or 129 564 * Length of Next Hop Address = 16 or 32 565 * NLRI= NLRI as per current AFI/SAFI definition 567 [RFC8950] next hop encoding of MP_REACH_NLRI with: 569 * NLRI= NLRI as per current AFI/SAFI definition 571 Advertising with [RFC4760] MP_REACH_NLRI with: 573 * AFI = 1 575 * SAFI = 128 or 129 577 * Length of Next Hop Address = 24 or 48 579 * Next Hop Address = VPN-IPv6 address of next hop with an 8-octet RD 580 set to zero (potentially followed by the link-local VPN-IPv6 581 address of the next hop with an 8-octet RD is set to zero). 583 * NLRI= NLRI as per current AFI/SAFI definition 585 5. IPv6-Only Design Edge E2E Test Cases 587 Proof of conept interoperability testing of the 4 test cases between 588 the 5 vendors Cisco, Juniper, Arista, Nokia and Huawei. 590 5.1. Test-1 E2E IPv6-Only PE-CE, Global Table over IPv4-Only Core(6PE), 591 6to4 softwire 593 ________ 594 IPv6-Only _____ / \ IPv6-Only 595 PE / CE / \__/ \___ PE / CE 596 +----+ +----+ / \ +------+ +-----+ 597 | | | | | |_ | | | | 598 | | | | | \ | | | | 599 | CE |--| PE |--\ IPv4-Only Core |----| PE |---| CE | 600 | | | | \0=========Underlay =======0| | | | | 601 +----+ +----+ \ __/ +------+ +-----+ 602 IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer 603 IPv4 forwarding \__ __ / IPv4 forwarding 604 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 606 Figure 7: Test-1 E2E IPv6-Only PE-CE, Global Table over IPv4-Only 607 Core (6PE) 609 Cisco, Juniper, Arista, Nokia, Huawei code and platform and test 610 results. 612 Cisco: Edge Router- XR ASR 9910 IOS XR 7.4.1, Core Router- NCS 6000 613 7.2.2, CRS-X 6.7.4 615 Juniper: Edge Router- MX platform MX480, MX960, Core Router- PTX 616 Platform PTX5000, PTC10K8 (JUNOS and EVO) Release 20.4R2 618 Tested v4 edge over v6 core in a virtual setup using vMX platforrm 619 and 20.4R2 and LDPv6 as underlay, but there were some data plane 620 forwarding issues. Tested same setup on latest release 21.4 and it 621 worked. Investigating what the minimum version is for this setup to 622 work. 624 Arista: 626 Nokia: Edge and Core-7750 Service Router, Release R21 628 Huawei: Edge and Core-VRPv8, Release VRP-V800R020C10 630 5.2. Test-2 E2E IPv6-Only PE-CE, VPN over IPv4-Only Core, 6to4 Softwire 632 ________ 633 IPv6-Only _____ / \ IPv6-Only 634 PE / CE / \__/ \___ PE / CE 635 +----+ +----+ / \ +------+ +-----+ 636 | | | | | 0====VPN Overlay Tunnel ==0| | | | | 637 | | | | | \ | | | | 638 | CE |--| PE |--\ IPv4-Only Core |----| PE |---| CE | 639 | | | | \0=========Underlay =======0| | | | | 640 +----+ +----+ \ __/ +------+ +-----+ 641 IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer 642 IPv4 forwarding \__ __ / IPv4 forwarding 643 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 645 Figure 8: Test-2 E2E IPv6-Only PE-CE, VPN over IPv4-Only Core 647 Cisco, Juniper, Arista, Nokia, Huawei code and platform and test 648 results. 650 Cisco: Edge Router- XR ASR 9910 IOS XR 7.4.1, Core Router- NCS 6000 651 7.2.2, CRS-X 6.7.4 652 Juniper: Edge Router- MX platform MX480, MX960, Core Router- PTX 653 Platform PTX5000, PTC10K8 (JUNOS and EVO) Release 20.4R2 655 Tested v4 edge over v6 core in a virtual setup using vMX platforrm 656 and 20.4R2 and LDPv6 as underlay, but there were some data plane 657 forwarding issues. Tested same setup on latest release 21.4 and it 658 worked. Investigating what the minimum version is for this setup to 659 work. 661 Arista: 663 Nokia: Edge and Core-7750 Service Router, Release R21 665 Huawei: Edge and Core-VRPv8, Release VRP-V800R020C10 667 5.3. Test-3 E2E IPv6-Only PE-CE, Global Table over IPv6-Only Core 668 (4PE), 4to6 Softwire 670 ________ 671 IPv6-Only _____ / \ IPv6-Only 672 PE / CE / \__/ \___ PE / CE 673 +----+ +----+ / \ +------+ +-----+ 674 | | | | | |_ | | | | 675 | | | | | \ | | | | 676 | CE |--| PE |--\ IPv6-Only Core |----| PE |---| CE | 677 | | | | \0=========Underlay =======0| | | | | 678 +----+ +----+ \ __/ +------+ +-----+ 679 IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer 680 IPv4 forwarding \__ __ / IPv4 forwarding 681 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 683 Figure 9: Test-3 E2E IPv6-Only PE-CE, Global Table over IPv6-Only 684 Core (4PE) 686 Cisco, Juniper, Arista, Nokia, Huawei code and platform and test 687 results. 689 Cisco: Edge Router- XR ASR 9910 IOS XR 7.4.1, Core Router- NCS 6000 690 7.2.2, CRS-X 6.7.4 692 Juniper: Edge Router- MX platform MX480, MX960, Core Router- PTX 693 Platform PTX5000, PTC10K8 (JUNOS and EVO) Release 20.4R2 694 Tested v4 edge over v6 core in a virtual setup using vMX platforrm 695 and 20.4R2 and LDPv6 as underlay, but there were some data plane 696 forwarding issues. Tested same setup on latest release 21.4 and it 697 worked. Investigating what the minimum version is for this setup to 698 work. 700 Arista: 702 Nokia: Edge and Core-7750 Service Router, Release R21 704 Huawei: Edge and Core-VRPv8, Release VRP-V800R020C10 706 5.4. Test-4 E2E IPv6-Only PE-CE, VPN over IPv6-Only Core, 4to6 Softwire 708 ________ 709 IPv6-Only _____ / \ IPv6-Only 710 PE / CE / \__/ \___ PE / CE 711 +----+ +----+ / \ +------+ +-----+ 712 | | | | | 0====VPN Overlay Tunnel ==0| | | | | 713 | | | | | \ | | | | 714 | CE |--| PE |--\ IPv6-Only Core |----| PE |---| CE | 715 | | | | \0=========Underlay =======0| | | | | 716 +----+ +----+ \ __/ +------+ +-----+ 717 IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer 718 IPv4 forwarding \__ __ / IPv4 forwarding 719 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 721 Figure 10: Test-4 E2E IPv6-Only PE-CE, VPN over IPv6-Only Core 723 Cisco, Juniper, Arista, Nokia, Huawei code and platform and test 724 results. 726 Cisco: Edge Router- XR ASR 9910 IOS XR 7.4.1, Core Router- NCS 6000 727 7.2.2, CRS-X 6.7.4 729 Juniper: Edge Router- MX platform MX480, MX960, Core Router- PTX 730 Platform PTX5000, PTC10K8 (JUNOS and EVO) Release 20.4R2 732 Tested v4 edge over v6 core in a virtual setup using vMX platforrm 733 and 20.4R2 and LDPv6 as underlay, but there were some data plane 734 forwarding issues. Tested same setup on latest release 21.4 and it 735 worked. Investigating what the minimum version is for this setup to 736 work. 738 Arista: 740 Nokia: Edge and Core-7750 Service Router, Release R21 742 Huawei: Edge and Core-VRPv8, Release VRP-V800R020C10 744 5.5. IPv6-Only PE-CE Operational Considerations Testing 746 Ping CE to PE when destination prefix is withdrawn 747 Traceroute CE to PE and test all ICMPv4 and ICMPv6 type codes 749 +-------+ +-------+ 750 | | IPv6 Only | | 751 | CE |----------------| PE | 752 | | IPv6 BGP Peer | | 753 +-------+ +-------+ 754 IPv4 forwarding IPv4 forwarding 755 IPv6 forwarding IPv6 forwarding 757 Figure 11: Ping and Trace Test Case 759 Cisco, Juniper, Arista, Nokia, Huawei code and platform and test 760 results. 762 Cisco: Edge Router- XR ASR 9910 IOS XR 7.4.1, Core Router- NCS 6000 763 7.2.2, CRS-X 6.7.4 765 Juniper: Edge Router- MX platform MX480, MX960, Core Router- PTX 766 Platform PTX5000, PTC10K8 (JUNOS and EVO) Release 20.4R2 768 Tested v4 edge over v6 core in a virtual setup using vMX platforrm 769 and 20.4R2 and LDPv6 as underlay, but there were some data plane 770 forwarding issues. Tested same setup on latest release 21.4 and it 771 worked. Investigating what the minimum version is for this setup to 772 work. 774 Arista: 776 Nokia: Edge and Core-7750 Service Router, Release R21 778 Huawei: Edge and Core-VRPv8, Release VRP-V800R020C10 780 6. Operational Considerations 782 With a single IPv6 Peer carrying both IPv4 and IPv6 NLRI there are 783 some operational considerations in terms of what changes and what 784 does not change. 786 What does not change with a single IPv6 transport peer carrying IPv4 787 NLRI and IPv6 NLRI below: 789 Routing Policy configuration is still separate for IPv4 and IPv6 790 configured by capability as previously. 792 Layer 1, Layer 2 issues such as one-way fiber or fiber cut will 793 impact both IPv4 and IPv6 as previously. 795 If the interface is in the Admin Down state, the IPv6 peer would go 796 down, and IPv4 NLRI and IPv6 NLRI would be withdrawn as previously. 798 Changes resulting from a single IPv6 transport peer carrying IPv4 799 NLRI and IPv6 NLRI below: 801 Physical interface is no longer dual stacked. 803 Any change in IPv6 address or DAD state will impact both IPv4 and 804 IPv6 NLRI exchange. 806 Single BFD session for both IPv4 and IPv6 NLRI fate sharing as the 807 session is now tied to the transport, which now is only IPv6 address 808 family. 810 Both IPv4 and IPv6 peer now exists under the IPv6 address family 811 configuration. 813 Fate sharing of IPv4 and IPv6 address family from a logical 814 perspective now carried over a single physical IPv6 peer. 816 From an operations perspective, prior to elimination of IPv4 peers, 817 an audit is recommended to identify and IPv4 and IPv6 peering 818 incongruencies that may exist and to rectify them. No operational 819 impacts or issues are expected with this change. 821 With MPLS VPN overlay, per-CE next-hop label allcoation mode where 822 both IPv4 and IPv6 prefixes have the same label in no table lookup 823 pop-n-forward mode should be taken into consideration. 825 7. IANA Considerations 827 There are not any IANA considerations. 829 8. Security Considerations 831 The extensions defined in this document allow BGP to propagate 832 reachability information about IPv4 prefixes over an MPLS or SR 833 IPv6-Only core network. As such, no new security issues are raised 834 beyond those that already exist in BGP-4 and the use of MP-BGP for 835 IPv6. Both IPv4 and IPv6 peers exist under the IPv6 address family 836 configuration. The security features of BGP and corresponding 837 security policy defined in the ISP domain are applicable. For the 838 inter-AS distribution of IPv6 routes according to case (a) of 839 Section 4 of this document, no new security issues are raised beyond 840 those that already exist in the use of eBGP for IPv6 [RFC2545]. 842 9. Acknowledgments 844 Thanks to Kaliraj Vairavakkalai, Linda Dunbar, Aijun Wang, Eduardfor 845 Vasilenko, Joel Harlpern, Michael McBride, Ketan Talaulikar for 846 review comments. 848 10. Contributors 850 The following people contributed substantive text to this document: 852 Mohana Sundari 853 EMail: mohanas@juniper.net 855 11. References 857 11.1. Normative References 859 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 860 Requirement Levels", BCP 14, RFC 2119, 861 DOI 10.17487/RFC2119, March 1997, 862 . 864 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 865 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 866 DOI 10.17487/RFC2545, March 1999, 867 . 869 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 870 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 871 2006, . 873 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 874 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 875 2006, . 877 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 878 "Multiprotocol Extensions for BGP-4", RFC 4760, 879 DOI 10.17487/RFC4760, January 2007, 880 . 882 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 883 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 884 2009, . 886 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 887 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 888 May 2017, . 890 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 891 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 892 . 894 11.2. Informative References 896 [I-D.ietf-idr-dynamic-cap] 897 Chen, E. and S. R. Sangli, "Dynamic Capability for BGP-4", 898 Work in Progress, Internet-Draft, draft-ietf-idr-dynamic- 899 cap-14, 5 December 2011, . 902 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 903 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 904 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 905 . 907 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 908 R., Patel, K., and J. Guichard, "Constrained Route 909 Distribution for Border Gateway Protocol/MultiProtocol 910 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 911 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 912 November 2006, . 914 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 915 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 916 Provider Edge Routers (6PE)", RFC 4798, 917 DOI 10.17487/RFC4798, February 2007, 918 . 920 [RFC4925] Li, X., Ed., Dawkins, S., Ed., Ward, D., Ed., and A. 921 Durand, Ed., "Softwire Problem Statement", RFC 4925, 922 DOI 10.17487/RFC4925, July 2007, 923 . 925 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 926 Layer Reachability Information with an IPv6 Next Hop", 927 RFC 5549, DOI 10.17487/RFC5549, May 2009, 928 . 930 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 931 Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, 932 . 934 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 935 "Provisioning, Auto-Discovery, and Signaling in Layer 2 936 Virtual Private Networks (L2VPNs)", RFC 6074, 937 DOI 10.17487/RFC6074, January 2011, 938 . 940 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 941 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 942 2012, . 944 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 945 Encodings and Procedures for Multicast in MPLS/BGP IP 946 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 947 . 949 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 950 Writing an IANA Considerations Section in RFCs", BCP 26, 951 RFC 8126, DOI 10.17487/RFC8126, June 2017, 952 . 954 [RFC8950] Litkowski, S., Agrawal, S., Ananthamurthy, K., and K. 955 Patel, "Advertising IPv4 Network Layer Reachability 956 Information (NLRI) with an IPv6 Next Hop", RFC 8950, 957 DOI 10.17487/RFC8950, November 2020, 958 . 960 Authors' Addresses 962 Gyan Mishra 963 Verizon Inc. 965 Email: gyan.s.mishra@verizon.com 966 Mankamana Mishra 967 Cisco Systems 968 821 Alder Drive, 969 MILPITAS 971 Email: mankamis@cisco.com 973 Jeff Tantsura 974 Microsoft, Inc. 976 Email: jefftant.ietf@gmail.com 978 Sudha Madhavi 979 Juniper Networks, Inc. 981 Email: smadhavi@juniper.net 983 Qing Yang 984 Arista Networks 986 Email: qyang@arista.com 988 Adam Simpson 989 Nokia 991 Email: adam.1.simpson@nokia.com 993 Shuanglong Chen 994 Huawei Technologies 996 Email: chenshuanglong@huawei.com