idnits 2.17.1 draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-03.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 (August 21, 2020) is 1343 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: February 22, 2021 Cisco Systems 6 J. Tantsura 7 Apstra, Inc. 8 August 21, 2020 10 IPv4 NLRI with IPv6 Next Hop Use Cases 11 draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-03 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 February 22, 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 107 1. Introduction 109 As Enterprises and Service Providers upgrade their brown field or 110 green field MPLS/SR core to an IPv6 transport such as MPLS LDPv6, SR- 111 MPLSv6 or SRv6, Multiprotocol BGP (MP-BGP)now plays an important role 112 in the transition of the core from IPv4 to IPv6, and being able to 113 continue to support legacy IPv4, VPN-IPv4, and Multicast VPN IPv4 114 customers. 116 IXPs (Internet Exchange points) are also facing IPv4 address 117 depletion at their peering points, which are large Layer 2 transit 118 backbones that service providers peer and exchange IPv4 and IPv6 119 (Network Layer Reachability Information) NLRI. Today these transit 120 exchange points are dual stacked. One proposal to solve this issue 121 is to use [RFC5549] to carry IPv4 (Network Layer Reachability 122 Information) NLRI in an IPv6 next hop and eliminate the IPv4 peering 123 completely using the concept of [RFC5565] softwire mesh framework. 124 So now with the MP-BGP reach capability exchanged over IPv4 AFI over 125 IPv6 next hop peer we can now advertise IPv4(Network Layer 126 Reachability Information) NLRI over IPv6 peering using the [RFC5565] 127 softwire mesh framework. 129 Multiprotocol BGP (MP-BGP) [RFC4760] specifies that the set of 130 network-layer protocols to which the address carried in the Next Hop 131 field may belong is determined by the Address Family Identifier (AFI) 132 and the Subsequent Address Family Identifier (SAFI). A number of 133 existing AFI/SAFIs allow the Next Hop address to belong to a 134 different address family than the Network Layer Reachability 135 Information (NLRI). 137 For example, the AFI/SAFI <25/65> used (as per [RFC6074]) to perform 138 L2VPN auto-discovery, allows advertising NLRI that contains the 139 identifier of a Virtual Private LAN Service (VPLS) instance or that 140 identifies a particular pool of attachment circuits at a given 141 Provider Edge (PE), while the Next Hop field contains the loopback 142 address of a PE. Similarly, the AFI/SAFI <1/132> (defined in 143 [RFC4684]) to advertise Route Target (RT) membership information, 144 allows advertising NLRI that contains such RT membership information, 145 while the Next Hop field contains the address of the advertising 146 router. 148 Furthermore, a number of these existing AFI/SAFIs allow the Next Hop 149 to belong to either the IPv4 Network Layer Protocol or the IPv6 150 Network Layer Protocol, and specify the encoding of the Next Hop 151 information to determine which of the protocols the address actually 152 belongs to. For example, [RFC4684] allows the Next Hop address to be 153 either IPv4 or IPv6 and states that the Next Hop field address shall 154 be interpreted as an IPv4 address whenever the length of Next Hop 155 address is 4 octets, and as an IPv6 address whenever the length of 156 the Next Hop address is 16 octets. 158 There are situations such as those described in [RFC4925] and in 159 [RFC5565] where carriers (or large enterprise networks acting as 160 carrier for their internal resources) may be required to establish 161 connectivity between 'islands' of networks of one address family type 162 across a transit core of a differing address family type. This 163 includes both the case of IPv6 islands across an IPv4 core and the 164 case of IPv4 islands across an IPv6 core. Where Multiprotocol BGP 165 (MP-BGP) is used to advertise the corresponding reachability 166 information, this translates into the requirement for a BGP speaker 167 to advertise Network Layer Reachability Information (NLRI) of a given 168 address family via a Next Hop of a different address family (i.e., 169 IPv6 NLRI with IPv4 Next Hop and IPv4 NLRI with IPv6 Next Hop). 171 The current AFI/SAFI definitions for the IPv6 address family assume 172 that the Next Hop address belongs to the IPv6 address family type. 173 Specifically, as per [RFC2545] and [RFC8277], when the is 174 <2/1>, <2/2>, or <2/4>, the Next Hop address is assumed to be of IPv6 175 type. As per [RFC4659], when the is <2/128>, the Next Hop 176 address is assumed to be of IPv6-VPN type. 178 However, [RFC4798] and [RFC4659] specify how an IPv4 address can be 179 encoded inside the Next Hop IPv6 address field when IPv6 NLRI needs 180 to be advertised with an IPv4 Next Hop. [RFC4798] defines how the 181 IPv4-mapped IPv6 address format specified in the IPv6 addressing 182 architecture ([RFC4291]) can be used for that purpose when the is <2/1>, <2/2>, or <2/4>. [RFC4659] defines how the IPv4- 184 mapped IPv6 address format as well as a null Route Distinguisher can 185 be used for that purpose when the is <2/128>. Thus, there 186 are existing solutions for the advertisement of IPv6 NLRI with an 187 IPv4 Next Hop. 189 Similarly, the current AFI/SAFI definitions for advertisement of IPv4 190 NLRI or VPN-IPv4 NLRI assume that the Next Hop address belongs to the 191 IPv4 address family type. Specifically, as per [RFC4760] and 192 [RFC8277], when the is <1/1>, <1/2>, or <1/4>, the Next 193 Hop address is assumed to be of IPv4 type. As per [RFC4364], when 194 the is <1/128>, the Next Hop address is assumed to be of 195 VPN-IPv4 type. As per [RFC6513] and [RFC6514], when the 196 is <1/129>, the Next Hop address is assumed to be of VPN-IPv4 type. 197 There is clearly no generally applicable method for encoding an IPv6 198 address inside the IPv4 address field of the Next Hop. Hence, there 199 is currently no specified solution for advertising IPv4 or VPN-IPv4 200 NLRI with an IPv6 Next Hop. 202 A new specification for carrying IPv4 Network Layer Reachability 203 Information (NLRI) of a given address family via a Next Hop of a 204 different address family is now defined in [RFC5549], and specifies 205 the extensions necessary to do so. This comprises an extension of 206 the AFI/SAFI definitions to allow the address of the Next Hop for 207 IPv4 NLRI or VPN-IPv4 NLRI to belong to either the IPv4 or the IPv6 208 protocol, the encoding of the Next Hop information to determine which 209 of the protocols the address actually belongs to, and a new BGP 210 Capability allowing MP-BGP peers to dynamically discover whether they 211 can exchange IPv4 NLRI and VPN- IPv4 NLRI with an IPv6 Next Hop. 213 With the new extensions defined in [RFC5549] supporting Network Layer 214 Reachability Information (NLRI) and next hop address family mismatch, 215 the BGP peer session can now be treated as a pure transport and carry 216 both IPv4 and IPv6 NLRI at the PE-CE edge over a single IPv6 TCP 217 session. This allows for the elimination of dual stack from the PE- 218 CE peering point, and now allow the peering to be IPv6-ONLY. The 219 elimination of IPv4 on the PE-CE peering points translates into OPEX 220 expenditure savings of point-to-point infrastructure links as well as 221 /31 address space savings and administration and network management 222 of both IPv4 and IPv6 BGP peers. This reduction decreases the number 223 of PE-CE BGP peers by fifty percent, which is a tremendous cost 224 savings for all Enterprises and Service Providers. 226 While the savings exists at the PE-CE edge, on the core side PE to 227 Route Reflector peering carrying IPv4 <1/1>, VPN-IPV4 228 <1/128>, and Multicasat VPN <1/129>, the cost savings nets to a break 229 even to be the same as with an IPV4 Core carrying IPv6 NLRI IPV6 230 <2/1>, VPN-IPV6 <2/128>, and Multicasat VPN <2/129>. This document 231 also provides a possible solution for IXPs (Internet Exchange points) 232 that are facing IPv4 address depletion at these peering points to use 233 BGP-MP capability exchange defined in [RFC5549] to carry IPv4 234 (Network Layer Reachability Information) NLRI in an IPv6 next hop 235 using the [RFC5565] softwire mesh framework. 237 2. Requirements Language 239 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 240 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 241 "OPTIONAL" in this document are to be interpreted as described in BCP 242 14 [RFC2119] [RFC8174] when, and only when, they appear in all 243 capitals, as shown here. 245 3. Extension of AFI/SAFI Definitions for the IPv4 Address Family 247 As mentioned earlier, MP-BGP specifies that the set of usable next- 248 hop address families is determined by the Address Family Identifier 249 (AFI) and the Subsequent Address Family Identifier (SAFI). The 250 following current AFI/SAFI definitions for the IPv4 NLRI or VPN-IPv4 251 NLRI (<1/1>, <1/2>, <1/4>, <1/128> and <1/129>) only have provisions 252 for advertising a Next Hop address that belongs to the IPv4 protocol. 253 This document extends the definition of the AFI/SAFI for 254 advertisement of IPv4 NLRI and VPN-IPv4 NLRI to extend the set of 255 usable next-hop address families to include IPv6 in addition to IPv4. 257 Specifically, this document allows advertising with [RFC4760] of an 258 MP_REACH_NLRI with: 260 o AFI = 1 262 o SAFI = 1, 2, or 4 264 o Length of Next Hop Address = 16 or 32 266 o Next Hop Address = IPv6 address of next hop (potentially followed 267 by the link-local IPv6 address of the next hop). This field is to 268 be constructed as per Section 3 of [RFC2545]. 270 o NLRI= NLRI as per current AFI/SAFI definition 272 It also allows advertising with [RFC4760] of an MP_REACH_NLRI with: 274 o AFI = 1 276 o SAFI = 128 or 129 278 o Length of Next Hop Address = 24 or 48 280 o Next Hop Address = VPN-IPv6 address of next hop with an 8-octet RD 281 set to zero (potentially followed by the link-local VPN-IPv6 282 address of the next hop with an 8-octet RD is set to zero). 284 o NLRI= NLRI as per current AFI/SAFI definition 285 This is in addition to the current mode of operation allowing 286 advertisement of NLRI for of <1/1>, <1/2> and <1/4> with a 287 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 289 type. 291 The BGP speaker receiving the advertisement MUST use the Length of 292 Next Hop Address field to determine which network-layer protocol the 293 next hop address belongs to. 295 o When the AFI/SAFI is <1/1>, <1/2> or <1/4> and when the Length of 296 Next Hop Address field is equal to 16 or 32, the next hop address 297 is of type IPv6. 299 o When the AFI/SAFI is <1/128>, or <1/129> and when the Length of 300 Next Hop Address field is equal to 24 or 48, the next hop address 301 is of type VPN-IPv6. 303 Note that this method of using the Length of the Next Hop Address 304 field to determine which network-layer protocol the next hop address 305 belongs to (out of the set of protocols allowed by the AFI/SAFI 306 definition) is the same as used in [RFC4684] and [RFC6074]. 308 4. Use of BGP Capability Advertisement 310 [RFC5492] defines a mechanism to allow two BGP speakers to discover 311 if a particular capability is supported by their BGP peer and thus 312 whether it can be used with that peer. This document defines a new 313 capability that can be advertised using [RFC5492] and that is 314 referred to as the Extended Next Hop Encoding capability. This 315 capability allows BGP speakers to discover whether, for a given NLRI 316 , a peer supports advertisement with a next hop whose 317 network protocol is determined by the value of the Length of Next Hop 318 Address field, as specified in Section 3. 320 A BGP speaker that wishes to advertise to a BGP peer an IPv6 Next Hop 321 for IPv4 NLRI or for VPN-IPv4 NLRI as per this specification MUST use 322 the Capability Advertisement procedures defined in [RFC5492] with the 323 Extended Next Hop Encoding Capability to determine whether its peer 324 supports this for the NLRI AFI/SAFI pair(s) of interest. The fields 325 in the Capabilities Optional Parameter MUST be set as follows: 327 o The Capability Code field MUST be set to 5 (which indicates the 328 Extended Next Hop Encoding capability). 330 o The Capability Length field is set to a variable value that is the 331 length of the Capability Value field (which follows). 333 o The Capability Value field has the following format: 335 +-----------------------------------------------------+ 336 | NLRI AFI - 1 (2 octets) | 337 +-----------------------------------------------------+ 338 | NLRI SAFI - 1 (2 octets) | 339 +-----------------------------------------------------+ 340 | Nexthop AFI - 1 (2 octets) | 341 +-----------------------------------------------------+ 342 | ..... | 343 +-----------------------------------------------------+ 344 | NLRI AFI - N (2 octets) | 345 +-----------------------------------------------------+ 346 | NLRI SAFI - N (2 octets) | 347 +-----------------------------------------------------+ 348 | Nexthop AFI - N (2 octets) | 349 +-----------------------------------------------------+ 351 where: 353 * each triple indicates that 354 NLRI of may be advertised with a Next 355 Hop address belonging to the network-layer protocol of Nexthop 356 AFI. 358 * the AFI and SAFI values are defined in the Address Family 359 Identifier and Subsequent Address Family Identifier registries 360 maintained by IANA. 362 Since this document only concerns itself with the advertisement of 363 IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop, this specification 364 only allows the following values in the Capability Value field of the 365 Extended Next Hop Encoding capability: 367 o NLRI AFI = 1 (IPv4) 369 o NLRI SAFI = 1, 2, 4, 128 or 129 371 o Nexthop AFI = 2 (IPv6) 373 This document does not specify the use of the Extended Next Hop 374 Encoding capability with any other combinations of . For example, the Next Hop Encoding capability 376 specified in this document is not intended to be used for NLRI AFI/ 377 SAFIs whose definition already allows use of both IPv4 and IPv6 next 378 hops (e.g., AFI/SAFI = <1/132> as defined in [RFC4684]). Similarly, 379 it is not intended that the Extended Next Hop Encoding capability be 380 used for NLRI AFI/SAFIs for which there is already solution for 381 advertising a next hop of a different address family (e.g., AFI/SAFI 382 = <2/1>, <2/2>, or <2/4> with IPv4 Next Hop as per [RFC4798] and AFI/ 383 SAFI = <2/128> with IPv4 Next Hop as per [RFC4659]). 385 It is expected that if new AFI/SAFIs are defined in the future, their 386 definition will have provisions (where appropriate) for both IPv4 and 387 IPv6 Next Hops from the onset, with determination based on Length of 388 Next Hop Address field. Thus, new AFI/SAFIs are not expected to make 389 use of the Extended Next Hop Encoding capability. 391 A BGP speaker MUST only advertise to a BGP peer the IPv4 or VPN-IPv4 392 NLRI with an IPv6 Next Hop if the BGP speaker has first ascertained 393 via BGP Capability Advertisement that the BGP peer supports the 394 Extended Next Hop Encoding capability for the relevant AFI/SAFI pair. 396 The Extended Next Hop Encoding capability provides information about 397 next hop encoding for a given AFI/SAFI, assuming that AFI/SAFI is 398 allowed. It does not influence whether that AFI/SAFI is indeed 399 allowed. Whether a AFI/SAFI can be used between the BGP peers is 400 purely determined through the Multiprotocol Extensions capability 401 defined in [RFC4760]. 403 The Extended Next Hop Encoding capability MAY be dynamically updated 404 through the use of the Dynamic Capability capability and associated 405 mechanisms defined in [I-D.ietf-idr-dynamic-cap]. 407 5. Operations 409 As Enterprises and Service Providers migrate their IPv4 core to an 410 MPLS LDPv6 or SRv6 transport, they must continue to be able to 411 support legacy IPv4 customers. With the new extensions defined in 412 [RFC4760], supporting Network Layer Reachability Information (NLRI) 413 and next hop address family mismatch, the BGP peer session can now be 414 treated as a pure transport and carry both IPv4 and IPv6 NLRI at the 415 PE-CE edge. This paves the way to now eliminate dual stacking on all 416 PE-CE peering points to customers making the peering IPv6 only. With 417 this change all IPv4 and IPv6 Network Layer Reachability Information 418 (NLRI) will now be carried over a single BGP session. This also 419 solves the dual stack issue with IXP (Internet Exchange Points) 420 having to maintain separate peering for both IPv4 and IPv6. From an 421 operations perspective the PE-CE edge peering will be drastically 422 simplified with the elimination of IPv4 peers yielding a reduction of 423 peers by 50 percent. From an operations perspective prior to 424 elimination of IPv4 peers an audit is recommended to identify and 425 IPv4 and IPv6 peering incongruencies that may exist and to rectify 426 prior to elimination of the IPv4 peers. No operational impacts or 427 issues are expected with this change. 429 When a next hop address needs to be passed along unchanged (e.g., as 430 a Route Reflector (RR) would do), its encoding MUST NOT be changed. 431 If a particular RR client cannot handle that encoding (as determined 432 by the BGP Capability Advertisement), then the NLRI in question 433 cannot be distributed to that client. For sound routing in certain 434 scenarios, this will require that all the RR clients be able to 435 handle whatever encodings any of them may generate. 437 6. Softwire Framework Use Cases of IPv4 NLRI with IPv6 Next Hop 439 6.1. VPN-IPv4 over MPLS LDPv6 or SRv6 Core 441 The new MP-BGP extensions defined in [RFC5549] is used to support 442 IPV4 VPNs over an IPv6 MPLS LDPv6 or SRv6 backbone. In this scenario 443 the PE routers would advertise and receive VPN-IPv4 NLRI in the 444 MP_REACH_NLRI along with an IPv6 Next Hop from the Route Reflector 445 (RR). 447 MP-BGP Reach Pseudo code: 449 If ((Update AFI == VPN-IPv4) 451 and (Length of next hop == 24 Bytes || 48 Bytes)) 453 { 455 This is an VPN-IPv4 route, but 457 with an IPv6 next hop; 459 } 461 The MP_REACH_NLRI is encoded with: 463 o AFI = 1 465 o SAFI = 128 467 o Length of Next Hop Network Address = 24 (or 48) 469 o Network Address of Next Hop = VPN-IPv6 address of Next Hop whose 470 RD is set to zero 472 o NLRI = IPv4-VPN routes 473 During BGP Capability Advertisement, the PE routers would include the 474 following fields in the Capabilities Optional Parameter: 476 o Capability Code set to "Extended Next Hop Encoding" 478 o Capability Value containing 481 6.2. IPv4 VPN multicast over MPLS LDPv6 or SRv6 Core 483 The new MP-BGP extensions defined in [RFC8126] is used to support 484 IPV4 Multicast VPNs over an MPLS LDPv6 or SRv6 backbone. In this 485 scenario, the PE routers would advertise and receive VPN-IPv4 NLRI in 486 the MP_REACH_NLRI along with an IPv6 Next Hop from the Route 487 Reflector (RR). 489 MP-BGP Reach Pseudo code: 491 If ((Update AFI == MVPN-IPv4) 493 and (Length of next hop == 24 Bytes || 48 Bytes)) 495 { 497 This is an MVPN-IPv4 route, but 499 with an IPv6 next hop; 501 } 503 The MP_REACH_NLRI is encoded with: 505 o AFI = 1 507 o SAFI = 129 509 o Length of Next Hop Network Address = 24 (or 48) 511 o Network Address of Next Hop = VPN-IPv6 address of Next Hop whose 512 RD is set to zero 514 o NLRI = IPv4-VPN routes 516 During BGP Capability Advertisement, the PE routers would include the 517 following fields in the Capabilities Optional Parameter: 519 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 Authors' Addresses 685 Gyan Mishra 686 Verizon Inc. 688 Email: gyan.s.mishra@verizon.com 690 Mankamana Mishra 691 Cisco Systems 692 821 Alder Drive, 693 MILPITAS CALIFORNIA 95035 695 Email: mankamis@cisco.com 697 Jeff Tantsura 698 Apstra, Inc. 700 Email: jefftant.ietf@gmail.com