idnits 2.17.1 draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-01.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 (July 12, 2020) is 1381 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 July 12, 2020 5 Expires: January 13, 2021 7 IPv4 NLRI with IPv6 Next Hop Use Cases 8 draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-01 10 Abstract 12 As Enterprises and Service Providers upgrade their brown field or 13 green field MPLS/SR core to an IPv6 transport such as MPLS LDPv6, SR- 14 MPLSv6 or SRv6, Multiprotocol BGP (MP-BGP)now plays an important role 15 in the transition of the core from IPv4 to IPv6 being able to 16 continue to support legacy IPv4, VPN-IPv4, and Multicast VPN IPv4 17 customers. 19 Multiprotocol BGP (MP-BGP) specifies that the set of usable next-hop 20 address families is determined by the Address Family Identifier (AFI) 21 and the Subsequent Address Family Identifier (SAFI). Historically 22 the AFI/SAFI definitions for the IPv4 address family only have 23 provisions for advertising a Next Hop address that belongs to the 24 IPv4 protocol when advertising IPv4 or VPN-IPv4 Network Layer 25 Reachability Information (NLRI). [RFC5549] specifies the extensions 26 necessary to allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next 27 Hop address that belongs to the IPv6 protocol. This comprises an 28 extension of the AFI/SAFI definitions to allow the address of the 29 Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 30 Protocol. [RFC5549] defines the encoding of the Next Hop to 31 determine which of the protocols the address actually belongs to, and 32 a new BGP Capability allowing MP-BGP Peers to dynamically discover 33 whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 34 Next Hop. 36 With this new MP-BGP capability exchange allows the BGP peering 37 session to act as a pure transport to allow the session to carry 38 Address Family Identifier (AFI) and the Subsequent Address Family 39 Identifier (SAFI) for both IPv4 and IPv6. 41 This document describes the critical use case and OPEX savings of 42 being able to leverage the MP-BGP capability exchange usage as a pure 43 transport allowing both IPv4 and IPv6 to be carried over the same BGP 44 TCP session. By doing so, allows for the elimination of Dual 45 Stacking on the PE-CE connections making the peering IPv6-ONLY to now 46 carry both IPv4 and IPv6 Network Layer Reachability Information 47 (NLRI). This document also provides a possible solution for IXPs 48 (Internet Exchange points) that are facing IPv4 address depletion at 49 these peering points to use BGP-MP capability exchange defined in 50 [RFC5549] to carry IPv4 (Network Layer Reachability Information) NLRI 51 in an IPv6 next hop using the [RFC5565] softwire mesh framework. 53 Status of This Memo 55 This Internet-Draft is submitted in full conformance with the 56 provisions of BCP 78 and BCP 79. 58 Internet-Drafts are working documents of the Internet Engineering 59 Task Force (IETF). Note that other groups may also distribute 60 working documents as Internet-Drafts. The list of current Internet- 61 Drafts is at https://datatracker.ietf.org/drafts/current/. 63 Internet-Drafts are draft documents valid for a maximum of six months 64 and may be updated, replaced, or obsoleted by other documents at any 65 time. It is inappropriate to use Internet-Drafts as reference 66 material or to cite them other than as "work in progress." 68 This Internet-Draft will expire on January 13, 2021. 70 Copyright Notice 72 Copyright (c) 2020 IETF Trust and the persons identified as the 73 document authors. All rights reserved. 75 This document is subject to BCP 78 and the IETF Trust's Legal 76 Provisions Relating to IETF Documents 77 (https://trustee.ietf.org/license-info) in effect on the date of 78 publication of this document. Please review these documents 79 carefully, as they describe your rights and restrictions with respect 80 to this document. Code Components extracted from this document must 81 include Simplified BSD License text as described in Section 4.e of 82 the Trust Legal Provisions and are provided without warranty as 83 described in the Simplified BSD License. 85 Table of Contents 87 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 88 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 89 3. Extension of AFI/SAFI Definitions for the IPv4 Address Family 6 90 4. Use of BGP Capability Advertisement . . . . . . . . . . . . . 7 91 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 9 92 6. Softwire Framework Use Cases of IPv4 NLRI with IPv6 Next Hop 10 93 6.1. VPN-IPv4 over MPLS LDPv6 or SRv6 Core . . . . . . . . . . 10 94 6.2. IPv4 VPN multicast over MPLS LDPv6 or SRv6 Core . . . . . 11 95 6.3. IPv4 Islands over MPLS LDPv6 or SRv6 Core . . . . . . . . 12 96 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 97 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 98 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 99 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 100 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 101 10.2. Informative References . . . . . . . . . . . . . . . . . 14 102 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 104 1. Introduction 106 As Enterprises and Service Providers upgrade their brown field or 107 green field MPLS/SR core to an IPv6 transport such as MPLS LDPv6, SR- 108 MPLSv6 or SRv6, Multiprotocol BGP (MP-BGP)now plays an important role 109 in the transition of the core from IPv4 to IPv6, and being able to 110 continue to support legacy IPv4, VPN-IPv4, and Multicast VPN IPv4 111 customers. 113 IXPs (Internet Exchange points) are also facing IPv4 address 114 depletion at their peering points, which are large Layer 2 transit 115 backbones that service providers peer and exchange IPv4 and IPv6 116 (Network Layer Reachability Information) NLRI. Today these transit 117 exchange points are dual stacked. One proposal to solve this issue 118 is to use [RFC5549] to carry IPv4 (Network Layer Reachability 119 Information) NLRI in an IPv6 next hop and eliminate the IPv4 peering 120 completely using the concept of [RFC5565] softwire mesh framework. 121 So now with the MP-BGP reach capability exchanged over IPv4 AFI over 122 IPv6 next hop peer we can now advertise IPv4(Network Layer 123 Reachability Information) NLRI over IPv6 peering using the [RFC5565] 124 softwire mesh framework. 126 Multiprotocol BGP (MP-BGP) [RFC4760] specifies that the set of 127 network-layer protocols to which the address carried in the Next Hop 128 field may belong is determined by the Address Family Identifier (AFI) 129 and the Subsequent Address Family Identifier (SAFI). A number of 130 existing AFI/SAFIs allow the Next Hop address to belong to a 131 different address family than the Network Layer Reachability 132 Information (NLRI). 134 For example, the AFI/SAFI <25/65> used (as per [RFC6074]) to perform 135 L2VPN auto-discovery, allows advertising NLRI that contains the 136 identifier of a Virtual Private LAN Service (VPLS) instance or that 137 identifies a particular pool of attachment circuits at a given 138 Provider Edge (PE), while the Next Hop field contains the loopback 139 address of a PE. Similarly, the AFI/SAFI <1/132> (defined in 140 [RFC4684]) to advertise Route Target (RT) membership information, 141 allows advertising NLRI that contains such RT membership information, 142 while the Next Hop field contains the address of the advertising 143 router. 145 Furthermore, a number of these existing AFI/SAFIs allow the Next Hop 146 to belong to either the IPv4 Network Layer Protocol or the IPv6 147 Network Layer Protocol, and specify the encoding of the Next Hop 148 information to determine which of the protocols the address actually 149 belongs to. For example, [RFC4684] allows the Next Hop address to be 150 either IPv4 or IPv6 and states that the Next Hop field address shall 151 be interpreted as an IPv4 address whenever the length of Next Hop 152 address is 4 octets, and as an IPv6 address whenever the length of 153 the Next Hop address is 16 octets. 155 There are situations such as those described in [RFC4925] and in 156 [RFC5565] where carriers (or large enterprise networks acting as 157 carrier for their internal resources) may be required to establish 158 connectivity between 'islands' of networks of one address family type 159 across a transit core of a differing address family type. This 160 includes both the case of IPv6 islands across an IPv4 core and the 161 case of IPv4 islands across an IPv6 core. Where Multiprotocol BGP 162 (MP-BGP) is used to advertise the corresponding reachability 163 information, this translates into the requirement for a BGP speaker 164 to advertise Network Layer Reachability Information (NLRI) of a given 165 address family via a Next Hop of a different address family (i.e., 166 IPv6 NLRI with IPv4 Next Hop and IPv4 NLRI with IPv6 Next Hop). 168 The current AFI/SAFI definitions for the IPv6 address family assume 169 that the Next Hop address belongs to the IPv6 address family type. 170 Specifically, as per [RFC2545] and [RFC8277], when the is 171 <2/1>, <2/2>, or <2/4>, the Next Hop address is assumed to be of IPv6 172 type. As per [RFC4659], when the is <2/128>, the Next Hop 173 address is assumed to be of IPv6-VPN type. 175 However, [RFC4798] and [RFC4659] specify how an IPv4 address can be 176 encoded inside the Next Hop IPv6 address field when IPv6 NLRI needs 177 to be advertised with an IPv4 Next Hop. [RFC4798] defines how the 178 IPv4-mapped IPv6 address format specified in the IPv6 addressing 179 architecture ([RFC4291]) can be used for that purpose when the is <2/1>, <2/2>, or <2/4>. [RFC4659] defines how the IPv4- 181 mapped IPv6 address format as well as a null Route Distinguisher can 182 be used for that purpose when the is <2/128>. Thus, there 183 are existing solutions for the advertisement of IPv6 NLRI with an 184 IPv4 Next Hop. 186 Similarly, the current AFI/SAFI definitions for advertisement of IPv4 187 NLRI or VPN-IPv4 NLRI assume that the Next Hop address belongs to the 188 IPv4 address family type. Specifically, as per [RFC4760] and 189 [RFC8277], when the is <1/1>, <1/2>, or <1/4>, the Next 190 Hop address is assumed to be of IPv4 type. As per [RFC4364], when 191 the is <1/128>, the Next Hop address is assumed to be of 192 VPN-IPv4 type. As per [RFC6513] and [RFC6514], when the 193 is <1/129>, the Next Hop address is assumed to be of VPN-IPv4 type. 194 There is clearly no generally applicable method for encoding an IPv6 195 address inside the IPv4 address field of the Next Hop. Hence, there 196 is currently no specified solution for advertising IPv4 or VPN-IPv4 197 NLRI with an IPv6 Next Hop. 199 A new specification for carrying IPv4 Network Layer Reachability 200 Information (NLRI) of a given address family via a Next Hop of a 201 different address family is now defined in [RFC5549], and specifies 202 the extensions necessary to do so. This comprises an extension of 203 the AFI/SAFI definitions to allow the address of the Next Hop for 204 IPv4 NLRI or VPN-IPv4 NLRI to belong to either the IPv4 or the IPv6 205 protocol, the encoding of the Next Hop information to determine which 206 of the protocols the address actually belongs to, and a new BGP 207 Capability allowing MP-BGP peers to dynamically discover whether they 208 can exchange IPv4 NLRI and VPN- IPv4 NLRI with an IPv6 Next Hop. 210 With the new extensions defined in [RFC5549] supporting Network Layer 211 Reachability Information (NLRI) and next hop address family mismatch, 212 the BGP peer session can now be treated as a pure transport and carry 213 both IPv4 and IPv6 NLRI at the PE-CE edge over a single IPv6 TCP 214 session. This allows for the elimination of dual stack from the PE- 215 CE peering point, and now allow the peering to be IPv6-ONLY. The 216 elimination of IPv4 on the PE-CE peering points translates into OPEX 217 expenditure savings of point-to-point infrastructure links as well as 218 /31 address space savings and administration and network management 219 of both IPv4 and IPv6 BGP peers. This reduction decreases the number 220 of PE-CE BGP peers by fifty percent, which is a tremendous cost 221 savings for all Enterprises and Service Providers. 223 While the savings exists at the PE-CE edge, on the core side PE to 224 Route Reflector peering carrying IPv4 <1/1>, VPN-IPV4 225 <1/128>, and Multicasat VPN <1/129>, the cost savings nets to a break 226 even to be the same as with an IPV4 Core carrying IPv6 NLRI IPV6 227 <2/1>, VPN-IPV6 <2/128>, and Multicasat VPN <2/129>. This document 228 also provides a possible solution for IXPs (Internet Exchange points) 229 that are facing IPv4 address depletion at these peering points to use 230 BGP-MP capability exchange defined in [RFC5549] to carry IPv4 231 (Network Layer Reachability Information) NLRI in an IPv6 next hop 232 using the [RFC5565] softwire mesh framework. 234 2. Requirements Language 236 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 237 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 238 "OPTIONAL" in this document are to be interpreted as described in BCP 239 14 [RFC2119] [RFC8174] when, and only when, they appear in all 240 capitals, as shown here. 242 3. Extension of AFI/SAFI Definitions for the IPv4 Address Family 244 As mentioned earlier, MP-BGP specifies that the set of usable next- 245 hop address families is determined by the Address Family Identifier 246 (AFI) and the Subsequent Address Family Identifier (SAFI). The 247 following current AFI/SAFI definitions for the IPv4 NLRI or VPN-IPv4 248 NLRI (<1/1>, <1/2>, <1/4>, <1/128> and <1/129>) only have provisions 249 for advertising a Next Hop address that belongs to the IPv4 protocol. 250 This document extends the definition of the AFI/SAFI for 251 advertisement of IPv4 NLRI and VPN-IPv4 NLRI to extend the set of 252 usable next-hop address families to include IPv6 in addition to IPv4. 254 Specifically, this document allows advertising with [RFC4760] of an 255 MP_REACH_NLRI with: 257 o AFI = 1 259 o SAFI = 1, 2, or 4 261 o Length of Next Hop Address = 16 or 32 263 o Next Hop Address = IPv6 address of next hop (potentially followed 264 by the link-local IPv6 address of the next hop). This field is to 265 be constructed as per Section 3 of [RFC2545]. 267 o NLRI= NLRI as per current AFI/SAFI definition 269 It also allows advertising with [RFC4760] of an MP_REACH_NLRI with: 271 o AFI = 1 273 o SAFI = 128 or 129 275 o Length of Next Hop Address = 24 or 48 277 o Next Hop Address = VPN-IPv6 address of next hop with an 8-octet RD 278 set to zero (potentially followed by the link-local VPN-IPv6 279 address of the next hop with an 8-octet RD is set to zero). 281 o NLRI= NLRI as per current AFI/SAFI definition 283 This is in addition to the current mode of operation allowing 284 advertisement of NLRI for of <1/1>, <1/2> and <1/4> with a 285 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 287 type. 289 The BGP speaker receiving the advertisement MUST use the Length of 290 Next Hop Address field to determine which network-layer protocol the 291 next hop address belongs to. 293 o When the AFI/SAFI is <1/1>, <1/2> or <1/4> and when the Length of 294 Next Hop Address field is equal to 16 or 32, the next hop address 295 is of type IPv6. 297 o When the AFI/SAFI is <1/128>, or <1/129> and when the Length of 298 Next Hop Address field is equal to 24 or 48, the next hop address 299 is of type VPN-IPv6. 301 Note that this method of using the Length of the Next Hop Address 302 field to determine which network-layer protocol the next hop address 303 belongs to (out of the set of protocols allowed by the AFI/SAFI 304 definition) is the same as used in [RFC4684] and [RFC6074]. 306 4. Use of BGP Capability Advertisement 308 [RFC5492] defines a mechanism to allow two BGP speakers to discover 309 if a particular capability is supported by their BGP peer and thus 310 whether it can be used with that peer. This document defines a new 311 capability that can be advertised using [RFC5492] and that is 312 referred to as the Extended Next Hop Encoding capability. This 313 capability allows BGP speakers to discover whether, for a given NLRI 314 , a peer supports advertisement with a next hop whose 315 network protocol is determined by the value of the Length of Next Hop 316 Address field, as specified in Section 3. 318 A BGP speaker that wishes to advertise to a BGP peer an IPv6 Next Hop 319 for IPv4 NLRI or for VPN-IPv4 NLRI as per this specification MUST use 320 the Capability Advertisement procedures defined in [RFC5492] with the 321 Extended Next Hop Encoding Capability to determine whether its peer 322 supports this for the NLRI AFI/SAFI pair(s) of interest. The fields 323 in the Capabilities Optional Parameter MUST be set as follows: 325 o The Capability Code field MUST be set to 5 (which indicates the 326 Extended Next Hop Encoding capability). 328 o The Capability Length field is set to a variable value that is the 329 length of the Capability Value field (which follows). 331 o The Capability Value field has the following format: 333 +-----------------------------------------------------+ 334 | NLRI AFI - 1 (2 octets) | 335 +-----------------------------------------------------+ 336 | NLRI SAFI - 1 (2 octets) | 337 +-----------------------------------------------------+ 338 | Nexthop AFI - 1 (2 octets) | 339 +-----------------------------------------------------+ 340 | ..... | 341 +-----------------------------------------------------+ 342 | NLRI AFI - N (2 octets) | 343 +-----------------------------------------------------+ 344 | NLRI SAFI - N (2 octets) | 345 +-----------------------------------------------------+ 346 | Nexthop AFI - N (2 octets) | 347 +-----------------------------------------------------+ 349 where: 351 * each triple indicates that 352 NLRI of may be advertised with a Next 353 Hop address belonging to the network-layer protocol of Nexthop 354 AFI. 356 * the AFI and SAFI values are defined in the Address Family 357 Identifier and Subsequent Address Family Identifier registries 358 maintained by IANA. 360 Since this document only concerns itself with the advertisement of 361 IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop, this specification 362 only allows the following values in the Capability Value field of the 363 Extended Next Hop Encoding capability: 365 o NLRI AFI = 1 (IPv4) 367 o NLRI SAFI = 1, 2, 4, 128 or 129 369 o Nexthop AFI = 2 (IPv6) 371 This document does not specify the use of the Extended Next Hop 372 Encoding capability with any other combinations of . For example, the Next Hop Encoding capability 374 specified in this document is not intended to be used for NLRI AFI/ 375 SAFIs whose definition already allows use of both IPv4 and IPv6 next 376 hops (e.g., AFI/SAFI = <1/132> as defined in [RFC4684]). Similarly, 377 it is not intended that the Extended Next Hop Encoding capability be 378 used for NLRI AFI/SAFIs for which there is already solution for 379 advertising a next hop of a different address family (e.g., AFI/SAFI 380 = <2/1>, <2/2>, or <2/4> with IPv4 Next Hop as per [RFC4798] and AFI/ 381 SAFI = <2/128> with IPv4 Next Hop as per [RFC4659]). 383 It is expected that if new AFI/SAFIs are defined in the future, their 384 definition will have provisions (where appropriate) for both IPv4 and 385 IPv6 Next Hops from the onset, with determination based on Length of 386 Next Hop Address field. Thus, new AFI/SAFIs are not expected to make 387 use of the Extended Next Hop Encoding capability. 389 A BGP speaker MUST only advertise to a BGP peer the IPv4 or VPN-IPv4 390 NLRI with an IPv6 Next Hop if the BGP speaker has first ascertained 391 via BGP Capability Advertisement that the BGP peer supports the 392 Extended Next Hop Encoding capability for the relevant AFI/SAFI pair. 394 The Extended Next Hop Encoding capability provides information about 395 next hop encoding for a given AFI/SAFI, assuming that AFI/SAFI is 396 allowed. It does not influence whether that AFI/SAFI is indeed 397 allowed. Whether a AFI/SAFI can be used between the BGP peers is 398 purely determined through the Multiprotocol Extensions capability 399 defined in [RFC4760]. 401 The Extended Next Hop Encoding capability MAY be dynamically updated 402 through the use of the Dynamic Capability capability and associated 403 mechanisms defined in [I-D.ietf-idr-dynamic-cap]. 405 5. Operations 407 As Enterprises and Service Providers migrate their IPv4 core to an 408 MPLS LDPv6 or SRv6 transport, they must continue to be able to 409 support legacy IPv4 customers. With the new extensions defined in 410 [RFC4760], supporting Network Layer Reachability Information (NLRI) 411 and next hop address family mismatch, the BGP peer session can now be 412 treated as a pure transport and carry both IPv4 and IPv6 NLRI at the 413 PE-CE edge. This paves the way to now eliminate dual stacking on all 414 PE-CE peering points to customers making the peering IPv6 only. With 415 this change all IPv4 and IPv6 Network Layer Reachability Information 416 (NLRI) will now be carried over a single BGP session. This also 417 solves the dual stack issue with IXP (Internet Exchange Points) 418 having to maintain separate peering for both IPv4 and IPv6. From an 419 operations perspective the PE-CE edge peering will be drastically 420 simplified with the elimination of IPv4 peers yielding a reduction of 421 peers by 50 percent. From an operations perspective prior to 422 elimination of IPv4 peers an audit is recommended to identify and 423 IPv4 and IPv6 peering incongruencies that may exist and to rectify 424 prior to elimination of the IPv4 peers. No operational impacts or 425 issues are expected with this change. 427 When a next hop address needs to be passed along unchanged (e.g., as 428 a Route Reflector (RR) would do), its encoding MUST NOT be changed. 429 If a particular RR client cannot handle that encoding (as determined 430 by the BGP Capability Advertisement), then the NLRI in question 431 cannot be distributed to that client. For sound routing in certain 432 scenarios, this will require that all the RR clients be able to 433 handle whatever encodings any of them may generate. 435 6. Softwire Framework Use Cases of IPv4 NLRI with IPv6 Next Hop 437 6.1. VPN-IPv4 over MPLS LDPv6 or SRv6 Core 439 The new MP-BGP extensions defined in [RFC5549] is used to support 440 IPV4 VPNs over an IPv6 MPLS LDPv6 or SRv6 backbone. In this scenario 441 the PE routers would advertise and receive VPN-IPv4 NLRI in the 442 MP_REACH_NLRI along with an IPv6 Next Hop from the Route Reflector 443 (RR). 445 MP-BGP Reach Pseudo code: 447 If ((Update AFI == VPN-IPv4) 449 and (Length of next hop == 24 Bytes || 48 Bytes)) 451 { 453 This is an VPN-IPv4 route, but 455 with an IPv6 next hop; 457 } 459 The MP_REACH_NLRI is encoded with: 461 o AFI = 1 463 o SAFI = 128 465 o Length of Next Hop Network Address = 24 (or 48) 467 o Network Address of Next Hop = VPN-IPv6 address of Next Hop whose 468 RD is set to zero 470 o NLRI = IPv4-VPN routes 472 During BGP Capability Advertisement, the PE routers would include the 473 following fields in the Capabilities Optional Parameter: 475 o Capability Code set to "Extended Next Hop Encoding" 477 o Capability Value containing 480 6.2. IPv4 VPN multicast over MPLS LDPv6 or SRv6 Core 482 The new MP-BGP extensions defined in [RFC8126] is used to support 483 IPV4 Multicast VPNs over an MPLS LDPv6 or SRv6 backbone. In this 484 scenario, the PE routers would advertise and receive VPN-IPv4 NLRI in 485 the MP_REACH_NLRI along with an IPv6 Next Hop from the Route 486 Reflector (RR). 488 MP-BGP Reach Pseudo code: 490 If ((Update AFI == MVPN-IPv4) 492 and (Length of next hop == 24 Bytes || 48 Bytes)) 494 { 496 This is an MVPN-IPv4 route, but 498 with an IPv6 next hop; 500 } 502 The MP_REACH_NLRI is encoded with: 504 o AFI = 1 506 o SAFI = 129 508 o Length of Next Hop Network Address = 24 (or 48) 510 o Network Address of Next Hop = VPN-IPv6 address of Next Hop whose 511 RD is set to zero 513 o NLRI = IPv4-VPN routes 515 During BGP Capability Advertisement, the PE routers would include the 516 following fields in the Capabilities Optional Parameter: 518 o Capability Code set to "Extended Next Hop Encoding" 520 o Capability Value containing 523 6.3. IPv4 Islands over MPLS LDPv6 or SRv6 Core 525 The new MP-BGP extensions defined in [RFC5549] is used to support 526 IPV4 islands over an IPv6 MPLS LDPv6 or SRv6 backbone. In this 527 scenario the PE routers would use BGP labeled unicast address family 528 (BGP-LU) to advertise BGP with label binding and receive labeled IPv4 529 NLRI in the MP_REACH_NLRI along with an IPv6 Next Hop from the Route 530 Reflector (RR). 532 MP-BGP Reach Pseudo code: 534 If ((Update AFI == IPv4) 536 and (Length of next hop == 16 Bytes || 32 Bytes)) 538 { 540 This is an IPv4 route, but 542 with an IPv6 next hop; 544 } 546 The MP_REACH_NLRI is encoded with: 548 o AFI = 1 550 o SAFI = 1 552 o Length of Next Hop Network Address = 16 (or 32) 554 o Network Address of Next Hop = IPv6 address of Next Hop whose RD is 555 set to zero 557 o NLRI = IPv4-VPN routes 559 During BGP Capability Advertisement, the PE routers would include the 560 following fields in the Capabilities Optional Parameter: 562 o Capability Code set to "Extended Next Hop Encoding" 564 o Capability Value containing 567 7. IANA Considerations 569 There are not any IANA considerations. 571 8. Security Considerations 573 The extensions defined in this document allow BGP to propagate 574 reachability information about IPv6 routes over an MPLS IPv4 core 575 network. As such, no new security issues are raised beyond those 576 that already exist in BGP-4 and use of MP-BGP for IPv6. The security 577 features of BGP and corresponding security policy defined in the ISP 578 domain are applicable. For the inter-AS distribution of IPv6 routes 579 according to case (a) of Section 4 of this document, no new security 580 issues are raised beyond those that already exist in the use of eBGP 581 for IPv6 [RFC2545]. 583 9. Acknowledgments 585 10. References 587 10.1. Normative References 589 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 590 Requirement Levels", BCP 14, RFC 2119, 591 DOI 10.17487/RFC2119, March 1997, 592 . 594 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 595 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 596 DOI 10.17487/RFC2545, March 1999, 597 . 599 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 600 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 601 2006, . 603 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 604 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 605 2006, . 607 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 608 "Multiprotocol Extensions for BGP-4", RFC 4760, 609 DOI 10.17487/RFC4760, January 2007, 610 . 612 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 613 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 614 2009, . 616 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 617 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 618 May 2017, . 620 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 621 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 622 . 624 10.2. Informative References 626 [I-D.ietf-idr-dynamic-cap] 627 Ramachandra, S. and E. Chen, "Dynamic Capability for BGP- 628 4", draft-ietf-idr-dynamic-cap-14 (work in progress), 629 December 2011. 631 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 632 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 633 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 634 . 636 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 637 R., Patel, K., and J. Guichard, "Constrained Route 638 Distribution for Border Gateway Protocol/MultiProtocol 639 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 640 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 641 November 2006, . 643 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 644 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 645 Provider Edge Routers (6PE)", RFC 4798, 646 DOI 10.17487/RFC4798, February 2007, 647 . 649 [RFC4925] Li, X., Ed., Dawkins, S., Ed., Ward, D., Ed., and A. 650 Durand, Ed., "Softwire Problem Statement", RFC 4925, 651 DOI 10.17487/RFC4925, July 2007, 652 . 654 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 655 Layer Reachability Information with an IPv6 Next Hop", 656 RFC 5549, DOI 10.17487/RFC5549, May 2009, 657 . 659 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 660 Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, 661 . 663 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 664 "Provisioning, Auto-Discovery, and Signaling in Layer 2 665 Virtual Private Networks (L2VPNs)", RFC 6074, 666 DOI 10.17487/RFC6074, January 2011, 667 . 669 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 670 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 671 2012, . 673 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 674 Encodings and Procedures for Multicast in MPLS/BGP IP 675 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 676 . 678 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 679 Writing an IANA Considerations Section in RFCs", BCP 26, 680 RFC 8126, DOI 10.17487/RFC8126, June 2017, 681 . 683 Author's Address 685 Gyan S. Mishra 686 Verizon Inc. 688 13101 Columbia Pike 690 Silver Spring 691 , 693 MD 20904 695 United States of America 697 Phone: 698 301 502-1347 700 Email: 701 gyan.s.mishra@verizon.com