idnits 2.17.1 draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5549], [RFC5565]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 18, 2020) is 1226 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-16) exists of draft-ietf-idr-dynamic-cap-14 -- Obsolete informational reference (is this intentional?): RFC 5549 (Obsoleted by RFC 8950) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group G. Mishra 3 Internet-Draft Verizon Inc. 4 Intended status: Standards Track M. Mishra 5 Expires: May 22, 2021 Cisco Systems 6 J. Tantsura 7 Apstra, Inc. 8 L. Wang 9 Juniper Networks, Inc. 10 November 18, 2020 12 IPv4 NLRI with IPv6 Next Hop Use Cases 13 draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-07 15 Abstract 17 As Enterprises and Service Providers upgrade their brown field or 18 green field MPLS/SR core to an IPv6 transport such as MPLS LDPv6, SR- 19 MPLSv6 or SRv6, Multiprotocol BGP (MP-BGP)now plays an important role 20 in the transition of the core from IPv4 to IPv6 being able to 21 continue to support legacy IPv4, VPN-IPv4, and Multicast VPN IPv4 22 customers. 24 This document describes the critical use case and OPEX savings of 25 being able to leverage the MP-BGP capability exchange usage as a pure 26 transport allowing both IPv4 and IPv6 to be carried over the same BGP 27 TCP session. By doing so, allows for the elimination of Dual 28 Stacking on the PE-CE connections making the peering IPv6-ONLY to now 29 carry both IPv4 and IPv6 Network Layer Reachability Information 30 (NLRI). This document now provides a solution for IXPs (Internet 31 Exchange points) that are facing IPv4 address depletion at these 32 peering points to use BGP-MP capability exchange defined in [RFC5549] 33 to carry IPv4 (Network Layer Reachability Information) NLRI in an 34 IPv6 next hop using the [RFC5565] softwire mesh framework. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on May 22, 2021. 53 Copyright Notice 55 Copyright (c) 2020 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 72 3. Extension of AFI/SAFI Definitions for the IPv4 Address Family 6 73 4. Use of BGP Capability Advertisement . . . . . . . . . . . . . 7 74 5. Operational Improvements with Single IPv6 transport peer . . 9 75 6. Operational Considerations . . . . . . . . . . . . . . . . . 10 76 7. Softwire Framework Use Cases of IPv4 NLRI with IPv6 Next Hop 10 77 7.1. VPN-IPv4 over MPLS LDPv6 or SRv6 Core . . . . . . . . . . 10 78 7.2. IPv4 VPN multicast over MPLS LDPv6 or SRv6 Core . . . . . 11 79 7.3. IPv4 Islands over MPLS LDPv6 or SRv6 Core . . . . . . . . 12 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 85 11.2. Informative References . . . . . . . . . . . . . . . . . 14 86 Appendix A. IPv4 NLRI IPv6 Next Hop Vendor Testing . . . . . . . 16 87 A.1. Router and Switch Vendors Support and Quality Assurance 88 Engineering Lab Results. . . . . . . . . . . . . . . . . 16 89 A.2. Router and Switch Vendors Interoperability Lab Results. . 16 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 92 1. Introduction 94 As Enterprises and Service Providers upgrade their brown field or 95 green field MPLS/SR core to an IPv6 transport such as MPLS LDPv6, SR- 96 MPLSv6 or SRv6, Multiprotocol BGP (MP-BGP)now plays an important role 97 in the transition of the core from IPv4 to IPv6, and being able to 98 continue to support legacy IPv4, VPN-IPv4, and Multicast VPN IPv4 99 customers. 101 IXPs (Internet Exchange points) are also facing IPv4 address 102 depletion at their peering points, which are large Layer 2 transit 103 backbones that service providers peer and exchange IPv4 and IPv6 104 (Network Layer Reachability Information) NLRI. Today these transit 105 exchange points are dual stacked. One proposal to solve this issue 106 is to use [RFC5549] to carry IPv4 (Network Layer Reachability 107 Information) NLRI in an IPv6 next hop and eliminate the IPv4 peering 108 completely using the concept of [RFC5565] softwire mesh framework. 109 So now with the MP-BGP reach capability exchanged over IPv4 AFI over 110 IPv6 next hop peer we can now advertise IPv4(Network Layer 111 Reachability Information) NLRI over IPv6 peering using the [RFC5565] 112 softwire mesh framework. 114 Multiprotocol BGP (MP-BGP) specifies that the set of usable next-hop 115 address families is determined by the Address Family Identifier (AFI) 116 and the Subsequent Address Family Identifier (SAFI). Historically 117 the AFI/SAFI definitions for the IPv4 address family only have 118 provisions for advertising a Next Hop address that belongs to the 119 IPv4 protocol when advertising IPv4 or VPN-IPv4 Network Layer 120 Reachability Information (NLRI). [RFC5549] specifies the extensions 121 necessary to allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next 122 Hop address that belongs to the IPv6 protocol. This comprises an 123 extension of the AFI/SAFI definitions to allow the address of the 124 Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 125 Protocol. [RFC5549] defines the encoding of the Next Hop to 126 determine which of the protocols the address actually belongs to, and 127 a new BGP Capability allowing MP-BGP Peers to dynamically discover 128 whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 129 Next Hop. 131 With this new MP-BGP capability exchange allows the BGP peering 132 session to act as a pure transport to allow the session to carry 133 Address Family Identifier (AFI) and the Subsequent Address Family 134 Identifier (SAFI) for both IPv4 and IPv6. 136 Furthermore, a number of these existing AFI/SAFIs allow the Next Hop 137 to belong to either the IPv4 Network Layer Protocol or the IPv6 138 Network Layer Protocol, and specify the encoding of the Next Hop 139 information to determine which of the protocols the address actually 140 belongs to. For example, [RFC4684] allows the Next Hop address to be 141 either IPv4 or IPv6 and states that the Next Hop field address shall 142 be interpreted as an IPv4 address whenever the length of Next Hop 143 address is 4 octets, and as an IPv6 address whenever the length of 144 the Next Hop address is 16 octets. 146 For example, the AFI/SAFI <25/65> used (as per [RFC6074]) to perform 147 L2VPN auto-discovery, allows advertising NLRI that contains the 148 identifier of a Virtual Private LAN Service (VPLS) instance or that 149 identifies a particular pool of attachment circuits at a given 150 Provider Edge (PE), while the Next Hop field contains the loopback 151 address of a PE. Similarly, the AFI/SAFI <1/132> (defined in 152 [RFC4684]) to advertise Route Target (RT) membership information, 153 allows advertising NLRI that contains such RT membership information, 154 while the Next Hop field contains the address of the advertising 155 router. 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 284 This is in addition to the current mode of operation allowing 285 advertisement of NLRI for of <1/1>, <1/2> and <1/4> with a 286 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 288 type. 290 The BGP speaker receiving the advertisement MUST use the Length of 291 Next Hop Address field to determine which network-layer protocol the 292 next hop address belongs to. 294 o When the AFI/SAFI is <1/1>, <1/2> or <1/4> and when the Length of 295 Next Hop Address field is equal to 16 or 32, the next hop address 296 is of type IPv6. 298 o When the AFI/SAFI is <1/128>, or <1/129> and when the Length of 299 Next Hop Address field is equal to 24 or 48, the next hop address 300 is of type VPN-IPv6. 302 Note that this method of using the Length of the Next Hop Address 303 field to determine which network-layer protocol the next hop address 304 belongs to (out of the set of protocols allowed by the AFI/SAFI 305 definition) is the same as used in [RFC4684] and [RFC6074]. 307 4. Use of BGP Capability Advertisement 309 [RFC5492] defines a mechanism to allow two BGP speakers to discover 310 if a particular capability is supported by their BGP peer and thus 311 whether it can be used with that peer. This document defines a new 312 capability that can be advertised using [RFC5492] and that is 313 referred to as the Extended Next Hop Encoding capability. This 314 capability allows BGP speakers to discover whether, for a given NLRI 315 , a peer supports advertisement with a next hop whose 316 network protocol is determined by the value of the Length of Next Hop 317 Address field, as specified in Section 3. 319 A BGP speaker that wishes to advertise to a BGP peer an IPv6 Next Hop 320 for IPv4 NLRI or for VPN-IPv4 NLRI as per this specification MUST use 321 the Capability Advertisement procedures defined in [RFC5492] with the 322 Extended Next Hop Encoding Capability to determine whether its peer 323 supports this for the NLRI AFI/SAFI pair(s) of interest. The fields 324 in the Capabilities Optional Parameter MUST be set as follows: 326 o The Capability Code field MUST be set to 5 (which indicates the 327 Extended Next Hop Encoding capability). 329 o The Capability Length field is set to a variable value that is the 330 length of the Capability Value field (which follows). 332 o The Capability Value field has the following format: 334 +-----------------------------------------------------+ 335 | NLRI AFI - 1 (2 octets) | 336 +-----------------------------------------------------+ 337 | NLRI SAFI - 1 (2 octets) | 338 +-----------------------------------------------------+ 339 | Nexthop AFI - 1 (2 octets) | 340 +-----------------------------------------------------+ 341 | ..... | 342 +-----------------------------------------------------+ 343 | NLRI AFI - N (2 octets) | 344 +-----------------------------------------------------+ 345 | NLRI SAFI - N (2 octets) | 346 +-----------------------------------------------------+ 347 | Nexthop AFI - N (2 octets) | 348 +-----------------------------------------------------+ 350 where: 352 * each triple indicates that 353 NLRI of may be advertised with a Next 354 Hop address belonging to the network-layer protocol of Nexthop 355 AFI. 357 * the AFI and SAFI values are defined in the Address Family 358 Identifier and Subsequent Address Family Identifier registries 359 maintained by IANA. 361 Since this document only concerns itself with the advertisement of 362 IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop, this specification 363 only allows the following values in the Capability Value field of the 364 Extended Next Hop Encoding capability: 366 o NLRI AFI = 1 (IPv4) 368 o NLRI SAFI = 1, 2, 4, 128 or 129 370 o Nexthop AFI = 2 (IPv6) 372 This document does not specify the use of the Extended Next Hop 373 Encoding capability with any other combinations of . For example, the Next Hop Encoding capability 375 specified in this document is not intended to be used for NLRI AFI/ 376 SAFIs whose definition already allows use of both IPv4 and IPv6 next 377 hops (e.g., AFI/SAFI = <1/132> as defined in [RFC4684]). Similarly, 378 it is not intended that the Extended Next Hop Encoding capability be 379 used for NLRI AFI/SAFIs for which there is already solution for 380 advertising a next hop of a different address family (e.g., AFI/SAFI 381 = <2/1>, <2/2>, or <2/4> with IPv4 Next Hop as per [RFC4798] and AFI/ 382 SAFI = <2/128> with IPv4 Next Hop as per [RFC4659]). 384 It is expected that if new AFI/SAFIs are defined in the future, their 385 definition will have provisions (where appropriate) for both IPv4 and 386 IPv6 Next Hops from the onset, with determination based on Length of 387 Next Hop Address field. Thus, new AFI/SAFIs are not expected to make 388 use of the Extended Next Hop Encoding capability. 390 A BGP speaker MUST only advertise to a BGP peer the IPv4 or VPN-IPv4 391 NLRI with an IPv6 Next Hop if the BGP speaker has first ascertained 392 via BGP Capability Advertisement that the BGP peer supports the 393 Extended Next Hop Encoding capability for the relevant AFI/SAFI pair. 395 The Extended Next Hop Encoding capability provides information about 396 next hop encoding for a given AFI/SAFI, assuming that AFI/SAFI is 397 allowed. It does not influence whether that AFI/SAFI is indeed 398 allowed. Whether a AFI/SAFI can be used between the BGP peers is 399 purely determined through the Multiprotocol Extensions capability 400 defined in [RFC4760]. 402 The Extended Next Hop Encoding capability MAY be dynamically updated 403 through the use of the Dynamic Capability capability and associated 404 mechanisms defined in [I-D.ietf-idr-dynamic-cap]. 406 5. Operational Improvements with Single IPv6 transport peer 408 As Enterprises and Service Providers migrate their IPv4 core to an 409 MPLS LDPv6 or SRv6 transport, they must continue to be able to 410 support legacy IPv4 customers. With the new extensions defined in 411 [RFC4760], supporting Network Layer Reachability Information (NLRI) 412 and next hop address family mismatch, the BGP peer session can now be 413 treated as a pure transport and carry both IPv4 and IPv6 NLRI at the 414 PE-CE edge. This paves the way to now eliminate dual stacking on all 415 PE-CE peering points to customers making the peering IPv6 only. With 416 this change all IPv4 and IPv6 Network Layer Reachability Information 417 (NLRI) will now be carried over a single BGP session. This also 418 solves the dual stack issue with IXP (Internet Exchange Points) 419 having to maintain separate peering for both IPv4 and IPv6. From an 420 operations perspective the PE-CE edge peering will be drastically 421 simplified with the elimination of IPv4 peers yielding a reduction of 422 peers by 50 percent. From an operations perspective prior to 423 elimination of IPv4 peers an audit is recommended to identify and 424 IPv4 and IPv6 peering incongruencies that may exist and to rectify 425 prior to elimination of the IPv4 peers. No operational impacts or 426 issues are expected with this change. 428 6. Operational Considerations 430 With a sinlge IPv6 Peer carrying both IPv4 and IPv6 NLRI there are 431 some operational considerations in terms of what changes and what 432 does not change. 434 What does not change with a single IPv6 transport peer carrying IPv4 435 NLRI and IPv6 NLRI below: 437 Routing Policy configuration is still separate for IPv4 and IPv6 438 configured by capability as previously 440 Layer 1, Layer 2 issues such as 1 way fiber or fiber cut will impact 441 both IPv4 and IPv6 as previously. 443 If the interface is admin down the IPv6 peer would go down and IPv4 444 NLRI and IPv6 NLRI would be withdrawn as previously. 446 What does change with a single IPv6 transport peer carrying IPv4 NLRI 447 and IPv6 NLRI below: 449 Physical interface is no longer dual stacked. Any change in IPv6 450 address or DAD state will impact both IPv4 and IPv6 NLRI exchange 452 Single BFD session for both IPv4 and IPv6 NLRI fate sharing as the 453 session is now tied to the transport which now is only IPv6 address 454 family 456 Both IPv4 and IPv6 peer now exists under the IPv4 address family 457 configuration 459 Fate sharing of IPv4 and IPv6 address family from a logical 460 perspective now carried over a single IPv6 peer 462 7. Softwire Framework Use Cases of IPv4 NLRI with IPv6 Next Hop 464 7.1. VPN-IPv4 over MPLS LDPv6 or SRv6 Core 466 The new MP-BGP extensions defined in [RFC5549] is used to support 467 IPV4 VPNs over an IPv6 MPLS LDPv6 or SRv6 backbone. In this scenario 468 the PE routers would advertise and receive VPN-IPv4 NLRI in the 469 MP_REACH_NLRI along with an IPv6 Next Hop from the Route Reflector 470 (RR). 472 MP-BGP Reach Pseudo code: 474 If ((Update AFI == VPN-IPv4) 476 and (Length of next hop == 24 Bytes || 48 Bytes)) 478 { 480 This is an VPN-IPv4 route, but 482 with an IPv6 next hop; 484 } 486 The MP_REACH_NLRI is encoded with: 488 o AFI = 1 490 o SAFI = 128 492 o Length of Next Hop Network Address = 24 (or 48) 494 o Network Address of Next Hop = VPN-IPv6 address of Next Hop whose 495 RD is set to zero 497 o NLRI = IPv4-VPN routes 499 During BGP Capability Advertisement, the PE routers would include the 500 following fields in the Capabilities Optional Parameter: 502 o Capability Code set to "Extended Next Hop Encoding" 504 o Capability Value containing 507 7.2. IPv4 VPN multicast over MPLS LDPv6 or SRv6 Core 509 The new MP-BGP extensions defined in [RFC8126] is used to support 510 IPV4 Multicast VPNs over an MPLS LDPv6 or SRv6 backbone. In this 511 scenario, the PE routers would advertise and receive VPN-IPv4 NLRI in 512 the MP_REACH_NLRI along with an IPv6 Next Hop from the Route 513 Reflector (RR). 515 MP-BGP Reach Pseudo code: 517 If ((Update AFI == MVPN-IPv4) 519 and (Length of next hop == 24 Bytes || 48 Bytes)) 521 { 522 This is an MVPN-IPv4 route, but 524 with an IPv6 next hop; 526 } 528 The MP_REACH_NLRI is encoded with: 530 o AFI = 1 532 o SAFI = 129 534 o Length of Next Hop Network Address = 24 (or 48) 536 o Network Address of Next Hop = VPN-IPv6 address of Next Hop whose 537 RD is set to zero 539 o NLRI = IPv4-VPN routes 541 During BGP Capability Advertisement, the PE routers would include the 542 following fields in the Capabilities Optional Parameter: 544 o Capability Code set to "Extended Next Hop Encoding" 546 o Capability Value containing 549 7.3. IPv4 Islands over MPLS LDPv6 or SRv6 Core 551 The new MP-BGP extensions defined in [RFC5549] is used to support 552 IPV4 islands over an IPv6 MPLS LDPv6 or SRv6 backbone. In this 553 scenario the PE routers would use BGP labeled unicast address family 554 (BGP-LU) to advertise BGP with label binding and receive labeled IPv4 555 NLRI in the MP_REACH_NLRI along with an IPv6 Next Hop from the Route 556 Reflector (RR). 558 MP-BGP Reach Pseudo code: 560 If ((Update AFI == IPv4) 562 and (Length of next hop == 16 Bytes || 32 Bytes)) 564 { 566 This is an IPv4 route, but 568 with an IPv6 next hop; 569 } 571 The MP_REACH_NLRI is encoded with: 573 o AFI = 1 575 o SAFI = 1 577 o Length of Next Hop Network Address = 16 (or 32) 579 o Network Address of Next Hop = IPv6 address of Next Hop whose RD is 580 set to zero 582 o NLRI = IPv4-VPN routes 584 During BGP Capability Advertisement, the PE routers would include the 585 following fields in the Capabilities Optional Parameter: 587 o Capability Code set to "Extended Next Hop Encoding" 589 o Capability Value containing 592 8. IANA Considerations 594 There are not any IANA considerations. 596 9. Security Considerations 598 The extensions defined in this document allow BGP to propagate 599 reachability information about IPv6 routes over an MPLS IPv4 core 600 network. As such, no new security issues are raised beyond those 601 that already exist in BGP-4 and use of MP-BGP for IPv6. The security 602 features of BGP and corresponding security policy defined in the ISP 603 domain are applicable. For the inter-AS distribution of IPv6 routes 604 according to case (a) of Section 4 of this document, no new security 605 issues are raised beyond those that already exist in the use of eBGP 606 for IPv6 [RFC2545]. 608 10. Acknowledgments 610 11. References 612 11.1. Normative References 614 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 615 Requirement Levels", BCP 14, RFC 2119, 616 DOI 10.17487/RFC2119, March 1997, 617 . 619 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 620 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 621 DOI 10.17487/RFC2545, March 1999, 622 . 624 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 625 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 626 2006, . 628 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 629 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 630 2006, . 632 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 633 "Multiprotocol Extensions for BGP-4", RFC 4760, 634 DOI 10.17487/RFC4760, January 2007, 635 . 637 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 638 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 639 2009, . 641 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 642 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 643 May 2017, . 645 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 646 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 647 . 649 11.2. Informative References 651 [I-D.ietf-idr-dynamic-cap] 652 Ramachandra, S. and E. Chen, "Dynamic Capability for BGP- 653 4", draft-ietf-idr-dynamic-cap-14 (work in progress), 654 December 2011. 656 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 657 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 658 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 659 . 661 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 662 R., Patel, K., and J. Guichard, "Constrained Route 663 Distribution for Border Gateway Protocol/MultiProtocol 664 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 665 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 666 November 2006, . 668 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 669 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 670 Provider Edge Routers (6PE)", RFC 4798, 671 DOI 10.17487/RFC4798, February 2007, 672 . 674 [RFC4925] Li, X., Ed., Dawkins, S., Ed., Ward, D., Ed., and A. 675 Durand, Ed., "Softwire Problem Statement", RFC 4925, 676 DOI 10.17487/RFC4925, July 2007, 677 . 679 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 680 Layer Reachability Information with an IPv6 Next Hop", 681 RFC 5549, DOI 10.17487/RFC5549, May 2009, 682 . 684 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 685 Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, 686 . 688 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 689 "Provisioning, Auto-Discovery, and Signaling in Layer 2 690 Virtual Private Networks (L2VPNs)", RFC 6074, 691 DOI 10.17487/RFC6074, January 2011, 692 . 694 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 695 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 696 2012, . 698 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 699 Encodings and Procedures for Multicast in MPLS/BGP IP 700 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 701 . 703 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 704 Writing an IANA Considerations Section in RFCs", BCP 26, 705 RFC 8126, DOI 10.17487/RFC8126, June 2017, 706 . 708 Appendix A. IPv4 NLRI IPv6 Next Hop Vendor Testing 710 IPv4 NLRI with IPv6 Next Hop encoding is supported for all BGP peers 711 both iBGP and eBGP. 713 This section details the vendor support of RFC5549 "PE-RR iBGP", "PE- 714 CE eBGP" using GUA (Global Unicast Address), Link Local (LL) peering 715 and Quality Assurance lab testing. This drafts goal is to ensure 716 that all features and functionality works with "eBGP PE-CE" use case 717 single peer carrying both IPv4 NLRI and IPv6 NLRI and that the 718 routing policy features are all still fully functionality do not 719 change. 721 A.1. Router and Switch Vendors Support and Quality Assurance 722 Engineering Lab Results. 724 +-----------+------------+--------------+---------------+-----------+ 725 | Vendor | PE-RR iBGP | PE-CE eBGP | PE-CE eBGP LL | QA Tested | 726 | | | GUI | | | 727 +-----------+------------+--------------+---------------+-----------+ 728 | Cisco | *** | *** | | | 729 | Juniper | *** | *** | | | 730 | Nokia/ALU | *** | *** | | | 731 | Arista | | | | | 732 | Huawei | | | | | 733 +-----------+------------+--------------+---------------+-----------+ 735 Table 1: Vendor Support 737 A.2. Router and Switch Vendors Interoperability Lab Results. 739 This section details the vendor interoperability testing and support 740 of RFC5549 that all features and functionality works with "eBGP PE- 741 CE" use case with having a single peer carrying both IPv4 NLRI and 742 IPv6 NLRI and that the routing policy features are fully tested for 743 quality assurance. 745 +-----------+-------+---------+-----------+--------+--------+ 746 | Vendor | Cisco | Juniper | Nokia/ALU | Arista | Huawei | 747 +-----------+-------+---------+-----------+--------+--------+ 748 | Cisco | | | | | | 749 | Juniper | | | | | | 750 | Nokia/ALU | | | | | | 751 | Arista | | | | | | 752 | Huawei | | | | | | 753 +-----------+-------+---------+-----------+--------+--------+ 755 Table 2: Vendor Interop 757 Authors' Addresses 759 Gyan Mishra 760 Verizon Inc. 762 Email: gyan.s.mishra@verizon.com 764 Mankamana Mishra 765 Cisco Systems 766 821 Alder Drive, 767 MILPITAS CALIFORNIA 95035 769 Email: mankamis@cisco.com 771 Jeff Tantsura 772 Apstra, Inc. 774 Email: jefftant.ietf@gmail.com 776 Lili Wang 777 Juniper Networks, Inc. 778 10 Technology Park Drive, 779 Westford MA 01886 780 US 782 Email: liliw@juniper.net