idnits 2.17.1 draft-ietf-bess-deployment-guide-ipv4nlri-ipv6nh-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 12 characters in excess of 72. 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 (May 6, 2021) is 1078 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 764, but no explicit reference was found in the text == Unused Reference: 'RFC4364' is defined on line 768, but no explicit reference was found in the text == Unused Reference: 'RFC5492' is defined on line 777, but no explicit reference was found in the text == Unused Reference: 'RFC8277' is defined on line 785, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-dynamic-cap' is defined on line 791, but no explicit reference was found in the text == Unused Reference: 'RFC4659' is defined on line 796, but no explicit reference was found in the text == Unused Reference: 'RFC4684' is defined on line 801, but no explicit reference was found in the text == Unused Reference: 'RFC4798' is defined on line 808, but no explicit reference was found in the text == Unused Reference: 'RFC4925' is defined on line 814, but no explicit reference was found in the text == Unused Reference: 'RFC6074' is defined on line 828, but no explicit reference was found in the text == Unused Reference: 'RFC6513' is defined on line 834, but no explicit reference was found in the text == Unused Reference: 'RFC6514' is defined on line 838, but no explicit reference was found in the text == Unused Reference: 'RFC8126' is defined on line 843, 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: November 7, 2021 Cisco Systems 6 J. Tantsura 7 L. Wang 8 Juniper Networks, Inc. 9 Q. Yang 10 Arista Networks 11 A. Simpson 12 Nokia 13 S. Chen 14 Huawei Technologies 15 May 6, 2021 17 Deployment Guidelines for Edge Peering IPv4-NLRI with IPv6-NH 18 draft-ietf-bess-deployment-guide-ipv4nlri-ipv6nh-00 20 Abstract 22 As Enterprises and Service Providers upgrade their brown field or 23 green field MPLS/SR core to an IPv6 transport, Multiprotocol BGP (MP- 24 BGP)now plays an important role in the transition of their Provider 25 (P) core network as well as Provider Edge (PE) Edge network from IPv4 26 to IPv6. Operators must be able to continue to support IPv4 27 customers when both the Core and Edge networks are IPv6-Only. 29 This document details an important External BGP (eBGP) PE-CE Edge 30 IPv6-Only peering design that leverages the MP-BGP capability 31 exchange by using IPv6 peering as pure transport, allowing both IPv4 32 Network Layer Reachability Information (NLRI) and IPv6 Network Layer 33 Reachability Information (NLRI)to be carried over the same (Border 34 Gateway Protocol) BGP TCP session. The design change provides the 35 same Dual Stacking functionality that exists today with separate IPv4 36 and IPv6 BGP sessions as we have today. With this design change from 37 a control plane perspective a single IPv6 is required for both IPv4 38 and IPv6 routing updates and from a data plane forwarindg perspective 39 an IPv6 address need only be configured on the PE and CE interface 40 for both IPv4 and IPv6 packet forwarding. 42 This document provides a much needed solution for Internet Exchange 43 Point (IXP) that are facing IPv4 address depletion at large peering 44 points. With this design, IXP can now deploy PE-CE IPv6-Only eBGP 45 Edge peering design to eliminate IPv4 provisioning at the Edge. This 46 core and edge IPv6-Only peering design paradigm change can apply to 47 any eBGP peering, public internet or private, which can be either 48 Core networks, Data Center networks, Access networks or can be any 49 eBGP peering scenario. This document provides interoperability test 50 cases for the IPv6-Only peering design as well as test results 51 between five major vendors stakeholders in the routing and switching 52 indusrty, Cisco, Juniper, Arista, Nokia and Huawei. With the test 53 results provided for the IPv6-Only Edge peering design, the goal is 54 that all other vendors around the world that have not been tested 55 will begin to adopt and implement this new Best Current Practice for 56 eBGP IPv6-Only Edge peering. 58 As this issue with IXP IPv4 address depletion is a critical issue 59 around the world, it is imperative for an immediate solution that can 60 be implemented quickly. This Best Current Practice IPv6-only eBGP 61 peering design specification will help proliferate IPv6-Only 62 deployments at the eBGP Edge network peering points to starting 63 immediately at a minimum with operators around the world using Cisco, 64 Juniper, Arista, Nokia and Huawei. As other vendors start to 65 implement this Best Current Practice, the IXP IPv4 address depletion 66 gap will eventually be eliminated. 68 Status of This Memo 70 This Internet-Draft is submitted in full conformance with the 71 provisions of BCP 78 and BCP 79. 73 Internet-Drafts are working documents of the Internet Engineering 74 Task Force (IETF). Note that other groups may also distribute 75 working documents as Internet-Drafts. The list of current Internet- 76 Drafts is at https://datatracker.ietf.org/drafts/current/. 78 Internet-Drafts are draft documents valid for a maximum of six months 79 and may be updated, replaced, or obsoleted by other documents at any 80 time. It is inappropriate to use Internet-Drafts as reference 81 material or to cite them other than as "work in progress." 83 This Internet-Draft will expire on November 7, 2021. 85 Copyright Notice 87 Copyright (c) 2021 IETF Trust and the persons identified as the 88 document authors. All rights reserved. 90 This document is subject to BCP 78 and the IETF Trust's Legal 91 Provisions Relating to IETF Documents 92 (https://trustee.ietf.org/license-info) in effect on the date of 93 publication of this document. Please review these documents 94 carefully, as they describe your rights and restrictions with respect 95 to this document. Code Components extracted from this document must 96 include Simplified BSD License text as described in Section 4.e of 97 the Trust Legal Provisions and are provided without warranty as 98 described in the Simplified BSD License. 100 Table of Contents 102 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 103 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . 7 108 4.3. IPv6-Only Edge Peering Design . . . . . . . . . . . . . . 8 109 4.3.1. IPv6-Only Edge Peering Packet Walk . . . . . . . . . 8 110 4.3.2. 6to4 Softwire IPv4-Only Core packet walk . . . . . . 9 111 4.3.3. 4to6 Softwire IPv6-Only Core packet walk . . . . . . 10 112 4.4. RFC5549 and RFC8950 Applicability . . . . . . . . . . . . 13 113 4.4.1. IPv6-Only Edge Peering design next-hop encoding . . . 13 114 4.4.2. RFC8950 updates to RFC5549 applicability . . . . . . 13 115 5. IPv6-Only Design Edge E2E Test Cases . . . . . . . . . . . . 14 116 5.1. Test-1 IPv6-Only PE-CE Global Table over IPv4-Only Core . 14 117 5.2. Test-2 E2E IPv6-Only PE-CE VPN over IPv4-Only Core . . . 15 118 5.3. Test-3 IPv6-Only PE-CE Global Table over IPv6-Only Core . 15 119 5.4. Test-4 IPv6-Only PE-CE VPN over IPv6-Only Core . . . . . 16 120 5.5. IPv6-Only PE-CE Operational Considerations Testing . . . 16 121 6. Operational Considerations . . . . . . . . . . . . . . . . . 17 122 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 123 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 124 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 125 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 126 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 127 10.2. Informative References . . . . . . . . . . . . . . . . . 19 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 130 1. Introduction 132 As Enterprises and Service Providers upgrade their brown field or 133 green field MPLS/SR core to an IPv6 transport such as MPLS LDPv6, SR- 134 MPLSv6 or SRv6, Multiprotocol BGP (MP-BGP) now plays an important 135 role in the transition of the Provider (P) core networks and Provider 136 Edge (PE) edge networks from IPv4 to IPv6. Operators have a 137 requirement to support IPv4 customers and must be able to support 138 IPv4 address family and Sub-Address-Family Virtual Private Network 139 (VPN)-IPv4, and Multicast VPN IPv4 customers. 141 IXP are also facing IPv4 address depletion at their peering points, 142 which are large Layer 2 transit backbones that service providers peer 143 and exchange IPv4 and IPv6 Network Layer Reachability Information 144 (NLRI). Today, these transit exchange points are Dual Stacked. With 145 this IPv6-only BGP peering design, only IPv6 is configured on the PE- 146 CE interface, the Provider Edge (PE) - Customer Edge (CE), the IPv6 147 BGP peer is now used to carry IPv4 (Network Layer Reachability 148 Information) NLRI over an IPv6 next hop using IPv6 next hop encoding 149 defined in [RFC8950], while continuing to forward both IPv4 and IPv6 150 packets. In the framework of this design the PE is no longer Dual 151 Stacked. However in the case of the CE, PE-CE link CE side of the 152 link is no longer Dual Stacked, however all other internal links 153 within the CE domain may or maynot be Dual stacked. 155 MP-BGP specifies that the set of usable next-hop address families is 156 determined by the Address Family Identifier (AFI) and the Subsequent 157 Address Family Identifier (SAFI). Historically the AFI/SAFI 158 definitions for the IPv4 address family only have provisions for 159 advertising a Next Hop address that belongs to the IPv4 protocol when 160 advertising IPv4 or VPN-IPv4. [RFC8950] specifies the extensions 161 necessary to allow advertising IPv4 NLRI, Virtual Private Network 162 Unicast (VPN-IPv4) NLRI, Multicast Virtual Private Network (MVPN- 163 IPv4) NLRI with a Next Hop address that belongs to the IPv6 protocol. 164 This comprises of an extended next hop encoding MP-REACH BGP 165 capability exchange to allow the address of the Next Hop for IPv4 166 NLRI, VPN-IPv4 NLRI and MVPN-IPv4 NLRI to also belong to the IPv6 167 Protocol. [RFC8950] defines the encoding of the Next Hop to 168 determine which of the protocols the address actually belongs to, and 169 a new BGP Capability allowing MP-BGP Peers to discover dynamically 170 whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 171 Next Hop. 173 The current specification for carrying IPv4 NLRI of a given address 174 family via a Next Hop of a different address family is now defined in 175 [RFC8950], and specifies the extended next hop encoding MP-REACH 176 capability extension necessary to do so. This comprises an extension 177 of the AFI/SAFI definitions to allow the address of the Next Hop for 178 IPv4 NLRI or VPN-IPv4 NLRI to belong to either the IPv4 or the IPv6 179 protocol, the encoding of the Next Hop information to determine which 180 of the protocols the address belongs to, and a new BGP Capability 181 allowing MP-BGP peers to dynamically discover whether they can 182 exchange IPv4 NLRI and VPN- IPv4 NLRI with an IPv6 Next Hop. 184 With the new extensions defined in [RFC8950] supporting NLRI and next 185 hop address family mismatch, the BGP peer session can now be treated 186 as a pure TCP transport and carry both IPv4 and IPv6 NLRI at the 187 Provider Edge (PE) - Customer Edge (CE) over a single IPv6 TCP 188 session. This allows for the elimination of dual stack from the PE- 189 CE peering point, and now enable the peering to be IPv6-ONLY. The 190 elimination of IPv4 on the PE-CE peering points translates into OPEX 191 expenditure savings of point-to-point infrastructure links as well as 192 /31 address space savings and administration and network management 193 of both IPv4 and IPv6 BGP peers. This reduction decreases the number 194 of PE-CE BGP peers by fifty percent, which is a tremendous cost 195 savings for operators. 197 While the savings exists at the Edge eBGP PE-CE peering, on the core 198 side PE to Route Reflector (RR) peering carrying IPv4 199 <1/1>, VPN-IPV4 <1/128>, and Multicasat VPN <1/129>, there is no 200 savings as the Provider (P) Core is IPv6 Only and thus can only have 201 an IPv6 peer and must use [RFC8950] extended next hop encoding to 202 carrying IPv4 NLRI IPV4 <2/1>, VPN-IPV4 <2/128>, and Multicasat VPN 203 <2/129> over an IPv6 next hop. 205 This document provides a much needed solution for Internet Exchange 206 Point (IXP) that are facing IPv4 address depletion at large peering 207 points. With this design, IXP can now use deploy PE-CE IPv6-Only 208 eBGP Edge peering design to eliminate IPv4 provisioning at the Edge. 209 This core and edge IPv6-Only peering design paradigm change can apply 210 to any eBGP peering, public internet or private, which can be either 211 Core networks, Data Center networks, Access networks or can be any 212 eBGP peering scenario. This document provides interoperability test 213 cases for the IPv6-Only peering design as well as successful test 214 results between five major vendors stakeholders in the routing and 215 switching indusrty, Cisco, Juniper, Arista, Nokia and Huawei. With 216 the test results provided for the IPv6-Only Edge peering design, the 217 goal is that all other vendors around the world that have not been 218 tested will begin to adopt and implement this new best practice for 219 eBGP IPv6-Only Edge peering. 221 As this issue with IXP address depletion is a critical issue around 222 the world, it is imperative for an immediate solution that can be 223 implemented quickly. This best practice IPv6-only eBGP peering 224 design specification will help proliferate IPv6-Only deployments at 225 the eBGP Edge network peering points starting immediately at a 226 minimum with operators around the world using Cisco, Juniper, Arista, 227 Nokia and Huawei. 229 2. Requirements Language 231 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 232 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 233 "OPTIONAL" in this document are to be interpreted as described in BCP 234 14 [RFC2119] [RFC8174] when, and only when, they appear in all 235 capitals, as shown here. 237 3. Terminology 239 Terminolgoy used in defining the IPv6-Only Edge specification. 241 AFBR: Address Family Border Router Provider Edge (PE). 243 Edge: PE-CE Edge Network Provider Edge - Customer Edge 245 Core: P Core Network Provider (P) 247 4to6 Softwire : IPv4 edge over an IPv6-Only core 249 6to4 Softwire: IPv6 edge over an IPv4-Only core 251 E2E: End to End 253 4. IPv6-Only Edge Peering Architecture 255 4.1. Problem Statement 257 This specification addresses a real issue that has been discussed at 258 many operator groups around the world related to IXP major peering 259 points where hundreds of AS's have both IPv4 and IPv6 dual stacked 260 peering. IPv4 address depletion have been a major issue issue for 261 many years now. Operators around the world are clamoring for a 262 solution that can help solve issues related to IPv4 address depletion 263 at these large IXP peering points. With this solution IXPs as well 264 as all infrastructure networks such as Core networks, DC networks, 265 Access networks as well as any PE-CE public or private network can 266 now utilize this IPv6-Only Edge solution and reap the benefits 267 immediately on IPv4 address space saving. 269 IXP Problem Statement 271 Dual Stacked Dual Stacked 272 CE PE 274 +-------+ IPv4 BGP Peer +-------+ 275 | |---------------| | 276 | CE | IPv6 BGP Peer | PE | 277 | |---------------| | 278 +-------+ +-------+ 279 IPv4 forwarding IPv4 forwarding 280 IPv6 forwarding IPv6 forwarding 282 Figure 1: Problem Statement - IXP Dual Stack Peering 283 ________ 284 Dual Stacked _____ / \ Dual Stacked 285 PE / CE / \__/ \___ PE / CE 286 +----+ +----+ / \ +------+ +-----+ 287 | | | | |0====VPN Overlay Tunnel ==0| | | | | 288 | | | | | \ | | | | 289 | CE |--| PE |--\ IPv6-Only Core |----| PE |---| CE | 290 | | | | \0=========Underlay =======0| | | | | 291 +----+ +----+ \ __/ +------+ +-----+ 292 IPv4 IPv6 BGP peer \ IP / MPLS / SR domain / IPv4 and IPv6 BGP peer 293 IPv4 forwarding \__ __ / IPv4 forwarding 294 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 296 Figure 2: Problem Statement - E2E Dual Stack Edge 298 4.2. IPv6-Only PE-CE Design Solution 300 The IPv6-Only Edge design solution provides a means of E2E single 301 protocol design solution extension of [RFC5565] Softwire Mesh 302 framework from the PE-CE Edge to the Core from ingres so egress 303 through the entire operators domain. This solution eliminates all 304 IPv4 addressing from end to end while still providing the same Dual 305 Stack functionality of IPv4 and IPv6 packet forwarding from a data 306 plane perspective by leveraging the [RFC8950] extended next hop 307 encoding so that IPv4 NLRI can be advertised over a single IPv6 pure 308 transport TCP session. This IPv6-Only E2E architecture eliminates 309 all IPv4 peering and IPv4 addressing E2E from the ingress CE to 310 ingress PE to egress PE to egress CE and all hops along the operator 311 E2E path. 313 Solution applicable to 314 any Edge peering scenario - IXP, Core, DC, Access, etc 316 +-------+ +-------+ 317 | | IPv6 Only | | 318 | CE |----------------| PE | 319 | | IPv6 BGP Peer | | 320 +-------+ +-------+ 321 IPv4 forwarding IPv4 forwarding 322 IPv6 forwarding IPv6 forwarding 324 Figure 3: IPv6-Only Solution Applicability 325 ________ 326 IPv6-Only _____ / \ IPv6-Only 327 PE / CE / \__/ \___ PE / CE 328 +----+ +----+ / \ +------+ +-----+ 329 | | | | |0====VPN Overlay Tunnel ==0| | | | | 330 | | | | | \ | | | | 331 | CE |--| PE |--\ IPv6-Only Core |----| PE |---| CE | 332 | | | | \0=========Underlay ===== ==0 | | | | 333 +----+ +----+ \ __/ +------+ +-----+ 334 IPv6 BGP peer \IP / MPLS / SR domain / IPv6 BGP peer 335 IPv4 forwarding \__ __ / IPv4 forwarding 336 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 338 Figure 4: E2E VPN Solution 340 4.3. IPv6-Only Edge Peering Design 342 4.3.1. IPv6-Only Edge Peering Packet Walk 344 The IPv6-Only Edge Peering design utilizes two key E2E Softwire Mesh 345 Framework scenario's, 4to6 softwire and 6to4 softwire. The Softwire 346 mesh framework concept is based on the overlay and underlay MPLS or 347 SR based technology framework, where the underlay is the transport 348 layer and the overlay is a Virtual Private Network (VPN) layer, and 349 is the the tunneled virtualization layer containing the customer 350 payload. The concept of a 6to4 Softwire is based on transmission of 351 IPv6 packets at the edge of the network by tunneling the IPv6 packets 352 over an IPv4-Only Core. The concept of a 4to6 Softwire is also based 353 on transmission of IPv4 packets at the edge of the network by 354 tunneling the IPv4 packets over an IPv6-Only Core. 356 This document describes End to End (E2E) test scenarios that follow a 357 packet flow from IPv6-Only attachment circuit from ingress PE-CE to 358 egress PE-CE tracing the routing protocol control plane and data 359 plane forwarding of IPv4 packets in a 4to6 softwire or 6to4 softwire 360 within the IPv4-Only or IPv6-Only Core network. In both secneario we 361 are focusing on IPv4 packets and the control plane and data plane 362 forwarding aspects of IPv4 packets from the PE-CE Edge network over 363 an IPv6-Only P (Provider) core network or IPv4-Only P (Provider) core 364 network. With this IPv6-Only Edge peering design, the Softwire Mesh 365 Framework is not extended beyond the Provider Edge (PE) and continues 366 to terminate on the PE router. 368 4.3.2. 6to4 Softwire IPv4-Only Core packet walk 370 6to4 softwire where IPv6-Edge eBGP IPv6 peering where IPv4 packets at 371 network Edge traverse a IPv4-Only Core 373 In the scenario where IPv4 packets originating from a PE-CE edge are 374 tunneled over an MPLS or Segment Routing IPv4 underlay core network, 375 the PE and CE only have an IPv6 address configured on the interface. 376 In this scenario the IPv4 packets that ingress the CE from within the 377 CE AS are over an IPv6-Only interface and are forwarded to an IPv4 378 NLRI destination prefix learned from the Pure Transport Single IPv6 379 BGP Peer. In the IPv6-Only Edge peering architecture the PE is 380 IPv6-Only as all PE-CE interfaces are IPv6-Only. However, on the CE, 381 the PE-CE interface is the only interface that is IPv6-Only and all 382 other interfaces may or may not be IPv6-Only. Following the data 383 plane packet flow, IPv4 packets are forwarded from the ingress CE to 384 the IPv6-Only ingress PE where the VPN label imposition push per 385 prefix, per-vrf, per-CE occurs and the labeled packet is forwarded 386 over a 6to4 softwire IPv4-Only core, to the egress PE where the VPN 387 label disposition pop occurs and the native IPv4 packet is forwarded 388 to the egress CE. In the reverse direction IPv4 packets are 389 forwarded from the egress CE to egress PE where the VPN label 390 imposition per prefix, per-vrf, per-CE push occurs and the labeled 391 packet is forwarded back over the 6to4 softwire IPv4-Only core, to 392 the ingress PE where the VPN label disposition pop occurs and the 393 native IPv4 packet is forwarded to the ingress CE. . The 394 functionality of the IPv4 forwarding plane in this scenario is 395 identical from a data plane forwarding perspective to Dual Stack IPv4 396 forwarding scenario. 398 +--------+ +--------+ 399 | IPv4 | | IPv4 | 400 | Client | | Client | 401 | Network| | Network| 402 +--------+ +--------+ 403 | \ / | 404 | \ / | 405 | \ / | 406 | X | 407 | / \ | 408 | / \ | 409 | / \ | 410 +--------+ +--------+ 411 | AFBR | | AFBR | 412 +--| IPv4/6 |---| IPv4/6 |--+ 413 | +--------+ +--------+ | 414 +--------+ | | +--------+ 415 | IPv4 | | | | IPv4 | 416 | Client | | | | Client | 417 | Network|------| IPv4 |-------| Network| 418 +--------+ | only | +--------+ 419 | | 420 | +--------+ +--------+ | 421 +--| AFBR |---| AFBR |--+ 422 | IPv4/6 | | IPv4/6 | 423 +--------+ +--------+ 424 | \ / | 425 | \ / | 426 | \ / | 427 | X | 428 | / \ | 429 | / \ | 430 | / \ | 431 +--------+ +--------+ 432 | IPv6 | | IPv4 | 433 | Client | | Client | 434 | Network| | Network| 435 +--------+ +--------+ 437 Figure 5: 6to4 Softwire - IPv6 Edge over an IPv4-Only Core 439 4.3.3. 4to6 Softwire IPv6-Only Core packet walk 441 4to6 softwire where IPv6-Edge eBGP IPv6 peering where IPv4 packets at 442 network Edge traverse a IPv6-Only Core 443 In the scenario where IPv4 packets originating from a PE-CE edge are 444 tunneled over an MPLS or Segment Routing IPv4 underlay core network, 445 the PE and CE only have an IPv6 address configured on the interface. 446 In this scenario the IPv4 packets that ingress the CE from within the 447 CE AS are over an IPv6-Only interface and are forwarded to an IPv4 448 NLRI destination prefix learned from the Pure Transport Single IPv6 449 BGP Peer. In the IPv6-Only Edge peering architecture the PE is 450 IPv6-Only as all PE-CE interfaces are IPv6-Only. However, on the CE, 451 the PE-CE interface is the only interface that is IPv6-Only and all 452 other interfaces may or may not be IPv6-Only. Following the data 453 plane packet flow, IPv4 packets are forwarded from the ingress CE to 454 the IPv6-Only ingress PE where the VPN label imposition push per 455 prefix, per-vrf, per-CE occurs and the labeled packet is forwarded 456 over a 4to6 softwire IPv6-Only core, to the egress PE where the VPN 457 label disposition pop occurs and the native IPv4 packet is forwarded 458 to the egress CE. In the reverse direction IPv4 packets are 459 forwarded from the egress CE to egress PE where the VPN label 460 imposition per prefix, per-vrf, per-CE push occurs and the labeled 461 packet is forwarded back over the 4to6 softwire IPv6-Only core, to 462 the ingress PE where the VPN label disposition pop occurs and the 463 native IPv4 packet is forwarded to the ingress CE. . The 464 functionality of the IPv4 forwarding plane in this scenario is 465 identical from a data plane forwarding perspective to Dual Stack IPv4 466 forwarding scenario. 468 +--------+ +--------+ 469 | IPv4 | | IPv4 | 470 | Client | | Client | 471 | Network| | Network| 472 +--------+ +--------+ 473 | \ / | 474 | \ / | 475 | \ / | 476 | X | 477 | / \ | 478 | / \ | 479 | / \ | 480 +--------+ +--------+ 481 | AFBR | | AFBR | 482 +--| IPv4/6 |---| IPv4/6 |--+ 483 | +--------+ +--------+ | 484 +--------+ | | +--------+ 485 | IPv6 | | | | IPv6 | 486 | Client | | | | Client | 487 | Network|------| IPv6 |-------| Network| 488 +--------+ | only | +--------+ 489 | | 490 | +--------+ +--------+ | 491 +--| AFBR |---| AFBR |--+ 492 | IPv4/6 | | IPv4/6 | 493 +--------+ +--------+ 494 | \ / | 495 | \ / | 496 | \ / | 497 | X | 498 | / \ | 499 | / \ | 500 | / \ | 501 +--------+ +--------+ 502 | IPv4 | | IPv4 | 503 | Client | | Client | 504 | Network| | Network| 505 +--------+ +--------+ 507 Figure 6: 4to6 Softwire - IPv4 Edge over an IPv6-Only Core 509 4.4. RFC5549 and RFC8950 Applicability 511 4.4.1. IPv6-Only Edge Peering design next-hop encoding 513 This section describes [RFC8950] next hop encoding updates to 514 [RFC5549] applicability to this specification. IPv6-only eBGP Edge 515 PE-CE peering to carry IPv4 Unicast NLRI IPv4 <1/1> over 516 an IPv6 next hop BGP capability extended hop encoding IANA capability 517 codepoint value 5 defined is applicable to both [RFC5549] and 518 [RFC8950] as IPv4 Unicast NLRI IPv4 <1/1> does not change 519 in the RFC updates. 521 IPv4 packets over an IPv6-Only core 4to6 Softwire E2E packet flow is 522 part of the IPv6-Only design vendor interoperaiblity test cases and 523 in that respect is applicable as [RFC8950] updates [RFC5549] for 524 VPN-IPV4 <1/128>, and Multicasat VPN <1/129> 526 4.4.2. RFC8950 updates to RFC5549 applicability 528 This section describes the [RFC8950] next hop encoding updates to 529 [RFC5549] 531 In [RFC5549] when AFI/SAFI 1/128 is used, the next-hop address is 532 encoded as an IPv6 address with a length of 16 or 32 bytes. This 533 document modifies how the next-hop address is encoded to accommodate 534 all existing implementations and bring consistency with VPNv4oIPv4 535 and VPNv6oIPv6. The next-hop address is now encoded as a VPN-IPv6 536 address with a length of 24 or 48 bytes [RFC8950] (see Sections 3 and 537 6.2 of this document). This change addresses Erratum ID 5253 538 (Err5253). As all known and deployed implementations are 539 interoperable today and use the new proposed encoding, the change 540 does not break existing interoperability. Updates to [RFC8950] is 541 applicable to the IPv6-Only PE-CE edge design for the IPv6 next hop 542 encoding E2E test case of IPv4 packets over and IPv6-Only core 4to6 543 Softwire. In this test case IPv4 Unicast NLRI IPv4 <1/1> 544 is advertised over the PE to RR core peering 4to6 softwire in VPN-IPV4 <1/128>. In this test case label allocation mode 546 comes into play which is discussed in section 8.9. 548 [RFC5549] next hop encoding of MP_REACH_NLRI with: 550 o NLRI= NLRI as per current AFI/SAFI definition 552 Advertising with [RFC4760] MP_REACH_NLRI with: 554 o AFI = 1 556 o SAFI = 128 or 129 557 o Length of Next Hop Address = 16 or 32 559 o NLRI= NLRI as per current AFI/SAFI definition 561 [RFC8950] next hop encoding of MP_REACH_NLRI with: 563 o NLRI= NLRI as per current AFI/SAFI definition 565 Advertising with [RFC4760] MP_REACH_NLRI with: 567 o AFI = 1 569 o SAFI = 128 or 129 571 o Length of Next Hop Address = 24 or 48 573 o Next Hop Address = VPN-IPv6 address of next hop with an 8-octet RD 574 set to zero (potentially followed by the link-local VPN-IPv6 575 address of the next hop with an 8-octet RD is set to zero). 577 o NLRI= NLRI as per current AFI/SAFI definition 579 5. IPv6-Only Design Edge E2E Test Cases 581 Proof of conept interoperability testing of the 4 test cases between 582 the 5 vendors Cisco, Juniper, Arista, Nokia and Huawei. 584 5.1. Test-1 IPv6-Only PE-CE Global Table over IPv4-Only Core 586 ________ 587 IPv6-Only _____ / \ IPv6-Only 588 PE / CE / \__/ \___ PE / CE 589 +----+ +----+ / \ +------+ +-----+ 590 | | | | | |_ | | | | 591 | | | | | \ | | | | 592 | CE |--| PE |--\ IPv4-Only Core |----| PE |---| CE | 593 | | | | \0=========Underlay =======0| | | | | 594 +----+ +----+ \ __/ +------+ +-----+ 595 IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer 596 IPv4 forwarding \__ __ / IPv4 forwarding 597 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 599 Figure 7: Test-1 E2E IPv6-Only PE-CE Global Table 6to4 Softwire 601 Cisco, Juniper, Arista, Nokia, Huawei Test case Results documented 602 here. 604 5.2. Test-2 E2E IPv6-Only PE-CE VPN over IPv4-Only Core 606 ________ 607 IPv6-Only _____ / \ IPv6-Only 608 PE / CE / \__/ \___ PE / CE 609 +----+ +----+ / \ +------+ +-----+ 610 | | | | | 0====VPN Overlay Tunnel ==0| | | | | 611 | | | | | \ | | | | 612 | CE |--| PE |--\ IPv4-Only Core |----| PE |---| CE | 613 | | | | \0=========Underlay =======0| | | | | 614 +----+ +----+ \ __/ +------+ +-----+ 615 IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer 616 IPv4 forwarding \__ __ / IPv4 forwarding 617 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 619 Figure 8: Test-2 E2E IPv6-Only PE-CE Design VPN 6to4 Softwire 621 Cisco, Juniper, Arista, Nokia, Huawei Test case Results documented 622 here. 624 5.3. Test-3 IPv6-Only PE-CE Global Table over IPv6-Only Core 626 ________ 627 IPv6-Only _____ / \ IPv6-Only 628 PE / CE / \__/ \___ PE / CE 629 +----+ +----+ / \ +------+ +-----+ 630 | | | | | |_ | | | | 631 | | | | | \ | | | | 632 | CE |--| PE |--\ IPv6-Only Core |----| PE |---| CE | 633 | | | | \0=========Underlay =======0| | | | | 634 +----+ +----+ \ __/ +------+ +-----+ 635 IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer 636 IPv4 forwarding \__ __ / IPv4 forwarding 637 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 639 Figure 9: Test-3 E2E IPv6-Only PE-CE Global Table 4to6 Softwire 641 Cisco, Juniper, Arista, Nokia, Huawei Test case Results documented 642 here. 644 5.4. Test-4 IPv6-Only PE-CE VPN over IPv6-Only Core 646 ________ 647 IPv6-Only _____ / \ IPv6-Only 648 PE / CE / \__/ \___ PE / CE 649 +----+ +----+ / \ +------+ +-----+ 650 | | | | | 0====VPN Overlay Tunnel ==0| | | | | 651 | | | | | \ | | | | 652 | CE |--| PE |--\ IPv6-Only Core |----| PE |---| CE | 653 | | | | \0=========Underlay =======0| | | | | 654 +----+ +----+ \ __/ +------+ +-----+ 655 IPv6 BGP peer \ MPLS / SR domain / IPv6 BGP peer 656 IPv4 forwarding \__ __ / IPv4 forwarding 657 IPv6 forwarding \_______/ \_____/ IPv6 forwarding 659 Figure 10: Test-4 E2E IPv6-Only PE-CE VPN 4to6 Softwire 661 Cisco, Juniper, Arista, Nokia, Huawei Test case Results documented 662 here. 664 5.5. IPv6-Only PE-CE Operational Considerations Testing 666 Ping CE to PE when destination prefix is withdrawn 667 Traceroute CE to PE and test all ICMPv4 and ICMPv6 type codes 669 +-------+ +-------+ 670 | | IPv6 Only | | 671 | CE |----------------| PE | 672 | | IPv6 BGP Peer | | 673 +-------+ +-------+ 674 IPv4 forwarding IPv4 forwarding 675 IPv6 forwarding IPv6 forwarding 677 Figure 11: Ping and Trace Test Case 679 Cisco, Juniper, Arista, Nokia, Huawei Test case Results documented 680 here. 682 6. Operational Considerations 684 With a single IPv6 Peer carrying both IPv4 and IPv6 NLRI there are 685 some operational considerations in terms of what changes and what 686 does not change. 688 What does not change with a single IPv6 transport peer carrying IPv4 689 NLRI and IPv6 NLRI below: 691 Routing Policy configuration is still separate for IPv4 and IPv6 692 configured by capability as previously. 694 Layer 1, Layer 2 issues such as one-way fiber or fiber cut will 695 impact both IPv4 and IPv6 as previously. 697 If the interface is in the Admin Down state, the IPv6 peer would go 698 down, and IPv4 NLRI and IPv6 NLRI would be withdrawn as previously. 700 Changes resulting from a single IPv6 transport peer carrying IPv4 701 NLRI and IPv6 NLRI below: 703 Physical interface is no longer dual stacked. 705 Any change in IPv6 address or DAD state will impact both IPv4 and 706 IPv6 NLRI exchange. 708 Single BFD session for both IPv4 and IPv6 NLRI fate sharing as the 709 session is now tied to the transport, which now is only IPv6 address 710 family. 712 Both IPv4 and IPv6 peer now exists under the IPv6 address family 713 configuration. 715 Fate sharing of IPv4 and IPv6 address family from a logical 716 perspective now carried over a single physical IPv6 peer. 718 From an operations perspective, prior to elimination of IPv4 peers, 719 an audit is recommended to identify and IPv4 and IPv6 peering 720 incongruencies that may exist and to rectify them. No operational 721 impacts or issues are expected with this change. 723 With MPLS VPN overlay, per-CE next-hop label allcoation mode where 724 both IPv4 and IPv6 prefixes have the same label in no table lookup 725 pop-n-forward mode should be taken into consideration. 727 7. IANA Considerations 729 There are not any IANA considerations. 731 8. Security Considerations 733 The extensions defined in this document allow BGP to propagate 734 reachability information about IPv4 prefixes over an MPLS or SR 735 IPv6-Only core network. As such, no new security issues are raised 736 beyond those that already exist in BGP-4 and the use of MP-BGP for 737 IPv6. Both IPv4 and IPv6 peers exist under the IPv6 address family 738 configuration. The security features of BGP and corresponding 739 security policy defined in the ISP domain are applicable. For the 740 inter-AS distribution of IPv6 routes according to case (a) of 741 Section 4 of this document, no new security issues are raised beyond 742 those that already exist in the use of eBGP for IPv6 [RFC2545]. 744 9. Acknowledgments 746 Thanks to Kaliraj Vairavakkalai, Linda Dunbar, Aijun Wang, Eduardfor 747 Vasilenko, Joel Harlpern, Michael McBride, Ketan Talaulikar for 748 review comments. 750 10. References 752 10.1. Normative References 754 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 755 Requirement Levels", BCP 14, RFC 2119, 756 DOI 10.17487/RFC2119, March 1997, 757 . 759 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 760 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 761 DOI 10.17487/RFC2545, March 1999, 762 . 764 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 765 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 766 2006, . 768 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 769 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 770 2006, . 772 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 773 "Multiprotocol Extensions for BGP-4", RFC 4760, 774 DOI 10.17487/RFC4760, January 2007, 775 . 777 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 778 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 779 2009, . 781 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 782 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 783 May 2017, . 785 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 786 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 787 . 789 10.2. Informative References 791 [I-D.ietf-idr-dynamic-cap] 792 Ramachandra, S. and E. Chen, "Dynamic Capability for BGP- 793 4", draft-ietf-idr-dynamic-cap-14 (work in progress), 794 December 2011. 796 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 797 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 798 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 799 . 801 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 802 R., Patel, K., and J. Guichard, "Constrained Route 803 Distribution for Border Gateway Protocol/MultiProtocol 804 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 805 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 806 November 2006, . 808 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 809 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 810 Provider Edge Routers (6PE)", RFC 4798, 811 DOI 10.17487/RFC4798, February 2007, 812 . 814 [RFC4925] Li, X., Ed., Dawkins, S., Ed., Ward, D., Ed., and A. 815 Durand, Ed., "Softwire Problem Statement", RFC 4925, 816 DOI 10.17487/RFC4925, July 2007, 817 . 819 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 820 Layer Reachability Information with an IPv6 Next Hop", 821 RFC 5549, DOI 10.17487/RFC5549, May 2009, 822 . 824 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 825 Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, 826 . 828 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 829 "Provisioning, Auto-Discovery, and Signaling in Layer 2 830 Virtual Private Networks (L2VPNs)", RFC 6074, 831 DOI 10.17487/RFC6074, January 2011, 832 . 834 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 835 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 836 2012, . 838 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 839 Encodings and Procedures for Multicast in MPLS/BGP IP 840 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 841 . 843 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 844 Writing an IANA Considerations Section in RFCs", BCP 26, 845 RFC 8126, DOI 10.17487/RFC8126, June 2017, 846 . 848 [RFC8950] Litkowski, S., Agrawal, S., Ananthamurthy, K., and K. 849 Patel, "Advertising IPv4 Network Layer Reachability 850 Information (NLRI) with an IPv6 Next Hop", RFC 8950, 851 DOI 10.17487/RFC8950, November 2020, 852 . 854 Authors' Addresses 856 Gyan Mishra 857 Verizon Inc. 859 Email: gyan.s.mishra@verizon.com 860 Mankamana Mishra 861 Cisco Systems 862 821 Alder Drive, 863 MILPITAS CALIFORNIA 95035 865 Email: mankamis@cisco.com 867 Jeff Tantsura 868 Juniper Networks, Inc. 870 Email: jefftant.ietf@gmail.com 872 Lili Wang 873 Juniper Networks, Inc. 874 10 Technology Park Drive, 875 Westford MA 01886 876 US 878 Email: liliw@juniper.net 880 Qing Yang 881 Arista Networks 883 Email: qyang@arista.com 885 Adam Simpson 886 Nokia 888 Email: adam.1.simpson@nokia.com 890 Shuanglong Chen 891 Huawei Technologies 893 Email: chenshuanglong@huawei.com