idnits 2.17.1 draft-ietf-l3vpn-bgp-ipv6-00.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. == Mismatching filename: the document gives the document name as 'draft-ietf-l3vpn-bgp-ipv6-vpn-00', but the file name used is 'draft-ietf-l3vpn-bgp-ipv6-00' == 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 205: '...tising PE router MUST also assign and ...' RFC 2119 keyword, line 214: '... and SAFI fields MUST be set as follow...' RFC 2119 keyword, line 237: '...the BGP Next Hop MUST contain a VPN-IP...' RFC 2119 keyword, line 251: '...the BGP Next Hop MUST contain a VPN-IP...' RFC 2119 keyword, line 290: '...nfiguration, MPLS LSPs MUST be used to...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 70 has weird spacing: '...tribute route...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (November 2002) is 7833 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 198, but not defined == Missing Reference: 'BGP-EXTCOM' is mentioned on line 264, but not defined == Missing Reference: 'ADDRARCH' is mentioned on line 369, but not defined == Unused Reference: 'BGP-EXTCOMM' is defined on line 527, but no explicit reference was found in the text == Unused Reference: 'IPv6' is defined on line 538, but no explicit reference was found in the text == Unused Reference: 'MPLS-ARCH' is defined on line 541, but no explicit reference was found in the text == Unused Reference: 'MPLS-ENCAPS' is defined on line 547, but no explicit reference was found in the text == Unused Reference: 'MPLS-LDP' is defined on line 550, but no explicit reference was found in the text == Unused Reference: 'TRANS' is defined on line 553, but no explicit reference was found in the text -- No information found for draft-ietf-ppvpn-rfc2547bis - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2547bis' -- No information found for draft-ietf-ppvpn-ipsec-2547 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2547-IPsec' == Outdated reference: A later version (-09) exists of draft-ietf-idr-bgp-ext-communities-05 ** Obsolete normative reference: RFC 2858 (ref. 'BGP-MP') (Obsoleted by RFC 4760) -- Unexpected draft version: The latest known version of draft-ietf-idr-rfc2842bis is -01, but you're referring to -02. (However, the state information for draft-ietf-ppvpn-ipsec-2547 is not up-to-date. The last update was unsuccessful) ** 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 3036 (ref. 'MPLS-LDP') (Obsoleted by RFC 5036) ** Obsolete normative reference: RFC 2893 (ref. 'TRANS') (Obsoleted by RFC 4213) -- Possible downref: Normative reference to a draft: ref. 'SCOPE-ARCH' -- Possible downref: Normative reference to a draft: ref. 'TUNNEL-ATTR' -- Duplicate reference: RFC3036, mentioned in 'LDP', was also mentioned in 'MPLS-LDP'. ** Obsolete normative reference: RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) == Outdated reference: A later version (-05) exists of draft-worster-mpls-in-ip-03 -- Possible downref: Normative reference to a draft: ref. 'MPLS-in-IP' == Outdated reference: A later version (-03) exists of draft-rekhter-mpls-over-gre-01 -- Possible downref: Normative reference to a draft: ref. 'MPLS-in-GRE' Summary: 14 errors (**), 0 flaws (~~), 16 warnings (==), 11 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 Gerard Gastaud 5 Alcatel 6 Marco Carugi 7 Nortel Networks 8 Francois Le Faucheur 9 Cisco Systems 11 November 2002 12 Expires May, 2003 14 BGP-MPLS VPN extension for IPv6 VPN 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months. Internet-Drafts may be updated, replaced, or obsoleted by 27 other documents at any time. It is not appropriate to use Internet- 28 Drafts as reference material or to cite them other than as a 29 ``working draft'' or ``work in progress.'' 31 To view the entire list of current Internet-Drafts, please check the 32 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 33 Directorieson ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 34 ftp.nis.garr.it (Southern Europe), munnari.oz.au(Pacific Rim), 35 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 37 Distribution of this memo is unlimited. 39 Abstract 41 This document describes a method by which a Service Provider may use 42 its packet switched backbone to provide Virtual Private Network 43 services for its IPv6 customers. This method extends the "BGP/MPLS 44 VPN" method [2547bis] for support of IPv6. In BGP/MPLS VPN, 45 "Multiprotocol BGP" is used for distributing IPv4 VPN routes over the 46 service provider backbone and MPLS is used to forward IPv4 VPN 47 packets over the backbone. This document defines an IPv6 VPN address 48 family and describes the corresponding route distribution in 49 "Multiprotocol BGP". This document defines support of the IPv6 VPN 50 srvice over both an IPv4 and an IPv6 backbone, and using various 51 tunnelling techniques over the core including MPLS, IPsec, IP-in-IP 52 and GRE. 54 1. Introduction 56 This document adopts the definitions, acronyms and mechanisms 57 described in [2547bis]. Unless otherwise stated, the mechanisms of 58 [2547bis] apply and will not be re-described here. 60 A VPN is said to be an IPv6 VPN, when each site of this VPN is IPv6 61 capable and is natively connected over an IPv6 interface or sub- 62 interface to the SP backbone via a Provider Edge device (PE). 64 A site may be both IPv4- and IPv6-capable. The logical interface on 65 which packets arrive at the PE may determine the version, but 66 alternatively a per-packet header lookup may determine the version. 67 This document only concerns itself with handling of the IPv6 packets. 69 In a similar manner to how IPv4 VPN routes are distributed in 70 [2547bis], BGP and its extensions are used to distribute routes from 71 an IPv6 VPN site to all the other PE routers connected to a site of 72 the same IPv6 VPN. PEs use VRFs to separately maintain the 73 reachability information and forwarding information of each IPv6 VPN. 75 As it is done for IPv4 VPNs [2547bis], we allow each IPv6 VPN to have 76 its own IPv6 address space, which means that a given address may 77 denote different systems in different VPNs (as may be required when 78 site-local addresses are used by the end customers). This is achieved 79 via a new address family, the VPN-IPv6 Address Family, in a fashion 80 similar to the VPN-IPv4 address family definition given by [2547bis]. 82 In addition to operation over MPLS Label Switched Paths (LSPs), the 83 MPLS/BGP 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. Similar BGP-based negotiation and 89 discovery [TUNNEL-ATTR] mechanisms are proposed to dynamically 90 determine which tunnelling technique is to be used in a given 91 network. 93 This document allows support for an IPv6 VPN service over an IPv4 94 backbone as well as over an IPv6 backbone. The IPv6 VPN service 95 supported is identical in both cases. 97 The IPv6 VPN solution defined in this document offers the following 98 benefits: 100 o from both the Service Provider perspective and the customer 101 perspective, the VPN service that can be supported for IPv6 sites 102 is identical to the one that can be supported for IPv4 sites; 104 o from the Service Provider perspective, operations of the IPv6 105 VPN service require the exact same skills, procedures and 106 mechanisms as for the IPv4 VPN service; 108 o where both IPv4 VPNs and IPv6 VPN services are suppported over 109 an IPv4 core, the same single set of MP-BGP peering relationships 110 and the same single PE-PE tunnel mesh can be used for both; 112 o independence of whether the core runs IPv4 or IPv6. So that the 113 IPv6 VPN service suppported before, and after a migration of the 114 core from IPv4 to IPv6 is undistinguishable to the VPN customer. 116 2. The VPN Address Family 118 The BGP Multiprotocol Extensions [BGP-MP] allow BGP to carry routes 119 from multiple "address families". We introduce the notion of the 120 "VPN-IPv6 address family", that is similar to the VPN-IPv4 address 121 family introduced in [2547bis]. 123 2.1 The VPN-IPv6 Address Family 125 A VPN-IPv6 address is a 24-byte quantity, beginning with an 8-byte 126 "Route Distinguisher" (RD) and ending with a 16-byte IPv6 address. 127 If two VPNs use the same IPv6 address prefix (effectively denoting 128 different physical systems), the PEs translate these into unique 129 VPN-IPv6 address prefixes using different RDs. This ensures that if 130 the same address is used in two different VPNs, it is possible to 131 install two completely different routes to that address, one for each 132 VPN. 134 The purpose of the RD is solely to allow one to create distinct 135 routes to a common IPv6 address prefix, similarly to the purpose of 136 the RD defined in [2547bis]. As it is possible per [2547bis], the RD 137 can also be used to create multiple different routes to the very same 138 system. This can be achieved by creating two different VPN-IPv6 139 routes that have the same IPv6 part, but different RDs. This allows 140 BGP to install multiple different routes to the same system, and 141 allows policy to be used to decide which packets use which route. 143 Note that VPN-IPv6 addresses and IPv6 addresses are always considered 144 by BGP to be incomparable. 146 A VRF may have multiple equal-cost VPN-IPv6 routes for a single IPv6 147 address prefix. When a packet's destination address is matched 148 against a VPN-IPv6 route, only the IPv6 part is actually matched. 150 When a site is IPv4- and IPv6-capable, the same RD can be used for 151 the advertisement of IPv6 addresses and IPv4 addresses. 153 2.2. Encoding of Route Distinguishers 155 The RDs are encoded as per [2547bis]: 157 - TYPE field: 2 bytes 159 - VALUE field: 6 bytes 161 The interpretation of the VALUE field depends on the value of the 162 TYPE field. As it is the case in [2547bis], 3 encodings can be used: 164 - TYPE field = 0 : the VALUE field consists of the following two 165 subfields: 167 * Administrator subfield: 2 bytes, it contains an Autonomous 168 System Number 169 * Assigned Number subfield: 4 bytes 171 - TYPE field = 1 : the VALUE field consists of the following two 172 subfields: 174 * Administrator subfield: 4 bytes, it contains a global IPv4 175 address 176 * Assigned Number subfield: 2 bytes 178 - TYPE field = 2 : the VALUE field consists of the following two 179 subfields: 181 * Administrator subfield: 4 bytes, it contains a 4-byte Autonomous 182 System Number 183 * Assigned Number subfield: 2 bytes 185 3. VPN-IPv6 route distribution 187 3.1. Route Distribution Among PEs by BGP 189 As described in [2547bis], if two sites of a VPN attach to PEs which 190 are in the same Autonomous System, the PEs can distribute VPN routes 191 to each other by means of an (IPv4) IBGP connection between them. 192 Alternatively, each can have an IBGP connection to a route reflector. 193 Similarly, for IPv6 VPN route distribution, PEs can use an iBGP 194 connection between them or use iBGP connections to a route reflector. 196 The PE routers: 198 (i) exchange, via MP-BGP [MP-BGP], reachability information for the 199 IPv6 prefixes in the IPv6 VPNs. 201 (ii) announce themselves as the BGP Next Hop. 203 3.2 VPN IPv6 NLRI encoding 205 The advertising PE router MUST also assign and distribute MPLS labels 206 with the IPv6 VPN routes. Essentially, PE routers do not distribute 207 IPv6 VPN routes, but Labeled IPv6 VPN routes [MPLS-BGP]. When the 208 advertising PE receives a packet that has this particular advertised 209 label, the PE will pop the MPLS stack, and process the packet 210 appropriately (i.e. forward it directly based on the label or perform 211 a lookup in the corresponing IPv6-VPN context). 213 The BGP Multiprotocol Extensions [BGP-MP] are used to encode the 214 MP_REACH NLRI. The AFI and SAFI fields MUST be set as follows: 216 - AFI: 2; for IPv6 218 - SAFI: 128; for MPLS labeled VPN-IPv6 220 The labeled VPN-IPv6 MP_REACH_NLRI itself is encoded as specified in 221 [MPLS-BGP]. In the context of this extension, the prefix belongs to 222 the VPN-IPv6 Address Family and thus consists of an 8-byte Route 223 Distinguisher followed by an IPv6 prefix as specified in section 2 224 above. 226 3.2.1 BGP Next Hop encoding 228 MP-BGP has the constraint that the "BGP Next Hop" field in the 229 MP_REACH_NLRI attribute needs to be of the same address family as the 230 NLRI encoded in the MP_REACH_NLRI attribute. In this document, this 231 means that the BGP Next Hop field must belong to the VPN-IPv6 Address 232 Family. 234 3.2.1.1 IPv6 backbone 236 When an IPv6 VPN service is offered as per this document over an IPv6 237 backbone, the BGP Next Hop MUST contain a VPN-IPV6 address: 239 - whose RD is set to zero, and 241 - whose 16-byte IPv6 address is set to the IPv6 address of the 242 advertising PE. This IPv6 address must be routable in the Service 243 Provider's backbone. 245 This is the same approach as used in [2547bis] where the PE encodes 246 its IPv4 address in a VPN-IPv4 Address Family format. 248 3.2.1.2 IPv4 backbone 250 When an IPv6 VPN service is offered as per this document over an IPv4 251 backbone, the BGP Next Hop MUST contain a VPN-IPV6 address: 253 - whose RD is set to zero, and 255 - whose 16-byte IPv6 address is encoded as an IPv4-mapped IPv6 256 address [V6ADDR] containing the IPv4 address of the advertising 257 PE. This IPv4 address must be routable in the Service Provider's 258 backbone. 260 3.3. Route Target 262 The use of route target is specified in [2547bis] and applies to IPv6 263 VPNs. Encoding of the extended community attribute is defined in 264 [BGP-EXTCOM]. 266 3.4 BGP Capability Negotiation 268 In order for two PEs to exchange labelled IPv6 VPN NLRIs, they must 269 use BGP Capabilities Negotiation to ensure that they both are capable 270 of properly processing such NLRI. This is done as specified in 271 [BGP-MP] and [BGP-CAP], by using capability code 1 (multiprotocol 272 BGP), with AFI and SAFI fields according to above. 274 4. Automatic Determination of Tunnel Type 276 As mentioned earlier, this document allows support of IPv6 VPN 277 service using various tunneling techniques in the core. 279 The tunneling type to use in the core for IPv6 VPN may be determined 280 via configuration of PEs. 282 There is work underway [TUNNEL-ATTR] on a new BGP attribute (Tunnel 283 Type) and associated procedures so that BGP speakers can 284 automatically determine which tunneling type to use for a given 285 Prefix and a given BGP next hop. 287 This document defines MPLS as the default tunneling type. This means 288 that when no Tunnel Type attribute is included in a BGP advertisement 289 for a labeled VPN-IPv6 Prefix and when the tunnel type to be used is 290 not specified by the PE configuration, MPLS LSPs MUST be used to 291 tunnel IPv6 VPN packets to the BGP Next Hop over the Service Provider 292 backbone. 294 Where another tunneling technique than MPLS is desired for tunneling 295 traffic to an IPv6 VPN prefix between PEs, the Tunnel Type attribute 296 MAY be used in BGP advertisement of a labeled VPN-IPv6 Prefix, as 297 specified in [TUNNEL-ATTR]. 299 5. Encapsulation 301 The ingress PE Router MUST tunnel IPv6 VPN data over the backbone 302 towards the Egress PE router identified as the BGP Next Hop for the 303 corresponding IPv6 VPN prefix. 305 When the 16-byte IPv6 address contained in the BGP Next Hop field is 306 encoded as an IPv4-mapped IPv6 address (see section 3.2.1.2), the 307 ingress PE will use IPv4 tunnelling. 309 When the 16-byte IPv6 address contained in the BGP Next Hop field is 310 not encoded as an IPv4-mapped address (see section 3.2.1.2), the 311 ingress PE will use IPv6 tunnelling. 313 Regardless of whether it is IPv4 or IPv6 tunnelling, the tunnelling 314 type is determined as discussed above in section 4. 316 When a PE receives a packet from a CE, it looks up the packet's IPv6 317 destination address in the VRF corresponding to that CE. This enables 318 it to find a VPN-IPv6 route. The VPN-IPv6 route will have an 319 associated MPLS label and an associated BGP Next Hop. First, this 320 MPLS label is pushed on the packet. Then, this labelled packet is 321 encapsulated into the tunnel for transport to the egress PE. Details 322 of this encapsulation depend on the actual tunnelling technique as 323 follows: 325 As with MPLS/BGP for IPv4 VPNs [2547-GRE/IP], when tunnelling is done 326 using IP-in-IP IPv4 tunnels or IP-in-IP IPv6 tunnels (resp. IPv4 GRE 327 tunnels or IPv6 GRE tunnels), encapsulation of the labelled IPv6 VPN 328 packet results in an MPLS-in-IP (resp. MPLS-in-GRE) encapsulated 329 packet as specified in [MPLS-in-IP] (resp. [MPLS-in-GRE]). 331 As with MPLS/BGP for IPv4 VPNs [2547-IPsec], when tunnelling is done 332 using an IPsec secured tunnel, encapsulation of the labelled IP6 VPN 333 packet results in an MPLS-in-IP or MPLS-in-GRE encapsulated packet 334 [MPLS-in-IP], [MPLS-in-GRE]. The IPsec Transport Mode is used to 335 secure this IPv4 or GRE tunnel from ingress PE to egress PE. 337 When tunnelling is done using IP-in-IP IPv4 tunnels or IPv4 GRE 338 tunnels (whether IPsec secured or not), the Ingress PE Router MUST 339 use the IPv4 address which is encoded in the IPv4-mapped IPv6 address 340 field of the BGP next hop field, as the destination address of the 341 prepended IPv4 tunnelling header. It uses one of its IPv4 addresses 342 as the source address of the prepended IPv4 tunneling header. 344 When tunnelling is done using IP-in-IP IPv6 tunnels or IPv6 GRE 345 tunnels tunnels (whether IPsec secured or not), the Ingress PE Router 346 MUST simply use the IPv6 address which is contained in the IPv6 347 address field of the BGP next hop field, as the destination address 348 of the prepended IPv6 tunnelling header. It uses one of its IPv6 349 addresses as the source address of the prepended IPv6 tunneling 350 header. 352 When tunneling is done using MPLS LSPs, the LSPs can be established 353 using any label distribution technique (LDP[LDP], RSVP-TE [RSVP-TE], 354 ...). Nevertheless, to ensure interoperability among systems that 355 implement this VPN architecture using MPLS LSPs as the tunneling 356 technology, all such systems must support LDP [LDP]. 358 When tunnelling is done using MPLS LSPs, the ingress PE Router 359 directly pushes the LSP tunnel label on the label stack of the 360 labelled IPv6 VPN packet (i.e. without prepending any IPv4 or IPv6 361 header). The topmost label imposed corresponds to the LSP starting on 362 the ingress PE Router and ending on the egress PE Router. The BGP 363 Next Hop field is used to identify the egress PE router and as such 364 the topmost label to be pushed on the stack. The bottom label is the 365 label bound to the IPv6 VPN Prefix via BGP. 367 6. Address Scope 369 The IPv6 address architecture [ADDRARCH] defines the concept of scope 370 for IPv6 addresses and defines the following unicast address scopes: 372 - link-local, 374 - site-local, 376 - global 378 Since Link-local scope addresses are defined as uniquely identifying 379 interfaces within (i.e., attached to) a single link only, those may 380 be used on the PE-CE link but they are not supported for reachability 381 across IPv6 VPN Sites and are never advertised via MP-BGP to remote 382 PEs. 384 Global scope addresses are defined as uniquely identifying interfaces 385 anywhere in the Internet. Global addresses are expected to be 386 commonly used within and across IPv6 VPN Sites. They are obviously 387 supported by this IPv6 VPN solution for reachability across IPv6 VPN 388 Sites and advertised via MP-BGP to remote PEs and processed without 389 any specific considerations to their Global scope. 391 Site-local scope addresses are defined as uniquely identifying 392 interfaces within a single site only. Quoting from [SCOPE-ARCH], ''a 393 "site" is, by intent, not rigorously defined,...''. However, it is 394 anticipated by the authors of this document that, when used in an 395 IPv6 VPN network, the concept of Site Local scope will typically be 396 used in either of the following scenarios: 398 - all IPv6 VPN sites of a given VPN are within the same Site-Local 399 zone. Thus, Site-Local addresses may be used for reachability 400 across all IPv6 VPN sites and corresponding Site-Local routes may 401 be advertised via MP-BGP to remote PEs and installed in VRFs. In 402 this scenario, Site Local routes MUST effectively be treated by 403 the PE in exactly the same way as Global routes. 405 - Each IPv6 VPN site of a given VPN is in a different Site-Local 406 zone. Site-Local addresses can not be used for reachability across 407 IPv6 VPN sites and corresponding Site-Local routes should not be 408 advertised via MP-BGP to remote PEs. This IPv6 VPN solution 409 proposes that this scenario be supported simply by effectively 410 hiding the Site Local routes to the PE. This can be seen as 411 placing the Site-Local zone boundary on the CE (as opposed to on 412 the PE) and thus locating the PE outside the Site-Local zone. 413 Then, when dynamic IPv6 routing is used between the PE and CE (v6 414 IGP, MP-BGP), the CE will not distribute Site-Local routes to the 415 PE. Thus, no special handling of Site Local routes is required on 416 the PE since there are none. 418 The following is an example of the first scenario: 420 I VPN I VPN I Site-Local I Site-Local addresses within I 421 I I Site I Zone I I 422 ================================================================= 423 I Yellow I 1 I 1 I FEC0::CAFE1/64 I 424 I Yellow I 2 I 1 I FEC0::CAFE2/64 I 425 I Yellow I 3 I 1 I FEC0::CAFE3/64 I 427 The following is an example of the second scenario: 429 I VPN I VPN I Site-Local I Site-Local addresses within I 430 I I Site I Zone I I 431 ================================================================= 432 I Green I 1 I 1 I FEC0::BEEF1/64 I 433 I Green I 2 I 2 I FEC0::BEEF2/64 I 434 I Green I 3 I 3 I FEC0::BEEF3/64 I 436 Note that these two scenarios can be supported by the IPv6 VPN 437 solution without any additional PE mechanism specific to the concept 438 of Site-Local scope, since in the first scenario Site-Local routes 439 are treated by the PEs in exactly the same way as Global routes, and 440 in the second scenario Site Local routes are hidden to the PEs. 442 Additional scenarios for the use of Site-Local scope in the context 443 of IPv6 VPNs are conceivable. For example, a scenario could involve a 444 given VPN which comprises a first set of VPN Sites which are within 445 the same Site-Local zone and a second set of VPN Sites which are 446 within another Site-Local zone. In that case, Site-Local addresses 447 may be used to support reachability across VPN sites of the same 448 Site-Local zone, but not across VPN Sites of different Site-Local 449 zones. Such scenarios would require that Global routes be advertised 450 and installed in the VRFs of all the VPN sites but that Site-Local 451 routes only be installed in the VRFs of a subset of the VPN sites. 452 Thus, such scenarios may require additional PE mechanisms specific to 453 the concept of Site Local scope (such as perhaps automatically using 454 a different Route Targets for Site Local routes and Global routes). 455 Because it is unclear at this point in time that there is a practical 456 requirement for handling such scenarios, support for these scenarios, 457 and corresponding mechanisms, are left for further study. 459 7. Multicast 461 Multicast operations is outside the scope of this document. 463 8. Inter-Provider Backbones 465 The same mechanisms described in [2547bis] can be used and have the 466 same scalability properties. 468 9. Accessing the Internet from a VPN 470 The methods proposed by [2547bis] to access the global Internet can 471 be used in the context of IPv6 VPNs and the global IPv6 Internet. 472 Note however that if the IPv6 packets destined for the global IPv6 473 Internet need to traverse the SP's backbone, and if this is an IPv4 474 only backbone, they must be tunnelled through that IPv4 backbone. 476 10. Management VPN 477 Where the IPv6 VPN service is supported over an IPv4 backbone, and 478 where the Service Provider manages the CE, the Service Provider may 479 elect to use IPv4 for communication between the management tool and 480 the CE for such management purposes. In that case, regardless of 481 whether a customer IPv4 site is actually connected to the CE or not, 482 the CE is effectively part of an IPv4 VPN (i.e. it is attached to an 483 IPv4 VRF) in addition to belonging to an IPv6 VPN. Considerations 484 presented in [2547bis] on how to ensure that the management tool can 485 communicate with such managed CEs from multiple VPNs without allowing 486 undesired reachability across CEs of different VPNs, are applicable 487 to the IPv4 VRF to which the CE attaches. 489 Where the IPv6 VPN service is supported over an IPv4 backbone, and 490 where the Service Provider manages the CE, the Service Provider may 491 elect to use IPv6 for communication between the management tool and 492 the CE for such management purposes. Considerations presented in 493 [2547bis] on how to ensure that the management tool can communicate 494 with such managed CEs from multiple VPNs without allowing undesired 495 reachability across CEs of different VPNs, are then applicable to the 496 IPv6 VRF to which the CE attaches. 498 11. Security 500 The same security concerns as in [2547bis] are applicable. 502 12. Quality of Service 504 [2547bis] is applicable. 506 13. Acknowledgements 508 In Memoriam: 510 The authors would like to acknowledge the valuable contribution to 511 this document from Tri T. Nguyen, who passed away in April 2002 after 512 a sudden illness. 514 14. References 516 [2547bis] Rosen et al., "BGP/MPLS VPNs", draft-ietf-ppvpn- 517 rfc2547bis-03.txt, October 2002, work in progress 519 [2547-GRE/IP] Rekhter and Rosen, "Use of PE-PE GRE or IP in RFC2547 520 VPNs", draft-ietf-ppvpn-gre-ip-2547-01.txt, February 2002, work in 521 progress 523 [2547-IPsec] Rosen, De Clercq, Paridaens, T'Joens, Sargor, "Use of 524 PE-PE IPsec in RFC2547 VPNs", draft-ietf-ppvpn-ipsec-2547-01.txt, 525 August 2002, work in progress 527 [BGP-EXTCOMM] Ramachandra, Tappan, Rekhter, "BGP Extended Communities 528 Attribute", draft-ietf-idr-bgp-ext-communities-05.txt, work in 529 progress 531 [BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol Extensions 532 for BGP4", June 2000, RFC2858 534 [BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with 535 BGP-4", draft-ietf-idr-rfc2842bis-02.txt, April 2002, work in 536 progress 538 [IPv6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 539 (IPv6) Specification", RFC2460. 541 [MPLS-ARCH] Rosen, Viswanathan, and Callon, "Multiprotocol Label 542 Switching Architecture", RFC3031 544 [MPLS-BGP] Rekhter and Rosen, "Carrying Label Information in BGP4", 545 RFC3107 547 [MPLS-ENCAPS] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and 548 Conta, "MPLS Label Stack Encoding", RFC3032 550 [MPLS-LDP] Andersson, Doolan, Feldman, Fredette, Thomas, "LDP 551 Specification", RFC3036 553 [TRANS] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6 554 Hosts and Routers", RFC2893. 556 [V6ADDR] Deering, S., and Hinden, R., "IP Version 6 Addressing 557 Architecture", draft-ietf-ipngwg-addr-arch-v3-10.txt, work in 558 progress 560 [SCOPE-ARCH] Deering, S., et al., "IPv6 Scoped Address Architecture", 561 draft-ietf-ipngwg-scoping-arch-04.txt, work in progress 563 [TUNNEL-ATTR] Cristallo, G., De Clercq, J., "BGP Tunnel Attribute", 564 draft-cristallo-bgp-tunnel-attr-00.txt, June 2002, work in progress 566 [LDP] Andersson, L., et al., "LDP Specification", January 2001, 567 RFC3036 569 [RSVP-TE] Awduche, D., et al., "RSVP-TE: Extensions to RSVP for LSP 570 Tunnels", December 2001, RFC3209 572 [MPLS-in-IP] Doolan, P., et al., "MPLS Label Stack Encapsulation in 573 IP", draft-worster-mpls-in-ip-03.txt, work in progress 575 [MPLS-in-GRE] Rekhter, Y., Tappan, D., Rosen, E., "MPLS Label Stack 576 Encapsulation in GRE", draft-rekhter-mpls-over-gre-01.txt, work in 577 progress 579 11. Authors' Addresses 581 Jeremy De Clercq 582 Alcatel 583 Fr. Wellesplein 1, 2018 Antwerpen, Belgium 584 E-mail: jeremy.de_clercq@alcatel.be 586 Gerard Gastaud 587 Alcatel 588 10 rue Latecoere, BP 57, 78141 Velizy Cedex, France 589 E-mail: gerard.gastaud@alcatel.fr 591 Dirk Ooms 592 Alcatel 593 Fr. Wellesplein 1, 2018 Antwerpen, Belgium 594 E-mail: dirk.ooms@alcatel.be 596 Marco Carugi 597 Nortel Networks S.A. 598 Parc d'activites de Magny-Les Jeunes Bois CHATEAUFORT 599 78928 YVELINES Cedex 9 - France 600 E-mail: marco.carugi@nortelnetworks.com 602 Francois Le Faucheur 603 Cisco Systems, Inc. 604 Village d'Entreprise Green Side - Batiment T3 605 400, Avenue de Roumanille 606 06410 Biot-Sophia Antipolis 607 France 608 E-mail: flefauch@cisco.com