idnits 2.17.1 draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-04.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 (October 29, 2020) is 1273 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == 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 (~~), 2 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: Standards Track M. Mishra 5 Expires: May 2, 2021 Cisco Systems 6 J. Tantsura 7 Apstra, Inc. 8 October 29, 2020 10 IPv4 NLRI with IPv6 Next Hop Use Cases 11 draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-04 13 Abstract 15 As Enterprises and Service Providers upgrade their brown field or 16 green field MPLS/SR core to an IPv6 transport such as MPLS LDPv6, SR- 17 MPLSv6 or SRv6, Multiprotocol BGP (MP-BGP)now plays an important role 18 in the transition of the core from IPv4 to IPv6 being able to 19 continue to support legacy IPv4, VPN-IPv4, and Multicast VPN IPv4 20 customers. 22 Multiprotocol BGP (MP-BGP) specifies that the set of usable next-hop 23 address families is determined by the Address Family Identifier (AFI) 24 and the Subsequent Address Family Identifier (SAFI). Historically 25 the AFI/SAFI definitions for the IPv4 address family only have 26 provisions for advertising a Next Hop address that belongs to the 27 IPv4 protocol when advertising IPv4 or VPN-IPv4 Network Layer 28 Reachability Information (NLRI). [RFC5549] specifies the extensions 29 necessary to allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next 30 Hop address that belongs to the IPv6 protocol. This comprises an 31 extension of the AFI/SAFI definitions to allow the address of the 32 Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 33 Protocol. [RFC5549] defines the encoding of the Next Hop to 34 determine which of the protocols the address actually belongs to, and 35 a new BGP Capability allowing MP-BGP Peers to dynamically discover 36 whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 37 Next Hop. 39 With this new MP-BGP capability exchange allows the BGP peering 40 session to act as a pure transport to allow the session to carry 41 Address Family Identifier (AFI) and the Subsequent Address Family 42 Identifier (SAFI) for both IPv4 and IPv6. 44 This document describes the critical use case and OPEX savings of 45 being able to leverage the MP-BGP capability exchange usage as a pure 46 transport allowing both IPv4 and IPv6 to be carried over the same BGP 47 TCP session. By doing so, allows for the elimination of Dual 48 Stacking on the PE-CE connections making the peering IPv6-ONLY to now 49 carry both IPv4 and IPv6 Network Layer Reachability Information 50 (NLRI). This document also provides a possible solution for IXPs 51 (Internet Exchange points) that are facing IPv4 address depletion at 52 these peering points to use BGP-MP capability exchange defined in 53 [RFC5549] to carry IPv4 (Network Layer Reachability Information) NLRI 54 in an IPv6 next hop using the [RFC5565] softwire mesh framework. 56 Status of This Memo 58 This Internet-Draft is submitted in full conformance with the 59 provisions of BCP 78 and BCP 79. 61 Internet-Drafts are working documents of the Internet Engineering 62 Task Force (IETF). Note that other groups may also distribute 63 working documents as Internet-Drafts. The list of current Internet- 64 Drafts is at https://datatracker.ietf.org/drafts/current/. 66 Internet-Drafts are draft documents valid for a maximum of six months 67 and may be updated, replaced, or obsoleted by other documents at any 68 time. It is inappropriate to use Internet-Drafts as reference 69 material or to cite them other than as "work in progress." 71 This Internet-Draft will expire on May 2, 2021. 73 Copyright Notice 75 Copyright (c) 2020 IETF Trust and the persons identified as the 76 document authors. All rights reserved. 78 This document is subject to BCP 78 and the IETF Trust's Legal 79 Provisions Relating to IETF Documents 80 (https://trustee.ietf.org/license-info) in effect on the date of 81 publication of this document. Please review these documents 82 carefully, as they describe your rights and restrictions with respect 83 to this document. Code Components extracted from this document must 84 include Simplified BSD License text as described in Section 4.e of 85 the Trust Legal Provisions and are provided without warranty as 86 described in the Simplified BSD License. 88 Table of Contents 90 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 91 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 92 3. Extension of AFI/SAFI Definitions for the IPv4 Address Family 6 93 4. Use of BGP Capability Advertisement . . . . . . . . . . . . . 7 94 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 9 95 6. Softwire Framework Use Cases of IPv4 NLRI with IPv6 Next Hop 10 96 6.1. VPN-IPv4 over MPLS LDPv6 or SRv6 Core . . . . . . . . . . 10 97 6.2. IPv4 VPN multicast over MPLS LDPv6 or SRv6 Core . . . . . 11 98 6.3. IPv4 Islands over MPLS LDPv6 or SRv6 Core . . . . . . . . 12 99 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 100 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 101 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 102 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 103 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 104 10.2. Informative References . . . . . . . . . . . . . . . . . 14 105 Appendix A. IPv4 NLRI IPv6 Next Hop Vendor Testing . . . . . . . 15 106 A.1. Router and Switch Vendors Support and Interoperability 107 Test Results. . . . . . . . . . . . . . . . . . . . . . . 15 108 A.2. White Box Vendors Support and Interoperability Test 109 Results. . . . . . . . . . . . . . . . . . . . . . . . . 16 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 112 1. Introduction 114 As Enterprises and Service Providers upgrade their brown field or 115 green field MPLS/SR core to an IPv6 transport such as MPLS LDPv6, SR- 116 MPLSv6 or SRv6, Multiprotocol BGP (MP-BGP)now plays an important role 117 in the transition of the core from IPv4 to IPv6, and being able to 118 continue to support legacy IPv4, VPN-IPv4, and Multicast VPN IPv4 119 customers. 121 IXPs (Internet Exchange points) are also facing IPv4 address 122 depletion at their peering points, which are large Layer 2 transit 123 backbones that service providers peer and exchange IPv4 and IPv6 124 (Network Layer Reachability Information) NLRI. Today these transit 125 exchange points are dual stacked. One proposal to solve this issue 126 is to use [RFC5549] to carry IPv4 (Network Layer Reachability 127 Information) NLRI in an IPv6 next hop and eliminate the IPv4 peering 128 completely using the concept of [RFC5565] softwire mesh framework. 129 So now with the MP-BGP reach capability exchanged over IPv4 AFI over 130 IPv6 next hop peer we can now advertise IPv4(Network Layer 131 Reachability Information) NLRI over IPv6 peering using the [RFC5565] 132 softwire mesh framework. 134 Multiprotocol BGP (MP-BGP) [RFC4760] specifies that the set of 135 network-layer protocols to which the address carried in the Next Hop 136 field may belong is determined by the Address Family Identifier (AFI) 137 and the Subsequent Address Family Identifier (SAFI). A number of 138 existing AFI/SAFIs allow the Next Hop address to belong to a 139 different address family than the Network Layer Reachability 140 Information (NLRI). 142 For example, the AFI/SAFI <25/65> used (as per [RFC6074]) to perform 143 L2VPN auto-discovery, allows advertising NLRI that contains the 144 identifier of a Virtual Private LAN Service (VPLS) instance or that 145 identifies a particular pool of attachment circuits at a given 146 Provider Edge (PE), while the Next Hop field contains the loopback 147 address of a PE. Similarly, the AFI/SAFI <1/132> (defined in 148 [RFC4684]) to advertise Route Target (RT) membership information, 149 allows advertising NLRI that contains such RT membership information, 150 while the Next Hop field contains the address of the advertising 151 router. 153 Furthermore, a number of these existing AFI/SAFIs allow the Next Hop 154 to belong to either the IPv4 Network Layer Protocol or the IPv6 155 Network Layer Protocol, and specify the encoding of the Next Hop 156 information to determine which of the protocols the address actually 157 belongs to. For example, [RFC4684] allows the Next Hop address to be 158 either IPv4 or IPv6 and states that the Next Hop field address shall 159 be interpreted as an IPv4 address whenever the length of Next Hop 160 address is 4 octets, and as an IPv6 address whenever the length of 161 the Next Hop address is 16 octets. 163 There are situations such as those described in [RFC4925] and in 164 [RFC5565] where carriers (or large enterprise networks acting as 165 carrier for their internal resources) may be required to establish 166 connectivity between 'islands' of networks of one address family type 167 across a transit core of a differing address family type. This 168 includes both the case of IPv6 islands across an IPv4 core and the 169 case of IPv4 islands across an IPv6 core. Where Multiprotocol BGP 170 (MP-BGP) is used to advertise the corresponding reachability 171 information, this translates into the requirement for a BGP speaker 172 to advertise Network Layer Reachability Information (NLRI) of a given 173 address family via a Next Hop of a different address family (i.e., 174 IPv6 NLRI with IPv4 Next Hop and IPv4 NLRI with IPv6 Next Hop). 176 The current AFI/SAFI definitions for the IPv6 address family assume 177 that the Next Hop address belongs to the IPv6 address family type. 178 Specifically, as per [RFC2545] and [RFC8277], when the is 179 <2/1>, <2/2>, or <2/4>, the Next Hop address is assumed to be of IPv6 180 type. As per [RFC4659], when the is <2/128>, the Next Hop 181 address is assumed to be of IPv6-VPN type. 183 However, [RFC4798] and [RFC4659] specify how an IPv4 address can be 184 encoded inside the Next Hop IPv6 address field when IPv6 NLRI needs 185 to be advertised with an IPv4 Next Hop. [RFC4798] defines how the 186 IPv4-mapped IPv6 address format specified in the IPv6 addressing 187 architecture ([RFC4291]) can be used for that purpose when the is <2/1>, <2/2>, or <2/4>. [RFC4659] defines how the IPv4- 189 mapped IPv6 address format as well as a null Route Distinguisher can 190 be used for that purpose when the is <2/128>. Thus, there 191 are existing solutions for the advertisement of IPv6 NLRI with an 192 IPv4 Next Hop. 194 Similarly, the current AFI/SAFI definitions for advertisement of IPv4 195 NLRI or VPN-IPv4 NLRI assume that the Next Hop address belongs to the 196 IPv4 address family type. Specifically, as per [RFC4760] and 197 [RFC8277], when the is <1/1>, <1/2>, or <1/4>, the Next 198 Hop address is assumed to be of IPv4 type. As per [RFC4364], when 199 the is <1/128>, the Next Hop address is assumed to be of 200 VPN-IPv4 type. As per [RFC6513] and [RFC6514], when the 201 is <1/129>, the Next Hop address is assumed to be of VPN-IPv4 type. 202 There is clearly no generally applicable method for encoding an IPv6 203 address inside the IPv4 address field of the Next Hop. Hence, there 204 is currently no specified solution for advertising IPv4 or VPN-IPv4 205 NLRI with an IPv6 Next Hop. 207 A new specification for carrying IPv4 Network Layer Reachability 208 Information (NLRI) of a given address family via a Next Hop of a 209 different address family is now defined in [RFC5549], and specifies 210 the extensions necessary to do so. This comprises an extension of 211 the AFI/SAFI definitions to allow the address of the Next Hop for 212 IPv4 NLRI or VPN-IPv4 NLRI to belong to either the IPv4 or the IPv6 213 protocol, the encoding of the Next Hop information to determine which 214 of the protocols the address actually belongs to, and a new BGP 215 Capability allowing MP-BGP peers to dynamically discover whether they 216 can exchange IPv4 NLRI and VPN- IPv4 NLRI with an IPv6 Next Hop. 218 With the new extensions defined in [RFC5549] supporting Network Layer 219 Reachability Information (NLRI) and next hop address family mismatch, 220 the BGP peer session can now be treated as a pure transport and carry 221 both IPv4 and IPv6 NLRI at the PE-CE edge over a single IPv6 TCP 222 session. This allows for the elimination of dual stack from the PE- 223 CE peering point, and now allow the peering to be IPv6-ONLY. The 224 elimination of IPv4 on the PE-CE peering points translates into OPEX 225 expenditure savings of point-to-point infrastructure links as well as 226 /31 address space savings and administration and network management 227 of both IPv4 and IPv6 BGP peers. This reduction decreases the number 228 of PE-CE BGP peers by fifty percent, which is a tremendous cost 229 savings for all Enterprises and Service Providers. 231 While the savings exists at the PE-CE edge, on the core side PE to 232 Route Reflector peering carrying IPv4 <1/1>, VPN-IPV4 233 <1/128>, and Multicasat VPN <1/129>, the cost savings nets to a break 234 even to be the same as with an IPV4 Core carrying IPv6 NLRI IPV6 235 <2/1>, VPN-IPV6 <2/128>, and Multicasat VPN <2/129>. This document 236 also provides a possible solution for IXPs (Internet Exchange points) 237 that are facing IPv4 address depletion at these peering points to use 238 BGP-MP capability exchange defined in [RFC5549] to carry IPv4 239 (Network Layer Reachability Information) NLRI in an IPv6 next hop 240 using the [RFC5565] softwire mesh framework. 242 2. Requirements Language 244 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 245 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 246 "OPTIONAL" in this document are to be interpreted as described in BCP 247 14 [RFC2119] [RFC8174] when, and only when, they appear in all 248 capitals, as shown here. 250 3. Extension of AFI/SAFI Definitions for the IPv4 Address Family 252 As mentioned earlier, MP-BGP specifies that the set of usable next- 253 hop address families is determined by the Address Family Identifier 254 (AFI) and the Subsequent Address Family Identifier (SAFI). The 255 following current AFI/SAFI definitions for the IPv4 NLRI or VPN-IPv4 256 NLRI (<1/1>, <1/2>, <1/4>, <1/128> and <1/129>) only have provisions 257 for advertising a Next Hop address that belongs to the IPv4 protocol. 258 This document extends the definition of the AFI/SAFI for 259 advertisement of IPv4 NLRI and VPN-IPv4 NLRI to extend the set of 260 usable next-hop address families to include IPv6 in addition to IPv4. 262 Specifically, this document allows advertising with [RFC4760] of an 263 MP_REACH_NLRI with: 265 o AFI = 1 267 o SAFI = 1, 2, or 4 269 o Length of Next Hop Address = 16 or 32 271 o Next Hop Address = IPv6 address of next hop (potentially followed 272 by the link-local IPv6 address of the next hop). This field is to 273 be constructed as per Section 3 of [RFC2545]. 275 o NLRI= NLRI as per current AFI/SAFI definition 277 It also allows advertising with [RFC4760] of an MP_REACH_NLRI with: 279 o AFI = 1 281 o SAFI = 128 or 129 283 o Length of Next Hop Address = 24 or 48 285 o Next Hop Address = VPN-IPv6 address of next hop with an 8-octet RD 286 set to zero (potentially followed by the link-local VPN-IPv6 287 address of the next hop with an 8-octet RD is set to zero). 289 o NLRI= NLRI as per current AFI/SAFI definition 290 This is in addition to the current mode of operation allowing 291 advertisement of NLRI for of <1/1>, <1/2> and <1/4> with a 292 next hop address of IPv4 type and advertisement of NLRI for of <1/128> and <1/129> with a next hop address of VPN-IPv4 294 type. 296 The BGP speaker receiving the advertisement MUST use the Length of 297 Next Hop Address field to determine which network-layer protocol the 298 next hop address belongs to. 300 o When the AFI/SAFI is <1/1>, <1/2> or <1/4> and when the Length of 301 Next Hop Address field is equal to 16 or 32, the next hop address 302 is of type IPv6. 304 o When the AFI/SAFI is <1/128>, or <1/129> and when the Length of 305 Next Hop Address field is equal to 24 or 48, the next hop address 306 is of type VPN-IPv6. 308 Note that this method of using the Length of the Next Hop Address 309 field to determine which network-layer protocol the next hop address 310 belongs to (out of the set of protocols allowed by the AFI/SAFI 311 definition) is the same as used in [RFC4684] and [RFC6074]. 313 4. Use of BGP Capability Advertisement 315 [RFC5492] defines a mechanism to allow two BGP speakers to discover 316 if a particular capability is supported by their BGP peer and thus 317 whether it can be used with that peer. This document defines a new 318 capability that can be advertised using [RFC5492] and that is 319 referred to as the Extended Next Hop Encoding capability. This 320 capability allows BGP speakers to discover whether, for a given NLRI 321 , a peer supports advertisement with a next hop whose 322 network protocol is determined by the value of the Length of Next Hop 323 Address field, as specified in Section 3. 325 A BGP speaker that wishes to advertise to a BGP peer an IPv6 Next Hop 326 for IPv4 NLRI or for VPN-IPv4 NLRI as per this specification MUST use 327 the Capability Advertisement procedures defined in [RFC5492] with the 328 Extended Next Hop Encoding Capability to determine whether its peer 329 supports this for the NLRI AFI/SAFI pair(s) of interest. The fields 330 in the Capabilities Optional Parameter MUST be set as follows: 332 o The Capability Code field MUST be set to 5 (which indicates the 333 Extended Next Hop Encoding capability). 335 o The Capability Length field is set to a variable value that is the 336 length of the Capability Value field (which follows). 338 o The Capability Value field has the following format: 340 +-----------------------------------------------------+ 341 | NLRI AFI - 1 (2 octets) | 342 +-----------------------------------------------------+ 343 | NLRI SAFI - 1 (2 octets) | 344 +-----------------------------------------------------+ 345 | Nexthop AFI - 1 (2 octets) | 346 +-----------------------------------------------------+ 347 | ..... | 348 +-----------------------------------------------------+ 349 | NLRI AFI - N (2 octets) | 350 +-----------------------------------------------------+ 351 | NLRI SAFI - N (2 octets) | 352 +-----------------------------------------------------+ 353 | Nexthop AFI - N (2 octets) | 354 +-----------------------------------------------------+ 356 where: 358 * each triple indicates that 359 NLRI of may be advertised with a Next 360 Hop address belonging to the network-layer protocol of Nexthop 361 AFI. 363 * the AFI and SAFI values are defined in the Address Family 364 Identifier and Subsequent Address Family Identifier registries 365 maintained by IANA. 367 Since this document only concerns itself with the advertisement of 368 IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop, this specification 369 only allows the following values in the Capability Value field of the 370 Extended Next Hop Encoding capability: 372 o NLRI AFI = 1 (IPv4) 374 o NLRI SAFI = 1, 2, 4, 128 or 129 376 o Nexthop AFI = 2 (IPv6) 378 This document does not specify the use of the Extended Next Hop 379 Encoding capability with any other combinations of . For example, the Next Hop Encoding capability 381 specified in this document is not intended to be used for NLRI AFI/ 382 SAFIs whose definition already allows use of both IPv4 and IPv6 next 383 hops (e.g., AFI/SAFI = <1/132> as defined in [RFC4684]). Similarly, 384 it is not intended that the Extended Next Hop Encoding capability be 385 used for NLRI AFI/SAFIs for which there is already solution for 386 advertising a next hop of a different address family (e.g., AFI/SAFI 387 = <2/1>, <2/2>, or <2/4> with IPv4 Next Hop as per [RFC4798] and AFI/ 388 SAFI = <2/128> with IPv4 Next Hop as per [RFC4659]). 390 It is expected that if new AFI/SAFIs are defined in the future, their 391 definition will have provisions (where appropriate) for both IPv4 and 392 IPv6 Next Hops from the onset, with determination based on Length of 393 Next Hop Address field. Thus, new AFI/SAFIs are not expected to make 394 use of the Extended Next Hop Encoding capability. 396 A BGP speaker MUST only advertise to a BGP peer the IPv4 or VPN-IPv4 397 NLRI with an IPv6 Next Hop if the BGP speaker has first ascertained 398 via BGP Capability Advertisement that the BGP peer supports the 399 Extended Next Hop Encoding capability for the relevant AFI/SAFI pair. 401 The Extended Next Hop Encoding capability provides information about 402 next hop encoding for a given AFI/SAFI, assuming that AFI/SAFI is 403 allowed. It does not influence whether that AFI/SAFI is indeed 404 allowed. Whether a AFI/SAFI can be used between the BGP peers is 405 purely determined through the Multiprotocol Extensions capability 406 defined in [RFC4760]. 408 The Extended Next Hop Encoding capability MAY be dynamically updated 409 through the use of the Dynamic Capability capability and associated 410 mechanisms defined in [I-D.ietf-idr-dynamic-cap]. 412 5. Operations 414 As Enterprises and Service Providers migrate their IPv4 core to an 415 MPLS LDPv6 or SRv6 transport, they must continue to be able to 416 support legacy IPv4 customers. With the new extensions defined in 417 [RFC4760], supporting Network Layer Reachability Information (NLRI) 418 and next hop address family mismatch, the BGP peer session can now be 419 treated as a pure transport and carry both IPv4 and IPv6 NLRI at the 420 PE-CE edge. This paves the way to now eliminate dual stacking on all 421 PE-CE peering points to customers making the peering IPv6 only. With 422 this change all IPv4 and IPv6 Network Layer Reachability Information 423 (NLRI) will now be carried over a single BGP session. This also 424 solves the dual stack issue with IXP (Internet Exchange Points) 425 having to maintain separate peering for both IPv4 and IPv6. From an 426 operations perspective the PE-CE edge peering will be drastically 427 simplified with the elimination of IPv4 peers yielding a reduction of 428 peers by 50 percent. From an operations perspective prior to 429 elimination of IPv4 peers an audit is recommended to identify and 430 IPv4 and IPv6 peering incongruencies that may exist and to rectify 431 prior to elimination of the IPv4 peers. No operational impacts or 432 issues are expected with this change. 434 When a next hop address needs to be passed along unchanged (e.g., as 435 a Route Reflector (RR) would do), its encoding MUST NOT be changed. 436 If a particular RR client cannot handle that encoding (as determined 437 by the BGP Capability Advertisement), then the NLRI in question 438 cannot be distributed to that client. For sound routing in certain 439 scenarios, this will require that all the RR clients be able to 440 handle whatever encodings any of them may generate. 442 6. Softwire Framework Use Cases of IPv4 NLRI with IPv6 Next Hop 444 6.1. VPN-IPv4 over MPLS LDPv6 or SRv6 Core 446 The new MP-BGP extensions defined in [RFC5549] is used to support 447 IPV4 VPNs over an IPv6 MPLS LDPv6 or SRv6 backbone. In this scenario 448 the PE routers would advertise and receive VPN-IPv4 NLRI in the 449 MP_REACH_NLRI along with an IPv6 Next Hop from the Route Reflector 450 (RR). 452 MP-BGP Reach Pseudo code: 454 If ((Update AFI == VPN-IPv4) 456 and (Length of next hop == 24 Bytes || 48 Bytes)) 458 { 460 This is an VPN-IPv4 route, but 462 with an IPv6 next hop; 464 } 466 The MP_REACH_NLRI is encoded with: 468 o AFI = 1 470 o SAFI = 128 472 o Length of Next Hop Network Address = 24 (or 48) 474 o Network Address of Next Hop = VPN-IPv6 address of Next Hop whose 475 RD is set to zero 477 o NLRI = IPv4-VPN routes 478 During BGP Capability Advertisement, the PE routers would include the 479 following fields in the Capabilities Optional Parameter: 481 o Capability Code set to "Extended Next Hop Encoding" 483 o Capability Value containing 486 6.2. IPv4 VPN multicast over MPLS LDPv6 or SRv6 Core 488 The new MP-BGP extensions defined in [RFC8126] is used to support 489 IPV4 Multicast VPNs over an MPLS LDPv6 or SRv6 backbone. In this 490 scenario, the PE routers would advertise and receive VPN-IPv4 NLRI in 491 the MP_REACH_NLRI along with an IPv6 Next Hop from the Route 492 Reflector (RR). 494 MP-BGP Reach Pseudo code: 496 If ((Update AFI == MVPN-IPv4) 498 and (Length of next hop == 24 Bytes || 48 Bytes)) 500 { 502 This is an MVPN-IPv4 route, but 504 with an IPv6 next hop; 506 } 508 The MP_REACH_NLRI is encoded with: 510 o AFI = 1 512 o SAFI = 129 514 o Length of Next Hop Network Address = 24 (or 48) 516 o Network Address of Next Hop = VPN-IPv6 address of Next Hop whose 517 RD is set to zero 519 o NLRI = IPv4-VPN routes 521 During BGP Capability Advertisement, the PE routers would include the 522 following fields in the Capabilities Optional Parameter: 524 o Capability Code set to "Extended Next Hop Encoding" 525 o Capability Value containing 528 6.3. IPv4 Islands over MPLS LDPv6 or SRv6 Core 530 The new MP-BGP extensions defined in [RFC5549] is used to support 531 IPV4 islands over an IPv6 MPLS LDPv6 or SRv6 backbone. In this 532 scenario the PE routers would use BGP labeled unicast address family 533 (BGP-LU) to advertise BGP with label binding and receive labeled IPv4 534 NLRI in the MP_REACH_NLRI along with an IPv6 Next Hop from the Route 535 Reflector (RR). 537 MP-BGP Reach Pseudo code: 539 If ((Update AFI == IPv4) 541 and (Length of next hop == 16 Bytes || 32 Bytes)) 543 { 545 This is an IPv4 route, but 547 with an IPv6 next hop; 549 } 551 The MP_REACH_NLRI is encoded with: 553 o AFI = 1 555 o SAFI = 1 557 o Length of Next Hop Network Address = 16 (or 32) 559 o Network Address of Next Hop = IPv6 address of Next Hop whose RD is 560 set to zero 562 o NLRI = IPv4-VPN routes 564 During BGP Capability Advertisement, the PE routers would include the 565 following fields in the Capabilities Optional Parameter: 567 o Capability Code set to "Extended Next Hop Encoding" 569 o Capability Value containing 572 7. IANA Considerations 574 There are not any IANA considerations. 576 8. Security Considerations 578 The extensions defined in this document allow BGP to propagate 579 reachability information about IPv6 routes over an MPLS IPv4 core 580 network. As such, no new security issues are raised beyond those 581 that already exist in BGP-4 and use of MP-BGP for IPv6. The security 582 features of BGP and corresponding security policy defined in the ISP 583 domain are applicable. For the inter-AS distribution of IPv6 routes 584 according to case (a) of Section 4 of this document, no new security 585 issues are raised beyond those that already exist in the use of eBGP 586 for IPv6 [RFC2545]. 588 9. Acknowledgments 590 10. References 592 10.1. Normative References 594 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 595 Requirement Levels", BCP 14, RFC 2119, 596 DOI 10.17487/RFC2119, March 1997, 597 . 599 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 600 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 601 DOI 10.17487/RFC2545, March 1999, 602 . 604 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 605 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 606 2006, . 608 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 609 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 610 2006, . 612 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 613 "Multiprotocol Extensions for BGP-4", RFC 4760, 614 DOI 10.17487/RFC4760, January 2007, 615 . 617 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 618 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 619 2009, . 621 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 622 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 623 May 2017, . 625 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 626 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 627 . 629 10.2. Informative References 631 [I-D.ietf-idr-dynamic-cap] 632 Ramachandra, S. and E. Chen, "Dynamic Capability for BGP- 633 4", draft-ietf-idr-dynamic-cap-14 (work in progress), 634 December 2011. 636 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 637 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 638 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 639 . 641 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 642 R., Patel, K., and J. Guichard, "Constrained Route 643 Distribution for Border Gateway Protocol/MultiProtocol 644 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 645 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 646 November 2006, . 648 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 649 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 650 Provider Edge Routers (6PE)", RFC 4798, 651 DOI 10.17487/RFC4798, February 2007, 652 . 654 [RFC4925] Li, X., Ed., Dawkins, S., Ed., Ward, D., Ed., and A. 655 Durand, Ed., "Softwire Problem Statement", RFC 4925, 656 DOI 10.17487/RFC4925, July 2007, 657 . 659 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 660 Layer Reachability Information with an IPv6 Next Hop", 661 RFC 5549, DOI 10.17487/RFC5549, May 2009, 662 . 664 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 665 Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, 666 . 668 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 669 "Provisioning, Auto-Discovery, and Signaling in Layer 2 670 Virtual Private Networks (L2VPNs)", RFC 6074, 671 DOI 10.17487/RFC6074, January 2011, 672 . 674 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 675 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 676 2012, . 678 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 679 Encodings and Procedures for Multicast in MPLS/BGP IP 680 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 681 . 683 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 684 Writing an IANA Considerations Section in RFCs", BCP 26, 685 RFC 8126, DOI 10.17487/RFC8126, June 2017, 686 . 688 Appendix A. IPv4 NLRI IPv6 Next Hop Vendor Testing 690 IPv4 NLRI with IPv6 Next Hop encoding is supported for all BGP peers 691 both iBGP and eBGP. 693 This section details the vendor support and interoperability test 694 results for router and switch vendors as well as White Box vendors. 696 A.1. Router and Switch Vendors Support and Interoperability Test 697 Results. 699 +-----------------+----------+------------------+ 700 | | Supports | Interoperability | 701 +-----------------+----------+------------------+ 702 | Alcatel-Lucent | | | 703 | Arista | | | 704 | Cisco | *** | | 705 | Ericsson | | | 706 | Extremenetworks | | | 707 | HP | | | 708 | Huawei | | | 709 | Juniper | | | 710 +-----------------+----------+------------------+ 712 Table 1: Vendor Interop 714 A.2. White Box Vendors Support and Interoperability Test Results. 716 +----------------------------+----------+------------------+ 717 | | Supports | Interoperability | 718 +----------------------------+----------+------------------+ 719 | Cumulus Networks | | | 720 | PICA8 | | | 721 | Pluribus Networks Netvisor | | | 722 +----------------------------+----------+------------------+ 724 Table 2: White Box Vendor Interop 726 Authors' Addresses 728 Gyan Mishra 729 Verizon Inc. 731 Email: gyan.s.mishra@verizon.com 733 Mankamana Mishra 734 Cisco Systems 735 821 Alder Drive, 736 MILPITAS CALIFORNIA 95035 738 Email: mankamis@cisco.com 740 Jeff Tantsura 741 Apstra, Inc. 743 Email: jefftant.ietf@gmail.com