idnits 2.17.1 draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-08.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5549], [RFC5565]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 22, 2021) is 1158 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: 'RFC5492' is defined on line 448, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-dynamic-cap' is defined on line 462, but no explicit reference was found in the text == Unused Reference: 'RFC8126' is defined on line 514, 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 (~~), 5 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: August 26, 2021 Cisco Systems 6 J. Tantsura 7 Apstra, Inc. 8 L. Wang 9 Juniper Networks, Inc. 10 Q. Yang 11 Arista Networks 12 A. Simpson 13 Nokia 14 S. Chen 15 Huawei Technologies 16 February 22, 2021 18 IPv4 NLRI with IPv6 Next Hop Use Cases 19 draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-08 21 Abstract 23 As Enterprises and Service Providers upgrade their brown field or 24 green field MPLS/SR core to an IPv6 transport such as MPLS LDPv6, SR- 25 MPLSv6 or SRv6, Multiprotocol BGP (MP-BGP)now plays an important role 26 in the transition of the core from IPv4 to IPv6 being able to 27 continue to support legacy IPv4, VPN-IPv4, and Multicast VPN IPv4 28 customers. 30 This document describes the critical use case and OPEX savings of 31 being able to leverage the MP-BGP capability exchange usage as a pure 32 transport allowing both IPv4 and IPv6 to be carried over the same BGP 33 TCP session. By doing so, allows for the elimination of Dual 34 Stacking on the PE-CE connections making the peering IPv6-ONLY to now 35 carry both IPv4 and IPv6 Network Layer Reachability Information 36 (NLRI). This document now provides a solution for IXPs (Internet 37 Exchange points) that are facing IPv4 address depletion at these 38 peering points to use BGP-MP capability exchange defined in [RFC5549] 39 to carry IPv4 (Network Layer Reachability Information) NLRI in an 40 IPv6 next hop using the [RFC5565] softwire mesh framework. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on August 26, 2021. 59 Copyright Notice 61 Copyright (c) 2021 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (https://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 78 3. eBGP PE-CE IPv4 and IPv6 NLRI over IPv6 Next Hop Peer Use 79 Case Interop Testing . . . . . . . . . . . . . . . . . . . . 6 80 4. RFC 8950 updates to RFC 5549 . . . . . . . . . . . . . . . . 6 81 5. Operational Improvements with Single IPv6 transport peer . . 8 82 6. Operational Considerations . . . . . . . . . . . . . . . . . 8 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 85 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 87 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 88 10.2. Informative References . . . . . . . . . . . . . . . . . 10 89 Appendix A. IPv4 NLRI IPv6 Next Hop Vendor Testing . . . . . . . 12 90 A.1. Router and Switch Vendors Support and Quality Assurance 91 Engineering Lab Results. . . . . . . . . . . . . . . . . 12 92 A.2. Router and Switch Vendors Interoperability Lab Results. . 12 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 95 1. Introduction 97 As Enterprises and Service Providers upgrade their brown field or 98 green field MPLS/SR core to an IPv6 transport such as MPLS LDPv6, SR- 99 MPLSv6 or SRv6, Multiprotocol BGP (MP-BGP)now plays an important role 100 in the transition of the core from IPv4 to IPv6, and being able to 101 continue to support legacy IPv4, VPN-IPv4, and Multicast VPN IPv4 102 customers. 104 IXPs (Internet Exchange points) are also facing IPv4 address 105 depletion at their peering points, which are large Layer 2 transit 106 backbones that service providers peer and exchange IPv4 and IPv6 107 (Network Layer Reachability Information) NLRI. Today these transit 108 exchange points are dual stacked. One proposal to solve this issue 109 is to use [RFC5549] to carry IPv4 (Network Layer Reachability 110 Information) NLRI in an IPv6 next hop and eliminate the IPv4 peering 111 completely using the concept of [RFC5565] softwire mesh framework. 112 So now with the MP-BGP reach capability exchanged over IPv4 AFI over 113 IPv6 next hop peer we can now advertise IPv4(Network Layer 114 Reachability Information) NLRI over IPv6 peering using the [RFC5565] 115 softwire mesh framework. 117 Multiprotocol BGP (MP-BGP) specifies that the set of usable next-hop 118 address families is determined by the Address Family Identifier (AFI) 119 and the Subsequent Address Family Identifier (SAFI). Historically 120 the AFI/SAFI definitions for the IPv4 address family only have 121 provisions for advertising a Next Hop address that belongs to the 122 IPv4 protocol when advertising IPv4 or VPN-IPv4 Network Layer 123 Reachability Information (NLRI). [RFC5549] specifies the extensions 124 necessary to allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next 125 Hop address that belongs to the IPv6 protocol. This comprises an 126 extension of the AFI/SAFI definitions to allow the address of the 127 Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 128 Protocol. [RFC5549] defines the encoding of the Next Hop to 129 determine which of the protocols the address actually belongs to, and 130 a new BGP Capability allowing MP-BGP Peers to dynamically discover 131 whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 132 Next Hop. 134 With this new MP-BGP capability exchange allows the BGP peering 135 session to act as a pure transport to allow the session to carry 136 Address Family Identifier (AFI) and the Subsequent Address Family 137 Identifier (SAFI) for both IPv4 and IPv6. 139 Furthermore, a number of these existing AFI/SAFIs allow the Next Hop 140 to belong to either the IPv4 Network Layer Protocol or the IPv6 141 Network Layer Protocol, and specify the encoding of the Next Hop 142 information to determine which of the protocols the address actually 143 belongs to. For example, [RFC4684] allows the Next Hop address to be 144 either IPv4 or IPv6 and states that the Next Hop field address shall 145 be interpreted as an IPv4 address whenever the length of Next Hop 146 address is 4 octets, and as an IPv6 address whenever the length of 147 the Next Hop address is 16 octets. 149 For example, the AFI/SAFI <25/65> used (as per [RFC6074]) to perform 150 L2VPN auto-discovery, allows advertising NLRI that contains the 151 identifier of a Virtual Private LAN Service (VPLS) instance or that 152 identifies a particular pool of attachment circuits at a given 153 Provider Edge (PE), while the Next Hop field contains the loopback 154 address of a PE. Similarly, the AFI/SAFI <1/132> (defined in 155 [RFC4684]) to advertise Route Target (RT) membership information, 156 allows advertising NLRI that contains such RT membership information, 157 while the Next Hop field contains the address of the advertising 158 router. 160 There are situations such as those described in [RFC4925] and in 161 [RFC5565] where carriers (or large enterprise networks acting as 162 carrier for their internal resources) may be required to establish 163 connectivity between 'islands' of networks of one address family type 164 across a transit core of a differing address family type. This 165 includes both the case of IPv6 islands across an IPv4 core and the 166 case of IPv4 islands across an IPv6 core. Where Multiprotocol BGP 167 (MP-BGP) is used to advertise the corresponding reachability 168 information, this translates into the requirement for a BGP speaker 169 to advertise Network Layer Reachability Information (NLRI) of a given 170 address family via a Next Hop of a different address family (i.e., 171 IPv6 NLRI with IPv4 Next Hop and IPv4 NLRI with IPv6 Next Hop). 173 The current AFI/SAFI definitions for the IPv6 address family assume 174 that the Next Hop address belongs to the IPv6 address family type. 175 Specifically, as per [RFC2545] and [RFC8277], when the is 176 <2/1>, <2/2>, or <2/4>, the Next Hop address is assumed to be of IPv6 177 type. As per [RFC4659], when the is <2/128>, the Next Hop 178 address is assumed to be of IPv6-VPN type. 180 However, [RFC4798] and [RFC4659] specify how an IPv4 address can be 181 encoded inside the Next Hop IPv6 address field when IPv6 NLRI needs 182 to be advertised with an IPv4 Next Hop. [RFC4798] defines how the 183 IPv4-mapped IPv6 address format specified in the IPv6 addressing 184 architecture ([RFC4291]) can be used for that purpose when the is <2/1>, <2/2>, or <2/4>. [RFC4659] defines how the IPv4- 186 mapped IPv6 address format as well as a null Route Distinguisher can 187 be used for that purpose when the is <2/128>. Thus, there 188 are existing solutions for the advertisement of IPv6 NLRI with an 189 IPv4 Next Hop. 191 Similarly, the current AFI/SAFI definitions for advertisement of IPv4 192 NLRI or VPN-IPv4 NLRI assume that the Next Hop address belongs to the 193 IPv4 address family type. Specifically, as per [RFC4760] and 194 [RFC8277], when the is <1/1>, <1/2>, or <1/4>, the Next 195 Hop address is assumed to be of IPv4 type. As per [RFC4364], when 196 the is <1/128>, the Next Hop address is assumed to be of 197 VPN-IPv4 type. As per [RFC6513] and [RFC6514], when the 198 is <1/129>, the Next Hop address is assumed to be of VPN-IPv4 type. 199 There is clearly no generally applicable method for encoding an IPv6 200 address inside the IPv4 address field of the Next Hop. Hence, there 201 is currently no specified solution for advertising IPv4 or VPN-IPv4 202 NLRI with an IPv6 Next Hop. 204 A new specification for carrying IPv4 Network Layer Reachability 205 Information (NLRI) of a given address family via a Next Hop of a 206 different address family is now defined in [RFC5549], and specifies 207 the extensions necessary to do so. This comprises an extension of 208 the AFI/SAFI definitions to allow the address of the Next Hop for 209 IPv4 NLRI or VPN-IPv4 NLRI to belong to either the IPv4 or the IPv6 210 protocol, the encoding of the Next Hop information to determine which 211 of the protocols the address actually belongs to, and a new BGP 212 Capability allowing MP-BGP peers to dynamically discover whether they 213 can exchange IPv4 NLRI and VPN- IPv4 NLRI with an IPv6 Next Hop. 215 With the new extensions defined in [RFC5549] supporting Network Layer 216 Reachability Information (NLRI) and next hop address family mismatch, 217 the BGP peer session can now be treated as a pure transport and carry 218 both IPv4 and IPv6 NLRI at the PE-CE edge over a single IPv6 TCP 219 session. This allows for the elimination of dual stack from the PE- 220 CE peering point, and now allow the peering to be IPv6-ONLY. The 221 elimination of IPv4 on the PE-CE peering points translates into OPEX 222 expenditure savings of point-to-point infrastructure links as well as 223 /31 address space savings and administration and network management 224 of both IPv4 and IPv6 BGP peers. This reduction decreases the number 225 of PE-CE BGP peers by fifty percent, which is a tremendous cost 226 savings for all Enterprises and Service Providers. 228 While the savings exists at the PE-CE edge, on the core side PE to 229 Route Reflector peering carrying IPv4 <1/1>, VPN-IPV4 230 <1/128>, and Multicasat VPN <1/129>, the cost savings nets to a break 231 even to be the same as with an IPV4 Core carrying IPv6 NLRI IPV6 232 <2/1>, VPN-IPV6 <2/128>, and Multicasat VPN <2/129>. This document 233 also provides a possible solution for IXPs (Internet Exchange points) 234 that are facing IPv4 address depletion at these peering points to use 235 BGP-MP capability exchange defined in [RFC5549] to carry IPv4 236 (Network Layer Reachability Information) NLRI in an IPv6 next hop 237 using the [RFC5565] softwire mesh framework. 239 2. Requirements Language 241 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 242 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 243 "OPTIONAL" in this document are to be interpreted as described in BCP 244 14 [RFC2119] [RFC8174] when, and only when, they appear in all 245 capitals, as shown here. 247 3. eBGP PE-CE IPv4 and IPv6 NLRI over IPv6 Next Hop Peer Use Case 248 Interop Testing 250 This particualr use case for external BGP PE-CE edge peering 251 interoperability testing defined in this draft utilizing [RFC8950] 252 next hop encoding to carry both IPv4 and IPv6 NLRI over an IPv6 Next 253 hop encoded peer. Today the IPv4 NLRI and IPv6 NLRI are carried over 254 separate BGP sessions based on the address family of the NLRI being 255 transported. With this drafts use case, the IPv6 NLRI Unicast SAFI 256 along with now the IPv4 NLRI Unicast SAFI, is now being carried by 257 the sinlge transport style IPv6 next hop peer. 259 This document describes the use case of advertising with IPv4 NLRI 260 over IPv6 Next hop with MP_REACH_NLRI with: 262 o AFI = 1 264 o SAFI = 1 266 o Length of Next Hop Address = 16 or 32 268 o Next Hop Address = IPv6 address of next hop (potentially followed 269 by the link-local IPv6 address of the next hop). This field is to 270 be constructed as per Section 3 of [RFC2545]. 272 The BGP speaker receiving the advertisement MUST use the Length of 273 Next Hop Address field to determine which network-layer protocol the 274 next hop address belongs to. 276 Note that this method of using the Length of the Next Hop Address 277 field to determine which network-layer protocol the next hop address 278 belongs to (out of the set of protocols allowed by the AFI/SAFI 279 definition) is the same as used in [RFC4684] and [RFC6074]. 281 4. RFC 8950 updates to RFC 5549 283 This section describes the updates to [RFC8950] next hop encoding 284 from [RFC5549]. In [RFC5549] when AFI/SAFI 1/128 is used, the next- 285 hop address is encoded as an IPv6 address with a length of 16 or 32 286 bytes. To accommodate all existing implementations and bring 287 consistency with VPNv4oIPv4 and VPNv6oIPv6, this document modifies 288 how the next-hop address is encoded. The next-hop address is now 289 encoded as a VPN-IPv6 address with a length of 24 or 48 bytes 290 [RFC8950] (see Sections 3 and 6.2). This change addresses Erratum ID 291 5253 (Err5253). As all known and deployed implementations are 292 interoperable today and use the new proposed encoding, the change 293 does not break existing interoperability. 295 [RFC5549] next hop encoding of MP_REACH_NLRI with: 297 o AFI = 1 299 o SAFI = 1, 2, or 4 301 o Length of Next Hop Address = 16 or 32 303 o Next Hop Address = IPv6 address of next hop (potentially followed 304 by the link-local IPv6 address of the next hop). This field is to 305 be constructed as per Section 3 of [RFC2545]. 307 o NLRI= NLRI as per current AFI/SAFI definition 309 It also allows advertising with [RFC4760] of an MP_REACH_NLRI with: 311 o AFI = 1 313 o SAFI = 128 or 129 315 o Length of Next Hop Address = 16 or 32 317 o NLRI= NLRI as per current AFI/SAFI definition 319 [RFC8950] next hop encoding of MP_REACH_NLRI with: 321 o AFI = 1 323 o SAFI = 1, 2, or 4 325 o Length of Next Hop Address = 16 or 32 327 o Next Hop Address = IPv6 address of next hop (potentially followed 328 by the link-local IPv6 address of the next hop). This field is to 329 be constructed as per Section 3 of [RFC2545]. 331 o NLRI= NLRI as per current AFI/SAFI definition 333 It also allows advertising with [RFC4760] of an MP_REACH_NLRI with: 335 o AFI = 1 337 o SAFI = 128 or 129 339 o Length of Next Hop Address = 24 or 48 341 o Next Hop Address = VPN-IPv6 address of next hop with an 8-octet RD 342 set to zero (potentially followed by the link-local VPN-IPv6 343 address of the next hop with an 8-octet RD is set to zero). 345 o NLRI= NLRI as per current AFI/SAFI definition 347 5. Operational Improvements with Single IPv6 transport peer 349 As Enterprises and Service Providers migrate their IPv4 core to an 350 MPLS LDPv6 or SRv6 transport, they must continue to be able to 351 support legacy IPv4 customers. With the new extensions defined in 352 [RFC4760], supporting Network Layer Reachability Information (NLRI) 353 and next hop address family mismatch, the BGP peer session can now be 354 treated as a pure transport and carry both IPv4 and IPv6 NLRI at the 355 PE-CE edge. This paves the way to now eliminate dual stacking on all 356 PE-CE peering points to customers making the peering IPv6 only. With 357 this change all IPv4 and IPv6 Network Layer Reachability Information 358 (NLRI) will now be carried over a single BGP session. This also 359 solves the dual stack issue with IXP (Internet Exchange Points) 360 having to maintain separate peering for both IPv4 and IPv6. From an 361 operations perspective the PE-CE edge peering will be drastically 362 simplified with the elimination of IPv4 peers yielding a reduction of 363 peers by 50 percent. From an operations perspective prior to 364 elimination of IPv4 peers an audit is recommended to identify and 365 IPv4 and IPv6 peering incongruencies that may exist and to rectify 366 prior to elimination of the IPv4 peers. No operational impacts or 367 issues are expected with this change. 369 6. Operational Considerations 371 With a sinlge IPv6 Peer carrying both IPv4 and IPv6 NLRI there are 372 some operational considerations in terms of what changes and what 373 does not change. 375 What does not change with a single IPv6 transport peer carrying IPv4 376 NLRI and IPv6 NLRI below: 378 Routing Policy configuration is still separate for IPv4 and IPv6 379 configured by capability as previously 381 Layer 1, Layer 2 issues such as 1 way fiber or fiber cut will impact 382 both IPv4 and IPv6 as previously. 384 If the interface is admin down the IPv6 peer would go down and IPv4 385 NLRI and IPv6 NLRI would be withdrawn as previously. 387 What does change with a single IPv6 transport peer carrying IPv4 NLRI 388 and IPv6 NLRI below: 390 Physical interface is no longer dual stacked. Any change in IPv6 391 address or DAD state will impact both IPv4 and IPv6 NLRI exchange 393 Single BFD session for both IPv4 and IPv6 NLRI fate sharing as the 394 session is now tied to the transport which now is only IPv6 address 395 family 397 Both IPv4 and IPv6 peer now exists under the IPv4 address family 398 configuration 400 Fate sharing of IPv4 and IPv6 address family from a logical 401 perspective now carried over a single IPv6 peer 403 7. IANA Considerations 405 There are not any IANA considerations. 407 8. Security Considerations 409 The extensions defined in this document allow BGP to propagate 410 reachability information about IPv6 routes over an MPLS IPv4 core 411 network. As such, no new security issues are raised beyond those 412 that already exist in BGP-4 and use of MP-BGP for IPv6. The security 413 features of BGP and corresponding security policy defined in the ISP 414 domain are applicable. For the inter-AS distribution of IPv6 routes 415 according to case (a) of Section 4 of this document, no new security 416 issues are raised beyond those that already exist in the use of eBGP 417 for IPv6 [RFC2545]. 419 9. Acknowledgments 421 10. References 423 10.1. Normative References 425 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 426 Requirement Levels", BCP 14, RFC 2119, 427 DOI 10.17487/RFC2119, March 1997, 428 . 430 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 431 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 432 DOI 10.17487/RFC2545, March 1999, 433 . 435 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 436 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 437 2006, . 439 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 440 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 441 2006, . 443 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 444 "Multiprotocol Extensions for BGP-4", RFC 4760, 445 DOI 10.17487/RFC4760, January 2007, 446 . 448 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 449 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 450 2009, . 452 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 453 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 454 May 2017, . 456 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 457 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 458 . 460 10.2. Informative References 462 [I-D.ietf-idr-dynamic-cap] 463 Ramachandra, S. and E. Chen, "Dynamic Capability for BGP- 464 4", draft-ietf-idr-dynamic-cap-14 (work in progress), 465 December 2011. 467 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 468 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 469 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 470 . 472 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 473 R., Patel, K., and J. Guichard, "Constrained Route 474 Distribution for Border Gateway Protocol/MultiProtocol 475 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 476 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 477 November 2006, . 479 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 480 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 481 Provider Edge Routers (6PE)", RFC 4798, 482 DOI 10.17487/RFC4798, February 2007, 483 . 485 [RFC4925] Li, X., Ed., Dawkins, S., Ed., Ward, D., Ed., and A. 486 Durand, Ed., "Softwire Problem Statement", RFC 4925, 487 DOI 10.17487/RFC4925, July 2007, 488 . 490 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 491 Layer Reachability Information with an IPv6 Next Hop", 492 RFC 5549, DOI 10.17487/RFC5549, May 2009, 493 . 495 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 496 Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, 497 . 499 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 500 "Provisioning, Auto-Discovery, and Signaling in Layer 2 501 Virtual Private Networks (L2VPNs)", RFC 6074, 502 DOI 10.17487/RFC6074, January 2011, 503 . 505 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 506 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 507 2012, . 509 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 510 Encodings and Procedures for Multicast in MPLS/BGP IP 511 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 512 . 514 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 515 Writing an IANA Considerations Section in RFCs", BCP 26, 516 RFC 8126, DOI 10.17487/RFC8126, June 2017, 517 . 519 [RFC8950] Litkowski, S., Agrawal, S., Ananthamurthy, K., and K. 520 Patel, "Advertising IPv4 Network Layer Reachability 521 Information (NLRI) with an IPv6 Next Hop", RFC 8950, 522 DOI 10.17487/RFC8950, November 2020, 523 . 525 Appendix A. IPv4 NLRI IPv6 Next Hop Vendor Testing 527 IPv4 NLRI with IPv6 Next Hop encoding is supported for all BGP peers 528 both iBGP and eBGP. 530 This section details the vendor support QA testing of RFC 8950 Next 531 Hop Encoding for "PE-CE eBGP" using GUA (Global Unicast Address), 532 Link Local (LL) peering. This drafts goal is to first ensure that QA 533 testing of all features and functionality works with "eBGP PE-CE" use 534 case single peer carrying both IPv4 NLRI and IPv6 NLRI and that the 535 routing policy features are all still fully functionality do not 536 change. 538 A.1. Router and Switch Vendors Support and Quality Assurance 539 Engineering Lab Results. 541 +-----------+----------------+---------------+-----------+ 542 | Vendor | PE-CE eBGP GUI | PE-CE eBGP LL | QA Tested | 543 +-----------+----------------+---------------+-----------+ 544 | Cisco | *** | | | 545 | Juniper | *** | | | 546 | Nokia/ALU | *** | | | 547 | Arista | *** | | | 548 | Huawei | *** | | | 549 +-----------+----------------+---------------+-----------+ 551 Table 1: Vendor Support 553 A.2. Router and Switch Vendors Interoperability Lab Results. 555 This section details the vendor interoperability testing and support 556 of RFC5549 that all features and functionality works with "eBGP PE- 557 CE" use case with having a single peer carrying both IPv4 NLRI and 558 IPv6 NLRI and that the routing policy features are fully tested for 559 quality assurance. 561 +-----------+-------+---------+-----------+--------+--------+ 562 | Vendor | Cisco | Juniper | Nokia/ALU | Arista | Huawei | 563 +-----------+-------+---------+-----------+--------+--------+ 564 | Cisco | N/A | | | | | 565 | Juniper | | N/A | | | | 566 | Nokia/ALU | | | N/A | | | 567 | Arista | | | | N/A | | 568 | Huawei | | | | | N/A | 569 +-----------+-------+---------+-----------+--------+--------+ 571 Table 2: Vendor Interop 573 Authors' Addresses 575 Gyan Mishra 576 Verizon Inc. 578 Email: gyan.s.mishra@verizon.com 580 Mankamana Mishra 581 Cisco Systems 582 821 Alder Drive, 583 MILPITAS CALIFORNIA 95035 585 Email: mankamis@cisco.com 587 Jeff Tantsura 588 Apstra, Inc. 590 Email: jefftant.ietf@gmail.com 592 Lili Wang 593 Juniper Networks, Inc. 594 10 Technology Park Drive, 595 Westford MA 01886 596 US 598 Email: liliw@juniper.net 600 Qing Yang 601 Arista Networks 603 Email: qyang@arista.com 605 Adam Simpson 606 Nokia 608 Email: adam.1.simpson@nokia.com 610 Shuanglong Chen 611 Huawei Technologies 613 Email: chenshuanglong@huawei.com