idnits 2.17.1 draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-02.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 25, 2020) is 1364 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. Mankamana 5 Expires: January 26, 2021 Cisco Systems 6 July 25, 2020 8 IPv4 NLRI with IPv6 Next Hop Use Cases 9 draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-02 11 Abstract 13 As Enterprises and Service Providers upgrade their brown field or 14 green field MPLS/SR core to an IPv6 transport such as MPLS LDPv6, SR- 15 MPLSv6 or SRv6, Multiprotocol BGP (MP-BGP)now plays an important role 16 in the transition of the core from IPv4 to IPv6 being able to 17 continue to support legacy IPv4, VPN-IPv4, and Multicast VPN IPv4 18 customers. 20 Multiprotocol BGP (MP-BGP) specifies that the set of usable next-hop 21 address families is determined by the Address Family Identifier (AFI) 22 and the Subsequent Address Family Identifier (SAFI). Historically 23 the AFI/SAFI definitions for the IPv4 address family only have 24 provisions for advertising a Next Hop address that belongs to the 25 IPv4 protocol when advertising IPv4 or VPN-IPv4 Network Layer 26 Reachability Information (NLRI). [RFC5549] specifies the extensions 27 necessary to allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next 28 Hop address that belongs to the IPv6 protocol. This comprises an 29 extension of the AFI/SAFI definitions to allow the address of the 30 Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 31 Protocol. [RFC5549] defines the encoding of the Next Hop to 32 determine which of the protocols the address actually belongs to, and 33 a new BGP Capability allowing MP-BGP Peers to dynamically discover 34 whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 35 Next Hop. 37 With this new MP-BGP capability exchange allows the BGP peering 38 session to act as a pure transport to allow the session to carry 39 Address Family Identifier (AFI) and the Subsequent Address Family 40 Identifier (SAFI) for both IPv4 and IPv6. 42 This document describes the critical use case and OPEX savings of 43 being able to leverage the MP-BGP capability exchange usage as a pure 44 transport allowing both IPv4 and IPv6 to be carried over the same BGP 45 TCP session. By doing so, allows for the elimination of Dual 46 Stacking on the PE-CE connections making the peering IPv6-ONLY to now 47 carry both IPv4 and IPv6 Network Layer Reachability Information 48 (NLRI). This document also provides a possible solution for IXPs 49 (Internet Exchange points) that are facing IPv4 address depletion at 50 these peering points to use BGP-MP capability exchange defined in 51 [RFC5549] to carry IPv4 (Network Layer Reachability Information) NLRI 52 in an IPv6 next hop using the [RFC5565] softwire mesh framework. 54 Status of This Memo 56 This Internet-Draft is submitted in full conformance with the 57 provisions of BCP 78 and BCP 79. 59 Internet-Drafts are working documents of the Internet Engineering 60 Task Force (IETF). Note that other groups may also distribute 61 working documents as Internet-Drafts. The list of current Internet- 62 Drafts is at https://datatracker.ietf.org/drafts/current/. 64 Internet-Drafts are draft documents valid for a maximum of six months 65 and may be updated, replaced, or obsoleted by other documents at any 66 time. It is inappropriate to use Internet-Drafts as reference 67 material or to cite them other than as "work in progress." 69 This Internet-Draft will expire on January 26, 2021. 71 Copyright Notice 73 Copyright (c) 2020 IETF Trust and the persons identified as the 74 document authors. All rights reserved. 76 This document is subject to BCP 78 and the IETF Trust's Legal 77 Provisions Relating to IETF Documents 78 (https://trustee.ietf.org/license-info) in effect on the date of 79 publication of this document. Please review these documents 80 carefully, as they describe your rights and restrictions with respect 81 to this document. Code Components extracted from this document must 82 include Simplified BSD License text as described in Section 4.e of 83 the Trust Legal Provisions and are provided without warranty as 84 described in the Simplified BSD License. 86 Table of Contents 88 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 89 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 90 3. Extension of AFI/SAFI Definitions for the IPv4 Address Family 6 91 4. Use of BGP Capability Advertisement . . . . . . . . . . . . . 7 92 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 9 93 6. Softwire Framework Use Cases of IPv4 NLRI with IPv6 Next Hop 10 94 6.1. VPN-IPv4 over MPLS LDPv6 or SRv6 Core . . . . . . . . . . 10 95 6.2. IPv4 VPN multicast over MPLS LDPv6 or SRv6 Core . . . . . 11 96 6.3. IPv4 Islands over MPLS LDPv6 or SRv6 Core . . . . . . . . 12 98 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 99 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 100 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 101 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 102 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 103 10.2. Informative References . . . . . . . . . . . . . . . . . 14 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 106 1. Introduction 108 As Enterprises and Service Providers upgrade their brown field or 109 green field MPLS/SR core to an IPv6 transport such as MPLS LDPv6, SR- 110 MPLSv6 or SRv6, Multiprotocol BGP (MP-BGP)now plays an important role 111 in the transition of the core from IPv4 to IPv6, and being able to 112 continue to support legacy IPv4, VPN-IPv4, and Multicast VPN IPv4 113 customers. 115 IXPs (Internet Exchange points) are also facing IPv4 address 116 depletion at their peering points, which are large Layer 2 transit 117 backbones that service providers peer and exchange IPv4 and IPv6 118 (Network Layer Reachability Information) NLRI. Today these transit 119 exchange points are dual stacked. One proposal to solve this issue 120 is to use [RFC5549] to carry IPv4 (Network Layer Reachability 121 Information) NLRI in an IPv6 next hop and eliminate the IPv4 peering 122 completely using the concept of [RFC5565] softwire mesh framework. 123 So now with the MP-BGP reach capability exchanged over IPv4 AFI over 124 IPv6 next hop peer we can now advertise IPv4(Network Layer 125 Reachability Information) NLRI over IPv6 peering using the [RFC5565] 126 softwire mesh framework. 128 Multiprotocol BGP (MP-BGP) [RFC4760] specifies that the set of 129 network-layer protocols to which the address carried in the Next Hop 130 field may belong is determined by the Address Family Identifier (AFI) 131 and the Subsequent Address Family Identifier (SAFI). A number of 132 existing AFI/SAFIs allow the Next Hop address to belong to a 133 different address family than the Network Layer Reachability 134 Information (NLRI). 136 For example, the AFI/SAFI <25/65> used (as per [RFC6074]) to perform 137 L2VPN auto-discovery, allows advertising NLRI that contains the 138 identifier of a Virtual Private LAN Service (VPLS) instance or that 139 identifies a particular pool of attachment circuits at a given 140 Provider Edge (PE), while the Next Hop field contains the loopback 141 address of a PE. Similarly, the AFI/SAFI <1/132> (defined in 142 [RFC4684]) to advertise Route Target (RT) membership information, 143 allows advertising NLRI that contains such RT membership information, 144 while the Next Hop field contains the address of the advertising 145 router. 147 Furthermore, a number of these existing AFI/SAFIs allow the Next Hop 148 to belong to either the IPv4 Network Layer Protocol or the IPv6 149 Network Layer Protocol, and specify the encoding of the Next Hop 150 information to determine which of the protocols the address actually 151 belongs to. For example, [RFC4684] allows the Next Hop address to be 152 either IPv4 or IPv6 and states that the Next Hop field address shall 153 be interpreted as an IPv4 address whenever the length of Next Hop 154 address is 4 octets, and as an IPv6 address whenever the length of 155 the Next Hop address is 16 octets. 157 There are situations such as those described in [RFC4925] and in 158 [RFC5565] where carriers (or large enterprise networks acting as 159 carrier for their internal resources) may be required to establish 160 connectivity between 'islands' of networks of one address family type 161 across a transit core of a differing address family type. This 162 includes both the case of IPv6 islands across an IPv4 core and the 163 case of IPv4 islands across an IPv6 core. Where Multiprotocol BGP 164 (MP-BGP) is used to advertise the corresponding reachability 165 information, this translates into the requirement for a BGP speaker 166 to advertise Network Layer Reachability Information (NLRI) of a given 167 address family via a Next Hop of a different address family (i.e., 168 IPv6 NLRI with IPv4 Next Hop and IPv4 NLRI with IPv6 Next Hop). 170 The current AFI/SAFI definitions for the IPv6 address family assume 171 that the Next Hop address belongs to the IPv6 address family type. 172 Specifically, as per [RFC2545] and [RFC8277], when the is 173 <2/1>, <2/2>, or <2/4>, the Next Hop address is assumed to be of IPv6 174 type. As per [RFC4659], when the is <2/128>, the Next Hop 175 address is assumed to be of IPv6-VPN type. 177 However, [RFC4798] and [RFC4659] specify how an IPv4 address can be 178 encoded inside the Next Hop IPv6 address field when IPv6 NLRI needs 179 to be advertised with an IPv4 Next Hop. [RFC4798] defines how the 180 IPv4-mapped IPv6 address format specified in the IPv6 addressing 181 architecture ([RFC4291]) can be used for that purpose when the is <2/1>, <2/2>, or <2/4>. [RFC4659] defines how the IPv4- 183 mapped IPv6 address format as well as a null Route Distinguisher can 184 be used for that purpose when the is <2/128>. Thus, there 185 are existing solutions for the advertisement of IPv6 NLRI with an 186 IPv4 Next Hop. 188 Similarly, the current AFI/SAFI definitions for advertisement of IPv4 189 NLRI or VPN-IPv4 NLRI assume that the Next Hop address belongs to the 190 IPv4 address family type. Specifically, as per [RFC4760] and 191 [RFC8277], when the is <1/1>, <1/2>, or <1/4>, the Next 192 Hop address is assumed to be of IPv4 type. As per [RFC4364], when 193 the is <1/128>, the Next Hop address is assumed to be of 194 VPN-IPv4 type. As per [RFC6513] and [RFC6514], when the 195 is <1/129>, the Next Hop address is assumed to be of VPN-IPv4 type. 196 There is clearly no generally applicable method for encoding an IPv6 197 address inside the IPv4 address field of the Next Hop. Hence, there 198 is currently no specified solution for advertising IPv4 or VPN-IPv4 199 NLRI with an IPv6 Next Hop. 201 A new specification for carrying IPv4 Network Layer Reachability 202 Information (NLRI) of a given address family via a Next Hop of a 203 different address family is now defined in [RFC5549], and specifies 204 the extensions necessary to do so. This comprises an extension of 205 the AFI/SAFI definitions to allow the address of the Next Hop for 206 IPv4 NLRI or VPN-IPv4 NLRI to belong to either the IPv4 or the IPv6 207 protocol, the encoding of the Next Hop information to determine which 208 of the protocols the address actually belongs to, and a new BGP 209 Capability allowing MP-BGP peers to dynamically discover whether they 210 can exchange IPv4 NLRI and VPN- IPv4 NLRI with an IPv6 Next Hop. 212 With the new extensions defined in [RFC5549] supporting Network Layer 213 Reachability Information (NLRI) and next hop address family mismatch, 214 the BGP peer session can now be treated as a pure transport and carry 215 both IPv4 and IPv6 NLRI at the PE-CE edge over a single IPv6 TCP 216 session. This allows for the elimination of dual stack from the PE- 217 CE peering point, and now allow the peering to be IPv6-ONLY. The 218 elimination of IPv4 on the PE-CE peering points translates into OPEX 219 expenditure savings of point-to-point infrastructure links as well as 220 /31 address space savings and administration and network management 221 of both IPv4 and IPv6 BGP peers. This reduction decreases the number 222 of PE-CE BGP peers by fifty percent, which is a tremendous cost 223 savings for all Enterprises and Service Providers. 225 While the savings exists at the PE-CE edge, on the core side PE to 226 Route Reflector peering carrying IPv4 <1/1>, VPN-IPV4 227 <1/128>, and Multicasat VPN <1/129>, the cost savings nets to a break 228 even to be the same as with an IPV4 Core carrying IPv6 NLRI IPV6 229 <2/1>, VPN-IPV6 <2/128>, and Multicasat VPN <2/129>. This document 230 also provides a possible solution for IXPs (Internet Exchange points) 231 that are facing IPv4 address depletion at these peering points to use 232 BGP-MP capability exchange defined in [RFC5549] to carry IPv4 233 (Network Layer Reachability Information) NLRI in an IPv6 next hop 234 using the [RFC5565] softwire mesh framework. 236 2. Requirements Language 238 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 239 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 240 "OPTIONAL" in this document are to be interpreted as described in BCP 241 14 [RFC2119] [RFC8174] when, and only when, they appear in all 242 capitals, as shown here. 244 3. Extension of AFI/SAFI Definitions for the IPv4 Address Family 246 As mentioned earlier, MP-BGP specifies that the set of usable next- 247 hop address families is determined by the Address Family Identifier 248 (AFI) and the Subsequent Address Family Identifier (SAFI). The 249 following current AFI/SAFI definitions for the IPv4 NLRI or VPN-IPv4 250 NLRI (<1/1>, <1/2>, <1/4>, <1/128> and <1/129>) only have provisions 251 for advertising a Next Hop address that belongs to the IPv4 protocol. 252 This document extends the definition of the AFI/SAFI for 253 advertisement of IPv4 NLRI and VPN-IPv4 NLRI to extend the set of 254 usable next-hop address families to include IPv6 in addition to IPv4. 256 Specifically, this document allows advertising with [RFC4760] of an 257 MP_REACH_NLRI with: 259 o AFI = 1 261 o SAFI = 1, 2, or 4 263 o Length of Next Hop Address = 16 or 32 265 o Next Hop Address = IPv6 address of next hop (potentially followed 266 by the link-local IPv6 address of the next hop). This field is to 267 be constructed as per Section 3 of [RFC2545]. 269 o NLRI= NLRI as per current AFI/SAFI definition 271 It also allows advertising with [RFC4760] of an MP_REACH_NLRI with: 273 o AFI = 1 275 o SAFI = 128 or 129 277 o Length of Next Hop Address = 24 or 48 279 o Next Hop Address = VPN-IPv6 address of next hop with an 8-octet RD 280 set to zero (potentially followed by the link-local VPN-IPv6 281 address of the next hop with an 8-octet RD is set to zero). 283 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 474 During BGP Capability Advertisement, the PE routers would include the 475 following fields in the Capabilities Optional Parameter: 477 o Capability Code set to "Extended Next Hop Encoding" 479 o Capability Value containing 482 6.2. IPv4 VPN multicast over MPLS LDPv6 or SRv6 Core 484 The new MP-BGP extensions defined in [RFC8126] is used to support 485 IPV4 Multicast VPNs over an MPLS LDPv6 or SRv6 backbone. In this 486 scenario, the PE routers would advertise and receive VPN-IPv4 NLRI in 487 the MP_REACH_NLRI along with an IPv6 Next Hop from the Route 488 Reflector (RR). 490 MP-BGP Reach Pseudo code: 492 If ((Update AFI == MVPN-IPv4) 494 and (Length of next hop == 24 Bytes || 48 Bytes)) 496 { 498 This is an MVPN-IPv4 route, but 500 with an IPv6 next hop; 502 } 504 The MP_REACH_NLRI is encoded with: 506 o AFI = 1 508 o SAFI = 129 510 o Length of Next Hop Network Address = 24 (or 48) 512 o Network Address of Next Hop = VPN-IPv6 address of Next Hop whose 513 RD is set to zero 515 o NLRI = IPv4-VPN routes 517 During BGP Capability Advertisement, the PE routers would include the 518 following fields in the Capabilities Optional Parameter: 520 o Capability Code set to "Extended Next Hop Encoding" 522 o Capability Value containing 525 6.3. IPv4 Islands over MPLS LDPv6 or SRv6 Core 527 The new MP-BGP extensions defined in [RFC5549] is used to support 528 IPV4 islands over an IPv6 MPLS LDPv6 or SRv6 backbone. In this 529 scenario the PE routers would use BGP labeled unicast address family 530 (BGP-LU) to advertise BGP with label binding and receive labeled IPv4 531 NLRI in the MP_REACH_NLRI along with an IPv6 Next Hop from the Route 532 Reflector (RR). 534 MP-BGP Reach Pseudo code: 536 If ((Update AFI == IPv4) 538 and (Length of next hop == 16 Bytes || 32 Bytes)) 540 { 542 This is an IPv4 route, but 544 with an IPv6 next hop; 546 } 548 The MP_REACH_NLRI is encoded with: 550 o AFI = 1 552 o SAFI = 1 554 o Length of Next Hop Network Address = 16 (or 32) 556 o Network Address of Next Hop = IPv6 address of Next Hop whose RD is 557 set to zero 559 o NLRI = IPv4-VPN routes 561 During BGP Capability Advertisement, the PE routers would include the 562 following fields in the Capabilities Optional Parameter: 564 o Capability Code set to "Extended Next Hop Encoding" 566 o Capability Value containing 569 7. IANA Considerations 571 There are not any IANA considerations. 573 8. Security Considerations 575 The extensions defined in this document allow BGP to propagate 576 reachability information about IPv6 routes over an MPLS IPv4 core 577 network. As such, no new security issues are raised beyond those 578 that already exist in BGP-4 and use of MP-BGP for IPv6. The security 579 features of BGP and corresponding security policy defined in the ISP 580 domain are applicable. For the inter-AS distribution of IPv6 routes 581 according to case (a) of Section 4 of this document, no new security 582 issues are raised beyond those that already exist in the use of eBGP 583 for IPv6 [RFC2545]. 585 9. Acknowledgments 587 10. References 589 10.1. Normative References 591 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 592 Requirement Levels", BCP 14, RFC 2119, 593 DOI 10.17487/RFC2119, March 1997, 594 . 596 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 597 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 598 DOI 10.17487/RFC2545, March 1999, 599 . 601 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 602 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 603 2006, . 605 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 606 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 607 2006, . 609 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 610 "Multiprotocol Extensions for BGP-4", RFC 4760, 611 DOI 10.17487/RFC4760, January 2007, 612 . 614 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 615 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 616 2009, . 618 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 619 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 620 May 2017, . 622 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 623 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 624 . 626 10.2. Informative References 628 [I-D.ietf-idr-dynamic-cap] 629 Ramachandra, S. and E. Chen, "Dynamic Capability for BGP- 630 4", draft-ietf-idr-dynamic-cap-14 (work in progress), 631 December 2011. 633 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 634 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 635 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 636 . 638 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 639 R., Patel, K., and J. Guichard, "Constrained Route 640 Distribution for Border Gateway Protocol/MultiProtocol 641 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 642 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 643 November 2006, . 645 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 646 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 647 Provider Edge Routers (6PE)", RFC 4798, 648 DOI 10.17487/RFC4798, February 2007, 649 . 651 [RFC4925] Li, X., Ed., Dawkins, S., Ed., Ward, D., Ed., and A. 652 Durand, Ed., "Softwire Problem Statement", RFC 4925, 653 DOI 10.17487/RFC4925, July 2007, 654 . 656 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 657 Layer Reachability Information with an IPv6 Next Hop", 658 RFC 5549, DOI 10.17487/RFC5549, May 2009, 659 . 661 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 662 Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, 663 . 665 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 666 "Provisioning, Auto-Discovery, and Signaling in Layer 2 667 Virtual Private Networks (L2VPNs)", RFC 6074, 668 DOI 10.17487/RFC6074, January 2011, 669 . 671 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 672 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 673 2012, . 675 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 676 Encodings and Procedures for Multicast in MPLS/BGP IP 677 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 678 . 680 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 681 Writing an IANA Considerations Section in RFCs", BCP 26, 682 RFC 8126, DOI 10.17487/RFC8126, June 2017, 683 . 685 Authors' Addresses 687 Gyan S. Mishra 688 Verizon Inc. 690 13101 Columbia Pike 692 Silver Spring 693 , 695 MD 20904 697 United States of America 699 Phone: 700 301 502-1347 702 Email: 703 gyan.s.mishra@verizon.com 705 Mankamana Mishra 706 Cisco Systems 708 821 Alder Drive, 710 MILPITAS 711 , 713 CALIFORNIA 95035 715 Phone: 717 Email: 718 mankamis@cisco.com