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