idnits 2.17.1 draft-ietf-bess-rfc5549revision-00.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 ([RFC4760]), 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 (January 6, 2020) is 1572 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 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5549 (Obsoleted by RFC 8950) Summary: 1 error (**), 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 Intended status: Standards Track K. Ananthamurthy 5 Expires: July 9, 2020 Cisco 6 K. Patel 7 Arrcus 8 January 6, 2020 10 Advertising IPv4 Network Layer Reachability Information with an IPv6 11 Next Hop 12 draft-ietf-bess-rfc5549revision-00 14 Abstract 16 Multiprotocol BGP (MP-BGP) [RFC4760] specifies that the set of 17 network-layer protocols to which the address carried in the Next Hop 18 field may belong is determined by the Address Family Identifier (AFI) 19 and the Subsequent Address Family Identifier (SAFI). The current 20 AFI/SAFI definitions for the IPv4 address family only have provisions 21 for advertising a Next Hop address that belongs to the IPv4 protocol 22 when advertising IPv4 Network Layer Reachability Information (NLRI) 23 or VPN-IPv4 NLRI. This document specifies the extensions necessary 24 to allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop 25 address that belongs to the IPv6 protocol. This comprises an 26 extension of the AFI/SAFI definitions to allow the address of the 27 Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 28 protocol, the encoding of the Next Hop in order to determine which of 29 the protocols the address actually belongs to, and a new BGP 30 Capability allowing MP-BGP Peers to dynamically discover whether they 31 can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on July 9, 2020. 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. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 69 3. Extension of AFI/SAFI Definitions for the IPv4 Address Family 4 70 4. Use of BGP Capability Advertisement . . . . . . . . . . . . . 6 71 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 6. Usage Examples . . . . . . . . . . . . . . . . . . . . . . . 8 73 6.1. IPv4 over IPv6 Core . . . . . . . . . . . . . . . . . . . 8 74 6.2. IPv4 VPN unicast over IPv6 Core . . . . . . . . . . . . . 9 75 6.3. IPv4 VPN multicast over IPv6 Core . . . . . . . . . . . . 9 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 81 10.2. Informative References . . . . . . . . . . . . . . . . . 11 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Introduction 86 Multiprotocol BGP (MP-BGP) [RFC4760] specifies that the set of 87 network-layer protocols to which the address carried in the Next Hop 88 field may belong is determined by the Address Family Identifier (AFI) 89 and the Subsequent Address Family Identifier (SAFI). A number of 90 existing AFI/SAFIs allow the Next Hop address to belong to a 91 different address family than the Network Layer Reachability 92 Information (NLRI). For example, the AFI/SAFI <25/65> used (as per 93 [RFC6074]) in order to perform L2VPN auto-discovery, allows 94 advertising NLRI that contains the identifier of a Virtual Private 95 LAN Service (VPLS) instance or that identifies a particular pool of 96 attachment circuits at a given Provider Edge (PE), while the Next Hop 97 field contains the loopback address of a PE. Similarly, the AFI/SAFI 98 <1/132> (defined in [RFC4684]) in order to advertise Route Target 99 (RT) membership information, allows advertising NLRI that contains 100 such RT membership information, while the Next Hop field contains the 101 address of the advertising router. 103 Furthermore, a number of these existing AFI/SAFIs allow the Next Hop 104 to belong to either the IPv4 Network Layer Protocol or the IPv6 105 Network Layer Protocol, and specify the encoding of the Next Hop 106 information in order to determine which of the protocols the address 107 actually belongs to. For example, [RFC4684] allows the Next Hop 108 address to be either IPv4 or IPv6 and states that the Next Hop field 109 address shall be interpreted as an IPv4 address whenever the length 110 of Next Hop address is 4 octets, and as an IPv6 address whenever the 111 length of the Next Hop address is 16 octets. 113 There are situations such as those described in [RFC4925] and in 114 [RFC5565] where carriers (or large enterprise networks acting as 115 carrier for their internal resources) may be required to establish 116 connectivity between 'islands' of networks of one address family type 117 across a transit core of a differing address family type. This 118 includes both the case of IPv6 islands across an IPv4 core and the 119 case of IPv4 islands across an IPv6 core. Where Multiprotocol BGP 120 (MP-BGP) is used to advertise the corresponding reachability 121 information, this translates into the requirement for a BGP speaker 122 to advertise Network Layer Reachability Information (NLRI) of a given 123 address family via a Next Hop of a different address family (i.e., 124 IPv6 NLRI with IPv4 Next Hop and IPv4 NLRI with IPv6 Next Hop). 126 The current AFI/SAFI definitions for the IPv6 address family assume 127 that the Next Hop address belongs to the IPv6 address family type. 128 Specifically, as per [RFC2545] and [RFC8277], when the is 129 <2/1>, <2/2>, or <2/4>, the Next Hop address is assumed to be of IPv6 130 type. As per [RFC4659], when the is <2/128>, the Next Hop 131 address is assumed to be of IPv6-VPN type. 133 However, [RFC4798] and [RFC4659] specify how an IPv4 address can be 134 encoded inside the Next Hop IPv6 address field when IPv6 NLRI needs 135 to be advertised with an IPv4 Next Hop. [RFC4798] defines how the 136 IPv4-mapped IPv6 address format specified in the IPv6 addressing 137 architecture ([RFC4291]) can be used for that purpose when the is <2/1>, <2/2>, or <2/4>. [RFC4659] defines how the IPv4- 139 mapped IPv6 address format as well as a null Route Distinguisher can 140 be used for that purpose when the is <2/128>. Thus, there 141 are existing solutions for the advertisement of IPv6 NLRI with an 142 IPv4 Next Hop. 144 Similarly, the current AFI/SAFI definitions for advertisement of IPv4 145 NLRI or VPN-IPv4 NLRI assume that the Next Hop address belongs to the 146 IPv4 address family type. Specifically, as per [RFC4760] and 147 [RFC8277], when the is <1/1>, <1/2>, or <1/4>, the Next 148 Hop address is assumed to be of IPv4 type. As per [RFC4364], when 149 the is <1/128>, the Next Hop address is assumed to be of 150 VPN-IPv4 type. As per [RFC6513] and [RFC6514], when the 151 is <1/129>, the Next Hop address is assumed to be of VPN-IPv4 type. 152 There is clearly no generally applicable method for encoding an IPv6 153 address inside the IPv4 address field of the Next Hop. Hence, there 154 is currently no specified solution for advertising IPv4 or VPN-IPv4 155 NLRI with an IPv6 Next Hop. 157 This document specifies the extensions necessary to do so. This 158 comprises an extension of the AFI/SAFI definitions to allow the 159 address of the Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to belong to 160 either the IPv4 or the IPv6 protocol, the encoding of the Next Hop 161 information in order to determine which of the protocols the address 162 actually belongs to, and a new BGP Capability allowing MP-BGP peers 163 to dynamically discover whether they can exchange IPv4 NLRI and VPN- 164 IPv4 NLRI with an IPv6 Next Hop. The new BGP Capability allows 165 gradual deployment of the new functionality of advertising IPv4 166 reachability via an IPv6 Next Hop, without any flag day nor any risk 167 of traffic black-holing. 169 2. Requirements Language 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 173 "OPTIONAL" in this document are to be interpreted as described in BCP 174 14 [RFC2119] [RFC8174] when, and only when, they appear in all 175 capitals, as shown here. 177 3. Extension of AFI/SAFI Definitions for the IPv4 Address Family 179 As mentioned earlier, MP-BGP specifies that the set of network-layer 180 protocols to which the address carried in the Next Hop field may 181 belong is determined by the Address Family Identifier (AFI) and the 182 Subsequent Address Family Identifier (SAFI). The following current 183 AFI/SAFI definitions for the IPv4 NLRI or VPN-IPv4 NLRI (<1/1>, 184 <1/2>, <1/4>, <1/128> and <1/129>) only have provisions for 185 advertising a Next Hop address that belongs to the IPv4 protocol. 186 This document extends the definition of the AFI/SAFI for 187 advertisement of IPv4 NLRI and VPN-IPv4 NLRI to extend the set of 188 network-layer protocols to which the Next Hop address can belong, to 189 include IPv6 in addition to IPv4. 191 Specifically, this document allows advertising with [RFC4760] of an 192 MP_REACH_NLRI with: 194 o AFI = 1 196 o SAFI = 1, 2, or 4 198 o Length of Next Hop Address = 16 or 32 200 o Next Hop Address = IPv6 address of next hop (potentially followed 201 by the link-local IPv6 address of the next hop). This field is to 202 be constructed as per Section 3 of [RFC2545]. 204 o NLRI= NLRI as per current AFI/SAFI definition 206 It also allows advertising with [RFC4760] of an MP_REACH_NLRI with: 208 o AFI = 1 210 o SAFI = 128 or 129 212 o Length of Next Hop Address = 24 or 48 214 o Next Hop Address = VPN-IPv6 address of next hop whose 8-octet RD 215 is set to zero (potentially followed by the link-local VPN-IPv6 216 address of the next hop whose 8-octet RD is set to zero). 218 o NLRI= NLRI as per current AFI/SAFI definition 220 This is in addition to the current mode of operation allowing 221 advertisement of NLRI for of <1/1>, <1/2> and <1/4> with a 222 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 224 type. 226 The BGP speaker receiving the advertisement MUST use the Length of 227 Next Hop Address field to determine which network-layer protocol the 228 next hop address belongs to. 230 o When the AFI/SAFI is <1/1>, <1/2> or <1/4> and when the Length of 231 Next Hop Address field is equal to 16 or 32, the next hop address 232 is of type IPv6. 234 o When the AFI/SAFI is <1/128>, or <1/129> and when the Length of 235 Next Hop Address field is equal to 24 or 48, the next hop address 236 is of type VPN-IPv6. 238 Note that this method of using the Length of the Next Hop Address 239 field to determine which network-layer protocol the next hop address 240 belongs to (out of the set of protocols allowed by the AFI/SAFI 241 definition) is the same as used in [RFC4684] and [RFC6074]. 243 4. Use of BGP Capability Advertisement 245 [RFC5492] defines a mechanism to allow two BGP speakers to discover 246 if a particular capability is supported by their BGP peer and thus 247 whether it can be used with that peer. This document defines a new 248 capability that can be advertised using [RFC5492] and that is 249 referred to as the Extended Next Hop Encoding capability. This 250 capability allows BGP speakers to discover whether, for a given NLRI 251 , a peer supports advertisement with a next hop whose 252 network protocol is determined by the value of the Length of Next Hop 253 Address field, as specified in Section 3. 255 A BGP speaker that wishes to advertise to a BGP peer an IPv6 Next Hop 256 for IPv4 NLRI or for VPN-IPv4 NLRI as per this specification MUST use 257 the Capability Advertisement procedures defined in [RFC5492] with the 258 Extended Next Hop Encoding Capability to establish whether its peer 259 supports this for the NLRI AFI/SAFI pair(s) of interest. The fields 260 in the Capabilities Optional Parameter MUST be set as follows: 262 o The Capability Code field MUST be set to 5 (which indicates the 263 Extended Next Hop Encoding capability). 265 o The Capability Length field is set to a variable value that is the 266 length of the Capability Value field (which follows). 268 o The Capability Value field has the following format: 270 +-----------------------------------------------------+ 271 | NLRI AFI - 1 (2 octets) | 272 +-----------------------------------------------------+ 273 | NLRI SAFI - 1 (2 octets) | 274 +-----------------------------------------------------+ 275 | Nexthop AFI - 1 (2 octets) | 276 +-----------------------------------------------------+ 277 | ..... | 278 +-----------------------------------------------------+ 279 | NLRI AFI - N (2 octets) | 280 +-----------------------------------------------------+ 281 | NLRI SAFI - N (2 octets) | 282 +-----------------------------------------------------+ 283 | Nexthop AFI - N (2 octets) | 284 +-----------------------------------------------------+ 286 where: 288 * each triple indicates that 289 NLRI of may be advertised with a Next 290 Hop address belonging to the network-layer protocol of Nexthop 291 AFI. 293 * the AFI and SAFI values are defined in the Address Family 294 Identifier and Subsequent Address Family Identifier registries 295 maintained by IANA. 297 Since this document only concerns itself with the advertisement of 298 IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop, this specification 299 only allows the following values in the Capability Value field of the 300 Extended Next Hop Encoding capability: 302 o NLRI AFI = 1 (IPv4) 304 o NLRI SAFI = 1, 2, 4, 128 or 129 306 o Nexthop AFI = 2 (IPv6) 308 This specification does not propose that the Extended Next Hop 309 Encoding capability be used with any other combinations of . In particular, this specification does not 311 propose that the Extended Next Hop Encoding capability be used for 312 NLRI AFI/SAFIs whose definition already allows use of both IPv4 and 313 IPv6 next hops (e.g., AFI/SAFI = <1/132> as defined in [RFC4684]). 314 Similarly, it does not propose that the Extended Next Hop Encoding 315 capability be used for NLRI AFI/SAFIs for which there is already a 316 solution for advertising a next hop of a different address family 317 (e.g., AFI/SAFI = <2/1>, <2/2>, or <2/4> with IPv4 Next Hop as per 318 [RFC4798] and AFI/SAFI = <2/128> with IPv4 Next Hop as per 319 [RFC4659]). 321 It is expected that if new AFI/SAFIs are defined in the future, their 322 definition will have provisions (where appropriate) for both IPv4 and 323 IPv6 Next Hops from the onset, with determination based on Length of 324 Next Hop Address field. Thus, new AFI/SAFIs are not expected to make 325 use of the Extended Next Hop Encoding capability. 327 A BGP speaker MUST only advertise to a BGP peer the IPv4 or VPN-IPv4 328 NLRI with an IPv6 Next Hop if the BGP speaker has first ascertained 329 via BGP Capability Advertisement that the BGP peer supports the 330 Extended Next Hop Encoding capability for the relevant AFI/SAFI pair. 332 The Extended Next Hop Encoding capability provides information about 333 next hop encoding for a given AFI/SAFI, assuming that AFI/SAFI is 334 allowed. It does not influence whether that AFI/SAFI is indeed 335 allowed. Whether a AFI/SAFI can be used between the BGP peers is 336 purely determined through the Multiprotocol Extensions capability 337 defined in [RFC4760]. 339 The Extended Next Hop Encoding capability MAY be dynamically updated 340 through the use of the Dynamic Capability capability and associated 341 mechanisms defined in [I-D.ietf-idr-dynamic-cap]. 343 5. Operations 345 By default, if a particular BGP session is running over IPvx (where 346 IPvx is IPv4 or IPv6), and if the BGP speaker sending an update is 347 putting its own address in as the next hop, then the next hop address 348 SHOULD be specified as an IPvx address, using the encoding rules 349 specified in the AFI/SAFI definition of the NLRI being updated. This 350 default behavior may be overridden by policy. 352 When a next hop address needs to be passed along unchanged (e.g., as 353 a Route Reflector (RR) would do), its encoding MUST NOT be changed. 354 If a particular RR client cannot handle that encoding (as determined 355 by the BGP Capability Advertisement), then the NLRI in question 356 cannot be distributed to that client. For sound routing in certain 357 scenarios, this will require that all the RR clients be able to 358 handle whatever encodings any of them may generate. 360 6. Usage Examples 362 6.1. IPv4 over IPv6 Core 364 The extensions defined in this document may be used as discussed in 365 [RFC5565] for the interconnection of IPV4 islands over an IPv6 366 backbone. In this application, Address Family Border Routers (AFBRs; 367 as defined in [RFC4925]) advertise IPv4 NLRI in the MP_REACH_NLRI 368 along with an IPv6 Next Hop. 370 The MP_REACH_NLRI is encoded with: 372 o AFI = 1 374 o SAFI = 1 376 o Length of Next Hop Network Address = 16 (or 32) 378 o Network Address of Next Hop = IPv6 address of Next Hop 380 o NLRI = IPv4 routes 382 During BGP Capability Advertisement, the PE routers would include the 383 following fields in the Capabilities Optional Parameter: 385 o Capability Code set to "Extended Next Hop Encoding" 387 o Capability Value containing 390 6.2. IPv4 VPN unicast over IPv6 Core 392 The extensions defined in this document may be used for support of 393 IPV4 VPNs over an IPv6 backbone. In this application, PE routers 394 would advertise VPN-IPv4 NLRI in the MP_REACH_NLRI along with an IPv6 395 Next Hop. 397 The MP_REACH_NLRI is encoded with: 399 o AFI = 1 401 o SAFI = 128 403 o Length of Next Hop Network Address = 24 (or 48) 405 o Network Address of Next Hop = VPN-IPv6 address of Next Hop whose 406 RD is set to zero 408 o NLRI = IPv4-VPN routes 410 During BGP Capability Advertisement, the PE routers would include the 411 following fields in the Capabilities Optional Parameter: 413 o Capability Code set to "Extended Next Hop Encoding" 415 o Capability Value containing 418 6.3. IPv4 VPN multicast over IPv6 Core 420 The extensions defined in this document may be used for support of 421 IPV4 multicast VPNs over an IPv6 backbone. In this application, PE 422 routers would advertise VPN-IPv4 NLRI in the MP_REACH_NLRI along with 423 an IPv6 Next Hop. 425 The MP_REACH_NLRI is encoded with: 427 o AFI = 1 429 o SAFI = 129 431 o Length of Next Hop Network Address = 24 (or 48) 432 o Network Address of Next Hop = VPN-IPv6 address of Next Hop whose 433 RD is set to zero 435 o NLRI = IPv4-VPN routes 437 During BGP Capability Advertisement, the PE routers would include the 438 following fields in the Capabilities Optional Parameter: 440 o Capability Code set to "Extended Next Hop Encoding" 442 o Capability Value containing 445 7. IANA Considerations 447 This document defines, in Section 4, a new Capability Code to 448 indicate the Extended Next Hop Encoding capability in the [RFC5492] 449 Capabilities Optional Parameter. The value for this new Capability 450 Code is 5, which is in the range set aside for allocation using the 451 "IETF Review" policy defined in [RFC5226]. 453 8. Security Considerations 455 This document does not raise any additional security issues beyond 456 those of BGP-4 and the Multiprotocol extensions for BGP-4. The same 457 security mechanisms are applicable. 459 Although not expected to be the typical case, the IPv6 address used 460 as the BGP Next Hop Address could be an IPv4-mapped IPv6 address (as 461 defined in [RFC4291]). Configuration of the security mechanisms 462 potentially deployed by the network operator (such as security checks 463 on next hop address) need to keep this case in mind also. 465 9. Acknowledgments 467 The authors would like to thank Francois Le Faucheur and Eric Rosen 468 for the edition and their work on [RFC5549]. 470 The authors would like to thank Yakov Rekhter, Pranav Mehta, and John 471 Scudder for their contributions to the approach defined in [RFC5549]. 473 10. References 475 10.1. Normative References 477 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 478 Requirement Levels", BCP 14, RFC 2119, 479 DOI 10.17487/RFC2119, March 1997, 480 . 482 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 483 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 484 DOI 10.17487/RFC2545, March 1999, 485 . 487 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 488 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 489 2006, . 491 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 492 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 493 2006, . 495 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 496 "Multiprotocol Extensions for BGP-4", RFC 4760, 497 DOI 10.17487/RFC4760, January 2007, 498 . 500 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 501 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 502 2009, . 504 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 505 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 506 May 2017, . 508 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 509 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 510 . 512 10.2. Informative References 514 [I-D.ietf-idr-dynamic-cap] 515 Ramachandra, S. and E. Chen, "Dynamic Capability for BGP- 516 4", draft-ietf-idr-dynamic-cap-14 (work in progress), 517 December 2011. 519 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 520 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 521 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 522 . 524 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 525 R., Patel, K., and J. Guichard, "Constrained Route 526 Distribution for Border Gateway Protocol/MultiProtocol 527 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 528 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 529 November 2006, . 531 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 532 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 533 Provider Edge Routers (6PE)", RFC 4798, 534 DOI 10.17487/RFC4798, February 2007, 535 . 537 [RFC4925] Li, X., Ed., Dawkins, S., Ed., Ward, D., Ed., and A. 538 Durand, Ed., "Softwire Problem Statement", RFC 4925, 539 DOI 10.17487/RFC4925, July 2007, 540 . 542 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 543 IANA Considerations Section in RFCs", RFC 5226, 544 DOI 10.17487/RFC5226, May 2008, 545 . 547 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 548 Layer Reachability Information with an IPv6 Next Hop", 549 RFC 5549, DOI 10.17487/RFC5549, May 2009, 550 . 552 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 553 Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, 554 . 556 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 557 "Provisioning, Auto-Discovery, and Signaling in Layer 2 558 Virtual Private Networks (L2VPNs)", RFC 6074, 559 DOI 10.17487/RFC6074, January 2011, 560 . 562 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 563 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 564 2012, . 566 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 567 Encodings and Procedures for Multicast in MPLS/BGP IP 568 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 569 . 571 Authors' Addresses 573 Stephane Litkowski 574 Cisco 576 Email: slitkows@cisco.com 578 Swadesh Agrawal 579 Cisco 581 Email: swaagrawa@cisco.com 583 Krishna Muddenahally Ananthamurthy 584 Cisco 586 Email: kriswamy@cisco.com 588 Keyur Patel 589 Arrcus 591 Email: keyur@arrcus.com