idnits 2.17.1 draft-ietf-l3vpn-bgp-ipv6-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([2547bis]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 65: '...ogical interface MAY be used for both ...' RFC 2119 keyword, line 107: '...E-PE tunnel mesh MAY be used for both;...' RFC 2119 keyword, line 147: '...6-capable, the same RD MAY be used for...' RFC 2119 keyword, line 203: '...tising PE router MUST also assign and ...' RFC 2119 keyword, line 212: '... and SAFI fields MUST be set as follow...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 71 has weird spacing: '...tribute route...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2004) is 7248 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) == Missing Reference: 'MP-BGP' is mentioned on line 196, but not defined == Missing Reference: 'BGP-EXTCOM' is mentioned on line 284, but not defined == Missing Reference: 'LDP' is mentioned on line 361, but not defined == Unused Reference: 'BGP-EXTCOMM' is defined on line 456, but no explicit reference was found in the text == Unused Reference: 'IPv6' is defined on line 462, but no explicit reference was found in the text == Unused Reference: 'MPLS-ARCH' is defined on line 465, but no explicit reference was found in the text == Unused Reference: 'MPLS-ENCAPS' is defined on line 471, but no explicit reference was found in the text == Unused Reference: 'MPLS-LDP' is defined on line 477, but no explicit reference was found in the text == Unused Reference: 'TRANS' is defined on line 495, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BGP-EXTCOMM' ** Obsolete normative reference: RFC 2858 (ref. 'BGP-MP') (Obsoleted by RFC 4760) ** Obsolete normative reference: RFC 2460 (ref. 'IPv6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3107 (ref. 'MPLS-BGP') (Obsoleted by RFC 8277) ** Obsolete normative reference: RFC 3392 (ref. 'BGP-CAP') (Obsoleted by RFC 5492) ** Obsolete normative reference: RFC 3036 (ref. 'MPLS-LDP') (Obsoleted by RFC 5036) -- Obsolete informational reference (is this intentional?): RFC 3513 (ref. 'V6ADDR') (Obsoleted by RFC 4291) -- Obsolete informational reference (is this intentional?): RFC 2893 (ref. 'TRANS') (Obsoleted by RFC 4213) == Outdated reference: A later version (-05) exists of draft-nalawade-kapoor-tunnel-safi-00 Summary: 12 errors (**), 0 flaws (~~), 12 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Jeremy De Clercq 3 Dirk Ooms 4 Alcatel 5 Marco Carugi 6 Nortel Networks 7 Francois Le Faucheur 8 Cisco Systems 10 June 2004 11 Expires December, 2004 13 BGP-MPLS VPN extension for IPv6 VPN 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months. Internet-Drafts may be updated, replaced, or obsoleted by 26 other documents at any time. It is not appropriate to use Internet- 27 Drafts as reference material or to cite them other than as a 28 ``working draft'' or ``work in progress.'' 30 To view the entire list of current Internet-Drafts, please check the 31 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 32 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 33 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au(Pacific 34 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 36 Distribution of this memo is unlimited. 38 Abstract 40 This document describes a method by which a Service Provider may use 41 its packet switched backbone to provide Virtual Private Network 42 services for its IPv6 customers. This method extends the "BGP/MPLS 43 VPN" method [2547bis] for support of IPv6. In BGP/MPLS VPN, 44 "Multiprotocol BGP" is used for distributing IPv4 VPN routes over the 45 service provider backbone and MPLS is used to forward IPv4 VPN 46 packets over the backbone. This document defines an IPv6 VPN address 47 family and describes the corresponding route distribution in 48 "Multiprotocol BGP". This document defines support of the IPv6 VPN 49 service over both an IPv4 and an IPv6 backbone, and using various 50 tunnelling techniques over the core including MPLS, IPsec, IP-in-IP 51 and GRE. 53 1. Introduction 55 This document adopts the definitions, acronyms and mechanisms 56 described in [2547bis]. Unless otherwise stated, the mechanisms of 57 [2547bis] apply and will not be re-described here. 59 A VPN is said to be an IPv6 VPN, when each site of this VPN is IPv6 60 capable and is natively connected over an IPv6 interface or sub- 61 interface to the SP backbone via a Provider Edge device (PE). 63 A site may be both IPv4- and IPv6-capable. The logical interface on 64 which packets arrive at the PE may determine the version, but 65 alternatively the same logical interface MAY be used for both IPv4 66 and IPv6 in which case a per-packet header lookup determines the 67 version. This document only concerns itself with handling of the IPv6 68 packets. 70 In a similar manner to how IPv4 VPN routes are distributed in 71 [2547bis], BGP and its extensions are used to distribute routes from 72 an IPv6 VPN site to all the other PE routers connected to a site of 73 the same IPv6 VPN. PEs use VRFs to separately maintain the 74 reachability information and forwarding information of each IPv6 VPN. 76 As it is done for IPv4 VPNs [2547bis], we allow each IPv6 VPN to have 77 its own IPv6 address space, which means that a given address may 78 denote different systems in different VPNs. This is achieved via a 79 new address family, the VPN-IPv6 Address Family, in a fashion similar 80 to the VPN-IPv4 address family definition given by [2547bis]. 82 In addition to operation over MPLS Label Switched Paths (LSPs), the 83 BGP/MPLS VPN solution is extended to allow operation over other 84 tunnelling techniques including GRE tunnels, IP-in-IP tunnels [2547- 85 GRE/IP] and IPsec tunnels [2547-IPsec]. In a similar manner, this 86 document allows support of an IPv6 VPN service over MPLS LSPs as well 87 as over other tunnelling techniques including GRE tunnels, IP-in-IP 88 tunnels and IPsec tunnels. 90 This document allows support for an IPv6 VPN service over an IPv4 91 backbone as well as over an IPv6 backbone. The IPv6 VPN service 92 supported is identical in both cases. 94 The IPv6 VPN solution defined in this document offers the following 95 benefits: 97 o from both the Service Provider perspective and the customer 98 perspective, the VPN service that can be supported for IPv6 sites 99 is identical to the one that can be suported for IPv4 sites; 101 o from the Service Provider perspective, operations of the IPv6 102 VPN service require the exact same skills, procedures and 103 mechanisms as for the IPv4 VPN service; 105 o where both IPv4 VPNs and IPv6 VPN services are supported over an 106 IPv4 core, the same single set of MP-BGP peering relationships and 107 the same single PE-PE tunnel mesh MAY be used for both; 109 o independence of whether the core runs IPv4 or IPv6. So that the 110 IPv6 VPN service supported before, and after a migration of the 111 core from IPv4 to IPv6 is undistinguishable to the VPN customer. 113 2. The VPN Address Family 115 The BGP Multiprotocol Extensions [BGP-MP] allow BGP to carry routes 116 from multiple "address families". We introduce the notion of the 117 "VPN-IPv6 address family", that is similar to the VPN-IPv4 address 118 family introduced in [2547bis]. 120 2.1 The VPN-IPv6 Address Family 122 A VPN-IPv6 address is a 24-byte quantity, beginning with an 8-byte 123 "Route Distinguisher" (RD) and ending with a 16-byte IPv6 address. 124 If two VPNs use the same IPv6 address prefix (effectively denoting 125 different physical systems), the PEs translate these into unique 126 VPN-IPv6 address prefixes using different RDs. This ensures that if 127 the same address is used in two different VPNs, it is possible to 128 install two completely different routes to that address, one for each 129 VPN. 131 The purpose of the RD is solely to allow one to create distinct 132 routes to a common IPv6 address prefix, similarly to the purpose of 133 the RD defined in [2547bis]. As it is possible per [2547bis], the RD 134 can also be used to create multiple different routes to the very same 135 system. This can be achieved by creating two different VPN-IPv6 136 routes that have the same IPv6 part, but different RDs. This allows 137 BGP to install multiple different routes to the same system, and 138 allows policy to be used to decide which packets use which route. 140 Note that VPN-IPv6 addresses and IPv6 addresses are always considered 141 by BGP to be incomparable. 143 A VRF may have multiple equal-cost VPN-IPv6 routes for a single IPv6 144 address prefix. When a packet's destination address is matched in a 145 VRF against a VPN-IPv6 route, only the IPv6 part is actually matched. 147 When a site is IPv4- and IPv6-capable, the same RD MAY be used for 148 the advertisement of IPv6 addresses and IPv4 addresses. 150 2.2. Encoding of Route Distinguishers 152 The RDs are encoded as per [2547bis]: 154 - TYPE field: 2 bytes 156 - VALUE field: 6 bytes 158 The interpretation of the VALUE field depends on the value of the 159 TYPE field. As it is the case in [2547bis], 3 encodings can be used: 161 - TYPE field = 0 : the VALUE field consists of the following two 162 subfields: 164 * Administrator subfield: 2 bytes, it contains an Autonomous 165 System Number 166 * Assigned Number subfield: 4 bytes 168 - TYPE field = 1 : the VALUE field consists of the following two 169 subfields: 171 * Administrator subfield: 4 bytes, it contains a global IPv4 172 address 173 * Assigned Number subfield: 2 bytes 175 - TYPE field = 2 : the VALUE field consists of the following two 176 subfields: 178 * Administrator subfield: 4 bytes, it contains a 4-byte Autonomous 179 System Number 180 * Assigned Number subfield: 2 bytes 182 3. VPN-IPv6 route distribution 184 3.1. Route Distribution Among PEs by BGP 186 As described in [2547bis], if two sites of a VPN attach to PEs which 187 are in the same Autonomous System, the PEs can distribute VPN routes 188 to each other by means of an (IPv4) iBGP connection between them. 189 Alternatively, each PE can have an iBGP connection to a route 190 reflector. Similarly, for IPv6 VPN route distribution, PEs can use an 191 iBGP connection between them or use iBGP connections to a route 192 reflector. 194 The PE routers: 196 (i) exchange, via MP-BGP [MP-BGP], reachability information for the 197 IPv6 prefixes in the IPv6 VPNs. 199 (ii) announce themselves as the BGP Next Hop. 201 3.2 VPN IPv6 NLRI encoding 203 The advertising PE router MUST also assign and distribute MPLS labels 204 with the IPv6 VPN routes. Essentially, PE routers do not distribute 205 IPv6 VPN routes, but Labeled IPv6 VPN routes [MPLS-BGP]. When the 206 advertising PE receives a packet that has this particular advertised 207 label, the PE will pop the MPLS stack, and process the packet 208 appropriately (i.e. forward it directly based on the label or perform 209 a lookup in the corresponding IPv6-VPN context). 211 The BGP Multiprotocol Extensions [BGP-MP] are used to encode the 212 MP_REACH NLRI. The AFI and SAFI fields MUST be set as follows: 214 - AFI: 2; for IPv6 216 - SAFI: 128; for MPLS labeled VPN-IPv6 218 The labeled VPN-IPv6 MP_REACH_NLRI itself is encoded as specified in 219 [MPLS-BGP]. In the context of this extension, the prefix belongs to 220 the VPN-IPv6 Address Family and thus consists of an 8-byte Route 221 Distinguisher followed by an IPv6 prefix as specified in section 2 222 above. 224 3.2.1 BGP Next Hop encoding 226 3.2.1.1 BGP speakers with IPv6 connectivity 228 A BGP speaker SHALL advertise to its peers a Next Hop Network Address 229 field containing a VPN-IPv6 address: 231 - whose RD is set to zero, and 233 - whose 16-byte IPv6 address is set to the global IPv6 address of 234 the advertising PE. 236 potentially followed by another VPN-IPv6 address: 238 - whose RD is set to zero, and 240 - whose 16-byte IPv6 address is set to the link-local IPv6 address 241 of the advertising PE. 243 The value of the Length ofth Next Hop Network Address field in the 244 MP_REACH_NLRI attribute shall be set to 24 when only a global address 245 is present, or 48 if a link-local address is also included in the 246 Next Hop field. 248 The link-local address shall be included in the Next Hop field if and 249 only if the advertising BGP speaker shares a common subnet with the 250 peer the route is being advertised to [RFC2545]. 252 In all other cases, a BGP speaker shall advertise to its peer in the 253 Next Hop Network Address field only the global IPv6 address of the 254 next hop. 256 As a consequence, a BGP speaker that advertises a route to an 257 internal peer may modify the Network Address of Next Hop field by 258 removing the link-local IPv6 address of the next hop. 260 An example scenario where both the global IPv6 address and the link- 261 local IPv6 address shall be included in the BGP Next Hop address 262 field is where the IPv6 VPN service is supported over a multi-AS 263 backbone with redistribution of labeled VPN-IPv6 routes between ASBRs 264 (of different AS) sharing a common IPv6 subnet: in that case, both 265 the global IPv6 address and the link-local IPv6 address shall be 266 advertised by the ASBRs. 268 3.2.1.2 BGP Speakers with IPv4 connectivity 270 A BGP speaker SHALL advertise to its peer a Next Hop Network Address 271 field containing a VPN-IPv6 address: 273 - whose RD is set to zero, and 275 - whose 16-byte IPv6 address is encoded as an IPv4-mapped IPv6 276 address [V6ADDR] containing the IPv4 address of the advertising 277 PE. This IPv4 address must be routable in the Service Provider's 278 backbone. 280 3.3. Route Target 282 The use of route target is specified in [2547bis] and applies to IPv6 283 VPNs. Encoding of the extended community attribute is defined in 284 [BGP-EXTCOM]. 286 3.4 BGP Capability Negotiation 288 In order for two PEs to exchange labelled IPv6 VPN NLRIs, they MUST 289 use BGP Capabilities Negotiation to ensure that they both are capable 290 of properly processing such NLRIs. This is done as specified in 292 [BGP-MP] and [BGP-CAP], by using capability code 1 (multiprotocol 293 BGP), with AFI and SAFI values as specified above in section 3.2. 295 4. Determination of Tunnel Type 297 As mentioned earlier, this document allows support of IPv6 VPN 298 service using various tunneling techniques in the core. 300 The tunneling type to use in the core for IPv6 VPN MAY be determined 301 via configuration of PEs. Alternatively a mechanism to dynamically 302 determine the tunneling type to use MAY be deployed (see for example 303 [ENCAP-SIG] or [TUN-SAFI] and [SSA]). 305 5. Encapsulation 307 The ingress PE Router MUST tunnel IPv6 VPN data over the backbone 308 towards the Egress PE router identified as the BGP Next Hop for the 309 corresponding IPv6 VPN prefix. 311 When the 16-byte IPv6 address contained in the BGP Next Hop field is 312 encoded as an IPv4-mapped IPv6 address (see section 3.2.1.2), the 313 ingress PE MUST use IPv4 tunnelling. 315 When the 16-byte IPv6 address contained in the BGP Next Hop field is 316 not encoded as an IPv4-mapped address (see section 3.2.1.2), the 317 ingress PE MUST use IPv6 tunnelling. 319 Regardless of whether it is IPv4 or IPv6 tunnelling, the tunnelling 320 type is determined as discussed above in section 4. 322 When a PE receives a packet from a CE, it looks up the packet's IPv6 323 destination address in the VRF corresponding to that CE. This enables 324 it to find a VPN-IPv6 route. The VPN-IPv6 route will have an 325 associated MPLS label and an associated BGP Next Hop. First, this 326 MPLS label is pushed on the packet. Then, this labelled packet is 327 encapsulated into the tunnel for transport to the egress PE 328 identified as the BGP Next Hop. Details of this encapsulation depend 329 on the actual tunnelling technique as follows: 331 As with MPLS/BGP for IPv4 VPNs [2547-GRE/IP], when tunnelling is done 332 using IPv4 tunnels or IPv6 tunnels (resp. IPv4 GRE tunnels or IPv6 333 GRE tunnels), encapsulation of the labelled IPv6 VPN packet results 334 in an MPLS-in-IP (resp. MPLS-in-GRE) encapsulated packet as specified 335 in [MPLS-in-IP/GRE]. 337 As with MPLS/BGP for IPv4 VPNs, when tunnelling is done using an 338 IPsec secured tunnel [2547-IPsec], encapsulation of the labelled IP6 339 VPN packet results in an MPLS-in-IP or MPLS-in-GRE encapsulated 340 packet [MPLS-in-IP/GRE]. The IPsec Transport Mode is used to secure 341 this IPv4 or GRE tunnel from ingress PE to egress PE. 343 When tunnelling is done using IPv4 tunnels or IPv4 GRE tunnels 344 (whether IPsec secured or not), the Ingress PE Router MUST use the 345 IPv4 address which is encoded in the IPv4-mapped IPv6 address field 346 of the BGP next hop field, as the destination address of the 347 prepended IPv4 tunnelling header. It uses one of its IPv4 addresses 348 as the source address of the prepended IPv4 tunneling header. 350 When tunnelling is done using IPv6 tunnels or IPv6 GRE tunnels 351 tunnels (whether IPsec secured or not), the Ingress PE Router MUST 352 use the IPv6 address which is contained in the IPv6 address field of 353 the BGP next hop field, as the destination address of the prepended 354 IPv6 tunnelling header. It uses one of its IPv6 addresses as the 355 source address of the prepended IPv6 tunneling header. 357 When tunneling is done using MPLS LSPs, the LSPs can be established 358 using any label distribution technique (LDP[LDP], RSVP-TE [RSVP-TE], 359 ...). Nevertheless, to ensure interoperability among systems that 360 implement this VPN architecture using MPLS LSPs as the tunneling 361 technology, all such systems MUST support LDP [LDP]. 363 When tunnelling is done using MPLS LSPs, the ingress PE Router 364 directly pushes the LSP tunnel label on the label stack of the 365 labelled IPv6 VPN packet (i.e. without prepending any IPv4 or IPv6 366 header). This pushed label corresponds to the LSP starting on the 367 ingress PE Router and ending on the egress PE Router. The BGP Next 368 Hop field is used to identify the egress PE router and as such the 369 label to be pushed on the stack. In case the IPv6 address in the BGP 370 Next Hop field is a IPv4-mapped IPv6 address, the embedded IPv4 371 address will determine the tunnel label to push on the label stack. 372 In any other case, the IPv6 address in the BGP Next Hop field will 373 determine the tunnel label to push on the label stack. 375 The bottom label is the label bound to the IPv6 VPN Prefix via BGP. 377 6. Address Scope 379 Since Link-local scope addresses are defined as uniquely identifying 380 interfaces within (i.e., attached to) a single link only (see 381 [SCOPE-ARCH]), those may be used on the PE-CE link but they are not 382 supported for reachability across IPv6 VPN Sites and are never 383 advertised via MP-BGP to remote PEs. 385 Global scope addresses are defined as uniquely identifying interfaces 386 anywhere in the Internet. Global addresses are expected to be 387 commonly used within and across IPv6 VPN Sites. They are obviously 388 supported by this IPv6 VPN solution for reachability across IPv6 VPN 389 Sites and advertised via MP-BGP to remote PEs and processed without 390 any specific considerations to their Global scope. 392 7. Multicast 394 Multicast operations is outside the scope of this document. 396 8. Inter-Provider Backbones 398 The same mechanisms described in [2547bis] can be used and have the 399 same scalability properties. 401 9. Accessing the Internet from a VPN 403 The methods proposed by [2547bis] to access the global Internet can 404 be used in the context of IPv6 VPNs and the global IPv6 Internet. 405 Note however that if the IPv6 packets destined for the global IPv6 406 Internet need to traverse the SP backbone, and if this is an IPv4 407 only backbone, they must be tunnelled through that IPv4 backbone. 409 10. Management VPN 411 Where the IPv6 VPN service is supported over an IPv4 backbone, and 412 where the Service Provider manages the CE, the Service Provider may 413 elect to use IPv4 for communication between the management tool and 414 the CE for such management purposes. In that case, regardless of 415 whether a customer IPv4 site is actually connected to the CE or not, 416 the CE is effectively part of an IPv4 VPN (i.e. it is attached to an 417 IPv4 VRF) in addition to belonging to an IPv6 VPN. Considerations 418 presented in [2547bis] on how to ensure that the management tool can 419 communicate with such managed CEs from multiple VPNs without allowing 420 undesired reachability across CEs of different VPNs, are applicable 421 to the IPv4 VRF to which the CE attaches. 423 Where the IPv6 VPN service is supported over an IPv4 backbone, and 424 where the Service Provider manages the CE, the Service Provider may 425 elect to use IPv6 for communication between the management tool and 426 the CE for such management purposes. Considerations presented in 427 [2547bis] on how to ensure that the management tool can communicate 428 with such managed CEs from multiple VPNs without allowing undesired 429 reachability across CEs of different VPNs, are then applicable to the 430 IPv6 VRF to which the CE attaches. 432 11. Security 434 The same security concerns as in [2547bis] are applicable. 436 12. Quality of Service 438 [2547bis] is applicable. 440 13. Acknowledgements 442 We would like to thank Gerard Gastaud who largely contributed to this 443 document. 445 In Memoriam: 447 The authors would like to acknowledge the valuable contribution to 448 this document from Tri T. Nguyen, who passed away in April 2002 after 449 a sudden illness. 451 14. Normative References 453 [2547bis] Rosen et al., "BGP/MPLS VPNs", draft-ietf-l3vpn-rfc2547bis, 454 work in progress 456 [BGP-EXTCOMM] Ramachandra, Tappan, Rekhter, "BGP Extended Communities 457 Attribute", work in progress 459 [BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol Extensions 460 for BGP4", June 2000, RFC2858 462 [IPv6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 463 (IPv6) Specification", RFC2460. 465 [MPLS-ARCH] Rosen, Viswanathan, and Callon, "Multiprotocol Label 466 Switching Architecture", RFC3031 468 [MPLS-BGP] Rekhter and Rosen, "Carrying Label Information in BGP4", 469 RFC3107 471 [MPLS-ENCAPS] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and 472 Conta, "MPLS Label Stack Encoding", RFC3032 474 [BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with 475 BGP-4", November 2002, RFC3392 477 [MPLS-LDP] Andersson, Doolan, Feldman, Fredette, Thomas, "LDP 478 Specification", RFC3036 480 [RFC2545] Marques, P., Dupont, F., "Use of BGP-4 Multiprotocol 481 Extensions for IPv6 Inter-Domain Routing", March 1999, RFC2545 483 15. Informative References 485 [V6ADDR] Deering, S., and Hinden, R., "IP Version 6 Addressing 486 Architecture", April 2003, RFC3513 488 [2547-GRE/IP] Rekhter and Rosen, "Use of PE-PE GRE or IP in RFC2547 489 VPNs", draft-ietf-l3vpn-gre-ip-2547, work in progress 491 [2547-IPsec] Rosen, De Clercq, Paridaens, T'Joens, Sargor, "Use of 492 PE-PE IPsec in RFC2547 VPNs", draft-ietf-l3vpn-ipsec-2547, work in 493 progress 495 [TRANS] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6 496 Hosts and Routers", RFC2893. 498 [SCOPE-ARCH] Deering, S., et al., "IPv6 Scoped Address Architecture", 499 draft-ietf-ipv6-scoping-arch, work in progress 501 [RSVP-TE] Awduche, D., et al., "RSVP-TE: Extensions to RSVP for LSP 502 Tunnels", December 2001, RFC3209 504 [MPLS-in-IP/GRE] Worster, T., et al., "Encapsulating MPLS in IP or 505 GRE", draft-ietf-mpls-in-ip-or-gre, work in progress 507 [ENCAP-SIG] Aggarwal, R., et al., "Signaling Tunnel 508 Encapsulation/Deencapsulation capabilities", draft-raggarwa-ppvpn- 509 tunnel-encap-sig, work in progress 511 [TUN-SAFI] Nalawade, et al., "IPv4 Tunnel SAFI", draft-nalawade- 512 kapoor-tunnel-safi-00, work in progress 514 [SSA] Kapoor, et al., "BGP-4 SAFI-specific Attribute", draft-kapoor- 515 nalawade-idr-bgp-ssa, work in progress 517 16. Authors' Addresses 519 Jeremy De Clercq 520 Alcatel 521 Fr. Wellesplein 1, 2018 Antwerpen, Belgium 522 E-mail: jeremy.de_clercq@alcatel.be 524 Dirk Ooms 525 Alcatel 526 Fr. Wellesplein 1, 2018 Antwerpen, Belgium 527 E-mail: dirk.ooms@alcatel.be 529 Marco Carugi 530 Nortel Networks S.A. 532 Parc d'activites de Magny-Les Jeunes Bois CHATEAUFORT 533 78928 YVELINES Cedex 9 - France 534 E-mail: marco.carugi@nortelnetworks.com 536 Francois Le Faucheur 537 Cisco Systems, Inc. 538 Village d'Entreprise Green Side - Batiment T3 539 400, Avenue de Roumanille 540 06410 Biot-Sophia Antipolis 541 France 542 E-mail: flefauch@cisco.com