idnits 2.17.1 draft-ietf-bess-rfc5549revision-05.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 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The abstract seems to indicate that this document obsoletes RFC5549, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 31, 2020) is 1334 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) -- Obsolete informational reference (is this intentional?): RFC 5549 (Obsoleted by RFC 8950) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group S. Litkowski 3 Internet-Draft S. Agrawal 4 Obsoletes: RFC5549 (if approved) K. Ananthamurthy 5 Intended status: Standards Track Cisco 6 Expires: March 4, 2021 K. Patel 7 Arrcus 8 August 31, 2020 10 Advertising IPv4 Network Layer Reachability Information with an IPv6 11 Next Hop 12 draft-ietf-bess-rfc5549revision-05 14 Abstract 16 Multiprotocol BGP (MP-BGP) specifies that the set of usable next-hop 17 address families is determined by the Address Family Identifier (AFI) 18 and the Subsequent Address Family Identifier (SAFI). The AFI/SAFI 19 definitions for the IPv4 address family only have provisions for 20 advertising a Next Hop address that belongs to the IPv4 protocol when 21 advertising IPv4 Network Layer Reachability Information (NLRI) or 22 VPN-IPv4 NLRI. 24 This document specifies the extensions necessary to allow advertising 25 IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop address that belongs to 26 the IPv6 protocol. This comprises an extension of the AFI/SAFI 27 definitions to allow the address of the Next Hop for IPv4 NLRI or 28 VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of 29 the Next Hop to determine which of the protocols the address actually 30 belongs to, and a BGP Capability allowing MP-BGP Peers to dynamically 31 discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with 32 an IPv6 Next Hop. This document obsoletes RFC5549. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on March 4, 2021. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Changes compared to RFC5549 . . . . . . . . . . . . . . . . . 4 69 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 70 4. Extension of AFI/SAFI Definitions for the IPv4 Address Family 5 71 5. Use of BGP Capability Advertisement . . . . . . . . . . . . . 6 72 6. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 7. Usage Examples . . . . . . . . . . . . . . . . . . . . . . . 9 74 7.1. IPv4 over IPv6 Core . . . . . . . . . . . . . . . . . . . 9 75 7.2. IPv4 VPN unicast over IPv6 Core . . . . . . . . . . . . . 9 76 7.3. IPv4 VPN multicast over IPv6 Core . . . . . . . . . . . . 10 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 79 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 82 11.2. Informative References . . . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Introduction 87 Multiprotocol BGP (MP-BGP) [RFC4760] specifies that the set of 88 network-layer protocols to which the address carried in the Next Hop 89 field may belong is determined by the Address Family Identifier (AFI) 90 and the Subsequent Address Family Identifier (SAFI). A number of 91 existing AFI/SAFIs allow the Next Hop address to belong to a 92 different address family than the Network Layer Reachability 93 Information (NLRI). For example, the AFI/SAFI <25/65> used (as per 94 [RFC6074]) to perform L2VPN auto-discovery, allows advertising NLRI 95 that contains the identifier of a Virtual Private LAN Service (VPLS) 96 instance or that identifies a particular pool of attachment circuits 97 at a given Provider Edge (PE), while the Next Hop field contains the 98 loopback address of a PE. Similarly, the AFI/SAFI <1/132> (defined 99 in [RFC4684]) to advertise Route Target (RT) membership information, 100 allows advertising NLRI that contains such RT membership information, 101 while the Next Hop field contains the address of the advertising 102 router. 104 Furthermore, a number of these existing AFI/SAFIs allow the Next Hop 105 to belong to either the IPv4 protocol or the IPv6 protocol, and 106 specify the encoding of the Next Hop information to determine which 107 of the protocols the address actually belongs to. For example, 108 [RFC4684] allows the Next Hop address to be either an IPv4 or IPv6 109 address and states that the Next Hop field address shall be 110 interpreted as an IPv4 address whenever the length of Next Hop 111 address is 4 octets, and as an IPv6 address whenever the length of 112 the Next Hop address is 16 octets. 114 There are situations such as those described in [RFC4925] and in 115 [RFC5565] where carriers (or large enterprise networks acting as 116 carrier for their internal resources) may be required to establish 117 connectivity between 'islands' of networks of one address family type 118 across a transit core of a differing address family type. This 119 includes both the case of IPv6 islands across an IPv4 core and the 120 case of IPv4 islands across an IPv6 core. Where Multiprotocol BGP 121 (MP-BGP) is used to advertise the corresponding reachability 122 information, this translates into the requirement for a BGP speaker 123 to advertise Network Layer Reachability Information (NLRI) of a given 124 address family via a Next Hop of a different address family (i.e., 125 IPv6 NLRI with IPv4 Next Hop and IPv4 NLRI with IPv6 Next Hop). 127 The AFI/SAFI definitions for the IPv6 address family assume that the 128 Next Hop address belongs to the IPv6 address family type. 129 Specifically, as per [RFC2545] and [RFC8277], when the is 130 <2/1>, <2/2>, or <2/4>, the Next Hop address is assumed to be of IPv6 131 type. As per [RFC4659], when the is <2/128>, the Next Hop 132 address is assumed to be of VPN-IPv6 type. 134 However, [RFC4798] and [RFC4659] specify how an IPv4 address can be 135 encoded inside the Next Hop IPv6 address field when IPv6 NLRI needs 136 to be advertised with an IPv4 Next Hop. [RFC4798] defines how the 137 IPv4-mapped IPv6 address format specified in the IPv6 addressing 138 architecture ([RFC4291]) can be used for that purpose when the is <2/1>, <2/2>, or <2/4>. [RFC4659] defines how the IPv4- 140 mapped IPv6 address format as well as a null Route Distinguisher can 141 be used for that purpose when the is <2/128>. Thus, there 142 are existing solutions for the advertisement of IPv6 NLRI with an 143 IPv4 Next Hop. 145 Similarly, the AFI/SAFI definitions for advertisement of IPv4 NLRI or 146 VPN-IPv4 NLRI assume that the Next Hop address belongs to the IPv4 147 address family type. Specifically, as per [RFC4760] and [RFC8277], 148 when the is <1/1>, <1/2>, or <1/4>, the Next Hop address 149 is assumed to be of IPv4 type. As per [RFC4364], when the 150 is <1/128>, the Next Hop address is assumed to be of VPN-IPv4 type. 151 As per [RFC6513] and [RFC6514], when the is <1/129>, the 152 Next Hop address is assumed to be of VPN-IPv4 type. There is clearly 153 no generally applicable method for encoding an IPv6 address inside 154 the IPv4 address field of the Next Hop. Hence, there is currently no 155 specified solution for advertising IPv4 or VPN-IPv4 NLRI with an IPv6 156 Next Hop. 158 This document specifies the extensions necessary to allow advertising 159 IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop address that belongs to 160 the IPv6 protocol. This comprises an extension of the AFI/SAFI 161 definitions to allow the address of the Next Hop for IPv4 NLRI or 162 VPN-IPv4 NLRI to belong to either the IPv4 or the IPv6 protocol, the 163 encoding of the Next Hop information to determine which of the 164 protocols the address actually belongs to, and a BGP Capability 165 allowing MP-BGP peers to dynamically discover whether they can 166 exchange IPv4 NLRI and VPN- IPv4 NLRI with an IPv6 Next Hop. The BGP 167 Capability allows gradual deployment of the functionality of 168 advertising IPv4 reachability via an IPv6 Next Hop, without any flag 169 day nor any risk of traffic black-holing. 171 This document obsoletes [RFC5549]. 173 2. Changes compared to RFC5549 175 This document introduces two significant changes compared to 176 [RFC5549]: 178 In [RFC5549], when AFI/SAFI 1/128 is used, the nexthop address is 179 encoded as an IPv6 address with a length of 16 or 32 bytes. To 180 accomodate all existing implementations and bring consistency with 181 VPNv4oIPv4 and VPNv6oIPv6, this document modifies how the nexthop 182 address is encoded. The nexthop address is now encoded as an VPN- 183 IPv6 address with a length of 24 or 48 bytes. (See Section 4 and 184 Section 7.2). This change addresses the errata 5253. As all 185 known and deployed implementations are interoperable today and are 186 using the new proposed encoding, the change does not break 187 existing interoperability. 189 This document allows AFI/SAFI 1/129 (IPv4 multicast) to use an 190 IPv6 underlay using a similar encoding and procedures as for AFI/ 191 SAFI 1/128. (See Section 4 and Section 7.3) 193 3. Requirements Language 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 197 "OPTIONAL" in this document are to be interpreted as described in BCP 198 14 [RFC2119] [RFC8174] when, and only when, they appear in all 199 capitals, as shown here. 201 4. Extension of AFI/SAFI Definitions for the IPv4 Address Family 203 As mentioned earlier, MP-BGP specifies that the set of usable next- 204 hop address families is determined by the Address Family Identifier 205 (AFI) and the Subsequent Address Family Identifier (SAFI). The 206 following AFI/SAFI definitions for the IPv4 NLRI or VPN-IPv4 NLRI 207 (<1/1>, <1/2>, <1/4>, <1/128> and <1/129>) only have provisions for 208 advertising a Next Hop address that belongs to the IPv4 protocol. 209 This document extends the definition of the AFI/SAFI for 210 advertisement of IPv4 NLRI and VPN-IPv4 NLRI to extend the set of 211 usable next-hop address families to include IPv6 in addition to IPv4. 213 Specifically, this document allows advertising the MP_REACH_NLRI 214 attribute [RFC4760] with this content: 216 o AFI = 1 218 o SAFI = 1, 2, or 4 220 o Length of Next Hop Address = 16 or 32 222 o Next Hop Address = IPv6 address of next hop (potentially followed 223 by the link-local IPv6 address of the next hop). This field is to 224 be constructed as per Section 3 of [RFC2545]. 226 o NLRI= NLRI as per AFI/SAFI definition 228 It also allows advertising the MP_REACH_NLRI attribute [RFC4760] with 229 this content: 231 o AFI = 1 233 o SAFI = 128 or 129 235 o Length of Next Hop Address = 24 or 48 237 o Next Hop Address = VPN-IPv6 address of next hop with an 8-octet RD 238 set to zero (potentially followed by the link-local VPN-IPv6 239 address of the next hop with an 8-octet RD set to zero). 241 o NLRI= NLRI as per AFI/SAFI definition 243 This is in addition to the existing mode of operation allowing 244 advertisement of NLRI for of <1/1>, <1/2> and <1/4> with a 245 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 247 type. 249 The BGP speaker receiving the advertisement MUST use the Length of 250 Next Hop Address field to determine which network-layer protocol the 251 next hop address belongs to. 253 o When the AFI/SAFI is <1/1>, <1/2> or <1/4> and when the Length of 254 Next Hop Address field is equal to 16 or 32, the next hop address 255 is of type IPv6. 257 o When the AFI/SAFI is <1/128>, or <1/129> and when the Length of 258 Next Hop Address field is equal to 24 or 48, the next hop address 259 is of type VPN-IPv6. 261 Note that this method of using the Length of the Next Hop Address 262 field to determine which network-layer protocol the next hop address 263 belongs to (out of the set of protocols allowed by the AFI/SAFI 264 definition) is the same as used in [RFC4684] and [RFC6074]. 266 5. Use of BGP Capability Advertisement 268 [RFC5492] defines a mechanism to allow two BGP speakers to discover 269 if a particular capability is supported by their BGP peer and thus 270 whether it can be used with that peer. This document defines a 271 capability that can be advertised using [RFC5492] and that is 272 referred to as the Extended Next Hop Encoding capability. This 273 capability allows BGP speakers to discover whether, for a given NLRI 274 , a peer supports advertisement with a next hop whose 275 network protocol is determined by the value of the Length of Next Hop 276 Address field, as specified in Section 4. 278 A BGP speaker that wishes to advertise to a BGP peer an IPv6 Next Hop 279 for IPv4 NLRI or for VPN-IPv4 NLRI as per this specification MUST use 280 the Capability Advertisement procedures defined in [RFC5492] with the 281 Extended Next Hop Encoding Capability to determine whether its peer 282 supports this for the NLRI AFI/SAFI pair(s) of interest. The fields 283 in the Capabilities Optional Parameter MUST be set as follows: 285 o The Capability Code field MUST be set to 5 (which indicates the 286 Extended Next Hop Encoding capability). 288 o The Capability Length field is set to a variable value that is the 289 length of the Capability Value field (which follows). 291 o The Capability Value field has the following format: 293 +-----------------------------------------------------+ 294 | NLRI AFI - 1 (2 octets) | 295 +-----------------------------------------------------+ 296 | NLRI SAFI - 1 (2 octets) | 297 +-----------------------------------------------------+ 298 | Nexthop AFI - 1 (2 octets) | 299 +-----------------------------------------------------+ 300 | ..... | 301 +-----------------------------------------------------+ 302 | NLRI AFI - N (2 octets) | 303 +-----------------------------------------------------+ 304 | NLRI SAFI - N (2 octets) | 305 +-----------------------------------------------------+ 306 | Nexthop AFI - N (2 octets) | 307 +-----------------------------------------------------+ 309 where: 311 * each triple indicates that 312 NLRI of may be advertised with a Next 313 Hop address belonging to the network-layer protocol of Nexthop 314 AFI. 316 * the AFI and SAFI values are defined in the Address Family 317 Identifier and Subsequent Address Family Identifier registries 318 maintained by IANA. 320 Since this document only concerns itself with the advertisement of 321 IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop, this specification 322 only allows the following values in the Capability Value field of the 323 Extended Next Hop Encoding capability: 325 o NLRI AFI = 1 (IPv4) 327 o NLRI SAFI = 1, 2, 4, 128 or 129 329 o Nexthop AFI = 2 (IPv6) 331 This document does not specify the use of the Extended Next Hop 332 Encoding capability with any other combinations of . For example, the Next Hop Encoding capability 334 specified in this document is not intended to be used for NLRI AFI/ 335 SAFIs whose definition already allows use of both IPv4 and IPv6 next 336 hops (e.g., AFI/SAFI = <1/132> as defined in [RFC4684]). Similarly, 337 it is not intended that the Extended Next Hop Encoding capability be 338 used for NLRI AFI/SAFIs for which there is already a solution for 339 advertising a next hop of a different address family (e.g., AFI/SAFI 340 = <2/1>, <2/2>, or <2/4> with IPv4 Next Hop as per [RFC4798] and AFI/ 341 SAFI = <2/128> with IPv4 Next Hop as per [RFC4659]). 343 It is expected that if new AFI/SAFIs are defined in the future, their 344 definition will have provisions (where appropriate) for both IPv4 and 345 IPv6 Next Hops from the beginning, with determination based on Length 346 of Next Hop Address field. Thus, new AFI/SAFIs are not expected to 347 make use of the Extended Next Hop Encoding capability. 349 A BGP speaker MUST only advertise to a BGP peer the IPv4 or VPN-IPv4 350 NLRI with an IPv6 Next Hop if the BGP speaker has first ascertained 351 via BGP Capability Advertisement that the BGP peer supports the 352 Extended Next Hop Encoding capability for the relevant AFI/SAFI pair. 354 The Extended Next Hop Encoding capability provides information about 355 next hop encoding for a given AFI/SAFI, assuming that AFI/SAFI is 356 allowed. It does not influence whether that AFI/SAFI is indeed 357 allowed. Whether a AFI/SAFI can be used between the BGP peers is 358 purely determined through the Multiprotocol Extensions capability 359 defined in [RFC4760]. 361 6. Operations 363 By default, if a particular BGP session is running over IPvx (where 364 IPvx is IPv4 or IPv6), and if the BGP speaker sending an update is 365 putting its own address in as the next hop, then the next hop address 366 SHOULD be specified as an IPvx address, using the encoding rules 367 specified in the AFI/SAFI definition of the NLRI being updated. This 368 default behavior may be overridden by policy. 370 When a next hop address needs to be passed along unchanged (e.g., as 371 a Route Reflector (RR) would do), its encoding MUST NOT be changed. 372 If a particular RR client cannot handle that encoding (as determined 373 by the BGP Capability Advertisement), then the NLRI in question 374 cannot be distributed to that client. For sound routing in certain 375 scenarios, this will require that all the RR clients be able to 376 handle whatever encodings any of them may generate. 378 7. Usage Examples 380 7.1. IPv4 over IPv6 Core 382 The extensions defined in this document may be used as discussed in 383 [RFC5565] for the interconnection of IPv4 islands over an IPv6 384 backbone. In this application, Address Family Border Routers (AFBRs; 385 as defined in [RFC4925]) advertise IPv4 NLRI in the MP_REACH_NLRI 386 along with an IPv6 Next Hop. 388 The MP_REACH_NLRI is encoded with: 390 o AFI = 1 392 o SAFI = 1 394 o Length of Next Hop Network Address = 16 (or 32) 396 o Network Address of Next Hop = IPv6 address of Next Hop 398 o NLRI = IPv4 routes 400 During BGP Capability Advertisement, the PE routers would include the 401 following fields in the Capabilities Optional Parameter: 403 o Capability Code set to "Extended Next Hop Encoding" 405 o Capability Value containing 408 7.2. IPv4 VPN unicast over IPv6 Core 410 The extensions defined in this document may be used for support of 411 IPv4 VPNs over an IPv6 backbone. In this application, PE routers 412 would advertise VPN-IPv4 NLRI in the MP_REACH_NLRI along with an IPv6 413 Next Hop. 415 The MP_REACH_NLRI is encoded with: 417 o AFI = 1 419 o SAFI = 128 421 o Length of Next Hop Network Address = 24 (or 48) 423 o Network Address of Next Hop = VPN-IPv6 address of Next Hop whose 424 RD is set to zero 426 o NLRI = IPv4-VPN routes 428 During BGP Capability Advertisement, the PE routers would include the 429 following fields in the Capabilities Optional Parameter: 431 o Capability Code set to "Extended Next Hop Encoding" 433 o Capability Value containing 436 7.3. IPv4 VPN multicast over IPv6 Core 438 The extensions defined in this document may be used for support of 439 IPv4 multicast VPNs over an IPv6 backbone. In this application, PE 440 routers would advertise VPN-IPv4 NLRI in the MP_REACH_NLRI along with 441 an IPv6 Next Hop. 443 The MP_REACH_NLRI is encoded with: 445 o AFI = 1 447 o SAFI = 129 449 o Length of Next Hop Network Address = 24 (or 48) 451 o Network Address of Next Hop = VPN-IPv6 address of Next Hop whose 452 RD is set to zero 454 o NLRI = IPv4-VPN routes 456 During BGP Capability Advertisement, the PE routers would include the 457 following fields in the Capabilities Optional Parameter: 459 o Capability Code set to "Extended Next Hop Encoding" 461 o Capability Value containing 464 8. IANA Considerations 466 This document does not define any new code point compared to 467 [RFC5549]. IANA is requested to update the reference for the 468 existing registration mentioned below. 470 This document defines, in Section 5, a new Capability Code to 471 indicate the Extended Next Hop Encoding capability in the [RFC5492] 472 Capabilities Optional Parameter. The value for this new Capability 473 Code is 5, which is in the range set aside for allocation using the 474 "IETF Review" policy defined in [RFC8126]. 476 9. Security Considerations 478 This document does not raise any additional security issues beyond 479 those of BGP-4 and the Multiprotocol extensions for BGP-4. The same 480 security mechanisms are applicable. 482 However, as [RFC4272] discusses, BGP is vulnerable to traffic 483 diversion attacks. The ability to advertise an IPv6 Next Hop adds a 484 new means by which an attacker could cause traffic to be diverted 485 from its normal path. Such an attack differs from pre-existing 486 vulnerabilities in that traffic could be forwarded to a distant 487 target across an intervening network infrastructure (e.g. an IPv6 488 core), allowing an attack to potentially succeed more easily, since 489 less infrastructure would have to be subverted. Potential 490 consequences include "hijacking" of traffic or denial of service. 492 Although not expected to be the typical case, the IPv6 address used 493 as the BGP Next Hop Address could be an IPv4-mapped IPv6 address (as 494 defined in [RFC4291]). Configuration of the security mechanisms 495 potentially deployed by the network operator (such as security checks 496 on next hop address) need to keep this case in mind also. 498 10. Acknowledgments 500 The authors would like to thank Francois Le Faucheur and Eric Rosen 501 for the edition and their work on [RFC5549]. 503 The authors would like to thank Yakov Rekhter, Pranav Mehta, and John 504 Scudder for their contributions to the approach defined in [RFC5549]. 506 11. References 508 11.1. Normative References 510 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 511 Requirement Levels", BCP 14, RFC 2119, 512 DOI 10.17487/RFC2119, March 1997, 513 . 515 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 516 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 517 DOI 10.17487/RFC2545, March 1999, 518 . 520 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 521 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 522 2006, . 524 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 525 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 526 2006, . 528 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 529 "Multiprotocol Extensions for BGP-4", RFC 4760, 530 DOI 10.17487/RFC4760, January 2007, 531 . 533 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 534 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 535 2009, . 537 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 538 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 539 May 2017, . 541 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 542 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 543 . 545 11.2. Informative References 547 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 548 RFC 4272, DOI 10.17487/RFC4272, January 2006, 549 . 551 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 552 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 553 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 554 . 556 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 557 R., Patel, K., and J. Guichard, "Constrained Route 558 Distribution for Border Gateway Protocol/MultiProtocol 559 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 560 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 561 November 2006, . 563 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 564 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 565 Provider Edge Routers (6PE)", RFC 4798, 566 DOI 10.17487/RFC4798, February 2007, 567 . 569 [RFC4925] Li, X., Ed., Dawkins, S., Ed., Ward, D., Ed., and A. 570 Durand, Ed., "Softwire Problem Statement", RFC 4925, 571 DOI 10.17487/RFC4925, July 2007, 572 . 574 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 575 Layer Reachability Information with an IPv6 Next Hop", 576 RFC 5549, DOI 10.17487/RFC5549, May 2009, 577 . 579 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 580 Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, 581 . 583 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 584 "Provisioning, Auto-Discovery, and Signaling in Layer 2 585 Virtual Private Networks (L2VPNs)", RFC 6074, 586 DOI 10.17487/RFC6074, January 2011, 587 . 589 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 590 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 591 2012, . 593 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 594 Encodings and Procedures for Multicast in MPLS/BGP IP 595 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 596 . 598 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 599 Writing an IANA Considerations Section in RFCs", BCP 26, 600 RFC 8126, DOI 10.17487/RFC8126, June 2017, 601 . 603 Authors' Addresses 605 Stephane Litkowski 606 Cisco 608 Email: slitkows@cisco.com 610 Swadesh Agrawal 611 Cisco 613 Email: swaagraw@cisco.com 614 Krishna Muddenahally Ananthamurthy 615 Cisco 617 Email: kriswamy@cisco.com 619 Keyur Patel 620 Arrcus 622 Email: keyur@arrcus.com