idnits 2.17.1 draft-ietf-l3vpn-bgp-ipv6-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 814. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 781. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 788. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 800. ** Found boilerplate matching RFC 3979, Section 5, paragraph 3 (on line 800), which is fine, but *also* found old RFC 2026, Section 10.4B text on line 794. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 166: '...E-PE tunnel mesh MAY be used for both;...' RFC 2119 keyword, line 231: '...iBGP connections MAY be over IPv4 or o...' RFC 2119 keyword, line 242: '...routes, the advertising PE router MUST...' RFC 2119 keyword, line 253: '... NLRI. The AFI and SAFI fields MUST be...' RFC 2119 keyword, line 292: '... the BGP speaker SHALL advertise a Nex...' (13 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == In addition to RFC 3979, Section 5, paragraph 3 boilerplate, a section with a similar start was also found: The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (July 2005) is 6850 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: 'BGP' is mentioned on line 96, but not defined == Missing Reference: 'MP-BGP' is mentioned on line 233, but not defined == Missing Reference: 'BGP-EXTCOM' is mentioned on line 358, but not defined == Missing Reference: 'LDP' is mentioned on line 430, but not defined == Missing Reference: 'MP-BGP-v6' is mentioned on line 535, but not defined == Missing Reference: 'LABEL' is mentioned on line 535, but not defined == Unused Reference: 'BGP-EXTCOMM' is defined on line 688, but no explicit reference was found in the text == Unused Reference: 'MPLS-ARCH' is defined on line 697, but no explicit reference was found in the text == Unused Reference: 'MPLS-ENCAPS' is defined on line 703, but no explicit reference was found in the text == Unused Reference: 'MPLS-LDP' is defined on line 709, but no explicit reference was found in the text == Unused Reference: 'TRANS' is defined on line 730, but no explicit reference was found in the text == Unused Reference: 'SCOPE-ARCH' is defined on line 733, 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) Summary: 11 errors (**), 0 flaws (~~), 15 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Jeremy De Clercq 3 Alcatel 4 Dirk Ooms 5 OneSparrow 6 Marco Carugi 7 Nortel Networks 8 Francois Le Faucheur 9 Cisco Systems 11 July 2005 12 Expires January, 2006 14 BGP-MPLS IP VPN extension for IPv6 VPN 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 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 reuses, and extends 44 where necessary, the "BGP/MPLS IP VPN" method [2547bis] for support 45 of IPv6. In BGP/MPLS IP VPN, "Multiprotocol BGP" is used for 46 distributing IPv4 VPN routes over the service provider backbone and 47 MPLS is used to forward IPv4 VPN packets over the backbone. This 48 document defines an IPv6 VPN address family and describes the 49 corresponding IPv6 VPN route distribution in "Multiprotocol BGP". 51 This document defines support of the IPv6 VPN service over both an 52 IPv4 and an IPv6 backbone, and using various tunneling techniques 53 over the core including MPLS, IP-in-IP, GRE and IPsec protected 54 tunnels. The inter-working between an IPv4 site and an IPv6 site is 55 outside the scope of this document. 57 Table of Content 59 1. Introduction ................................................. 2 60 2. The VPN-IPv6 Address Family .................................. 4 61 3. VPN-IPv6 route distribution .................................. 5 62 3.1 Route Distribution Among PEs by BGP .......................... 5 63 3.2 VPN IPv6 NLRI encoding ....................................... 5 64 3.2.1 BGP Next Hop encoding ...................................... 6 65 3.2.1.1 BGP speaker requesting IPv6 transport .................... 6 66 3.2.1.2 BGP speaker requesting IPv4 transport .................... 8 67 3.3 Route Target ................................................. 8 68 3.4 BGP Capability Negotiation ................................... 8 69 4. Encapsulation ................................................ 8 70 5. Address Types ................................................ 10 71 6. Multicast .................................................... 10 72 7. Carriers' Carrier ............................................ 10 73 8. Multi-AS Backbones ........................................... 11 74 9. Accessing the Internet from a VPN ............................ 12 75 10. Management VPN ............................................... 13 76 11. Security Considerations ...................................... 13 77 12. Quality of Service ........................................... 13 78 13. Scalability .................................................. 14 79 14. IANA Considerations .......................................... 14 80 15. Acknowledgements ............................................. 14 81 16. Normative references ......................................... 14 82 17. Informative references ....................................... 15 83 18. Authors' Addresses ........................................... 16 85 1. Introduction 87 This document describes a method by which a Service Provider may use 88 its packet switched backbone to provide Virtual Private Network 89 services for its IPv6 customers. 91 This method reuses, and extends where necessary, the "BGP/MPLS IP 92 VPN" method [2547bis] for support of IPv6. In particular, this method 93 uses the same "peer model" as [2547bis], in which the customers' edge 94 routers ("CE routers") send their IPv6 routes to the Service 95 Provider's edge routers ("PE routers"). BGP ("Border Gateway 96 Protocol", [BGP, BGP-MP]) is then used by the Service Provider to 97 exchange the routes of a particular IPv6 VPN among the PE routers 98 that are attached to that IPv6 VPN. Eventually, the PE routers 99 distribute, to the CE routers in a particular VPN, the IPv6 routes 100 from other CE routers in that VPN. As with IPv4 VPNs, a key 101 characteristic of this "peer model" is that the (IPv6) CE routers 102 within an (IPv6) VPN do not peer with each other and there is no 103 "overlay" visible to the (IPv6) VPN's routing algorithm. 105 This document adopts the definitions, acronyms and mechanisms 106 described in [2547bis]. Unless otherwise stated, the mechanisms of 107 [2547bis] apply and will not be re-described here. 109 A VPN is said to be an IPv6 VPN, when each site of this VPN is IPv6 110 capable and is natively connected over an IPv6 interface or sub 111 interface to the SP backbone via a Provider Edge device (PE). 113 A site may be both IPv4-capable and IPv6-capable. The logical 114 interface on which packets arrive at the PE may determine the IP 115 version. Alternatively the same logical interface may be used for 116 both IPv4 and IPv6 in which case a per-packet lookup at the Version 117 field of the IP packet header determines the IP version. 119 This document only concerns itself with handling of IPv6 120 communication between IPv6 hosts located on IPv6-capable sites. 121 Handling of IPv4 communication between IPv4 hosts located on IPv4- 122 capable sites is outside the scope of this document and is covered in 123 [2547bis]. Communication between an IPv4 host located in an IPv4- 124 capable site and an IPv6 host located in an IPv6-capable site is 125 outside the scope of this document. 127 In a similar manner to how IPv4 VPN routes are distributed in 128 [2547bis], BGP and its extensions are used to distribute routes from 129 an IPv6 VPN site to all the other PE routers connected to a site of 130 the same IPv6 VPN. PEs use "VPN Routing and Forwarding tables" (VRFs) 131 to separately maintain the reachability information and forwarding 132 information of each IPv6 VPN. 134 As it is done for IPv4 VPNs [2547bis], we allow each IPv6 VPN to have 135 its own IPv6 address space, which means that a given address may 136 denote different systems in different VPNs. This is achieved via a 137 new address family, the VPN-IPv6 Address Family, in a fashion similar 138 to the VPN-IPv4 address family defined in [2547bis] and which 139 prepends a Route Distinguisher to the IP address. 141 In addition to its operation over MPLS Label Switched Paths (LSPs), 142 the IPv4 BGP/MPLS VPN solution has been extended to allow operation 143 over other tunneling techniques including GRE tunnels, IP-in-IP 144 tunnels [2547-GRE/IP], L2TPv3 tunnels [MPLS-in-L2TPv3] and IPsec 145 protected tunnels [2547-IPsec]. In a similar manner, this document 146 allows support of an IPv6 VPN service over MPLS LSPs as well as over 147 other tunneling techniques. 149 This document allows support for an IPv6 VPN service over an IPv4 150 backbone as well as over an IPv6 backbone. The IPv6 VPN service 151 supported is identical in both cases. 153 The IPv6 VPN solution defined in this document offers the following 154 benefits: 156 o from both the Service Provider perspective and the customer 157 perspective, the VPN service that can be supported for IPv6 sites 158 is identical to the one that can be supported for IPv4 sites; 160 o from the Service Provider perspective, operations of the IPv6 161 VPN service require the exact same skills, procedures and 162 mechanisms as for the IPv4 VPN service; 164 o where both IPv4 VPNs and IPv6 VPN services are supported over an 165 IPv4 core, the same single set of MP-BGP peering relationships and 166 the same single PE-PE tunnel mesh MAY be used for both; 168 o the IPv6 VPN service is independent of whether the core runs 169 IPv4 or IPv6. So that the IPv6 VPN service supported before, and 170 after a migration of the core from IPv4 to IPv6 is 171 undistinguishable to the VPN customer. 173 Note that supporting IPv4 VPN services over an IPv6 core is not 174 covered by this document. 176 2. The VPN-IPv6 Address Family 178 The BGP Multiprotocol Extensions [BGP-MP] allow BGP to carry routes 179 from multiple "address families". We introduce the notion of the 180 "VPN-IPv6 address family", that is similar to the VPN-IPv4 address 181 family introduced in [2547bis]. 183 A VPN-IPv6 address is a 24-byte quantity, beginning with an 8-byte 184 "Route Distinguisher" (RD) and ending with a 16-byte IPv6 address. 186 The purpose of the RD is solely to allow one to create distinct 187 routes to a common IPv6 address prefix, similarly to the purpose of 188 the RD defined in [2547bis]. In the same way as it is possible per 189 [2547bis], the RD can be used to create multiple different routes to 190 the very same system. This can be achieved by creating two different 191 VPN-IPv6 routes that have the same IPv6 part, but different RDs. This 192 allows the provider's BGP to install multiple different routes to the 193 same system, and allows policy to be used to decide which packets use 194 which route. 196 Also, if two VPNs were to use the same IPv6 address prefix 197 (effectively denoting different physical systems), the PEs would 198 translate these into unique VPN-IPv6 address prefixes using different 199 RDs. This ensures that if the same address is ever used in two 200 different VPNs, it is possible to install two completely different 201 routes to that address, one for each VPN. 203 Since VPN-IPv6 addresses and IPv6 addresses belong to different 204 address families, BGP never treats them as comparable addresses. 206 A VRF may have multiple equal-cost VPN-IPv6 routes for a single IPv6 207 address prefix. When a packet's destination address is matched in a 208 VRF against a VPN-IPv6 route, only the IPv6 part is actually matched. 210 The Route Distinguisher format and encoding is as specified in 211 [2547bis]. 213 When a site is IPv4-capable and IPv6-capable, the same RD may be used 214 for the advertisement of IPv6 addresses and IPv4 addresses. 215 Alternatively, a different RD may be used for the advertisement of 216 the IPv4 addresses and of the IPv6 addresses. Note however that in 217 the scope of this specification, IPv4 addresses and IPv6 addresses 218 will always be handled in separate contexts and no IPv4-IPv6 219 interworking issues and techniques will be discussed. 221 3. VPN-IPv6 route distribution 223 3.1. Route Distribution Among PEs by BGP 225 As described in [2547bis], if two sites of a VPN attach to PEs which 226 are in the same Autonomous System, the PEs can distribute VPN routes 227 to each other by means of an (IPv4) iBGP connection between them. 228 Alternatively, each PE can have iBGP connections to route reflectors. 229 Similarly, for IPv6 VPN route distribution, PEs can use iBGP 230 connections between them or use iBGP connections to route reflectors. 231 For IPv6 VPN, the iBGP connections MAY be over IPv4 or over IPv6. 233 The PE routers exchange, via MP-BGP [MP-BGP], reachability 234 information for the IPv6 prefixes in the IPv6 VPNs and thereby 235 announce themselves as the BGP Next Hop. 237 The rules for encoding the reachability information and the BGP Next 238 Hop address are specified in the following sections. 240 3.2 VPN IPv6 NLRI encoding 242 When distributing IPv6 VPN routes, the advertising PE router MUST 243 assign and distribute MPLS labels with the IPv6 VPN routes. 245 Essentially, PE routers do not distribute IPv6 VPN routes, but 246 Labeled IPv6 VPN routes [MPLS-BGP]. When the advertising PE then 247 receives a packet that has this particular advertised label, the PE 248 will pop the MPLS stack, and process the packet appropriately (i.e. 249 forward it directly based on the label or perform a lookup in the 250 corresponding IPv6-VPN context). 252 The BGP Multiprotocol Extensions [BGP-MP] are used to advertise the 253 IPv6 VPN routes in the MP_REACH NLRI. The AFI and SAFI fields MUST be 254 set as follows: 256 - AFI: 2; for IPv6 258 - SAFI: 128; for MPLS labeled VPN-IPv6 260 The NLRI field itself is encoded as specified in [MPLS-BGP]. In the 261 context of this extension, the prefix belongs to the VPN-IPv6 Address 262 Family and thus consists of an 8-byte Route Distinguisher followed by 263 an IPv6 prefix as specified in section 2 above. 265 3.2.1 BGP Next Hop encoding 267 The encoding of the BGP Next Hop depends on whether the policy of the 268 BGP speaker is to request that IPv6 VPN traffic be transported to 269 that BGP Next Hop using IPv6 tunneling (''BGP speaker requesting IPv6 270 transport'') or using IPv4 tunneling (''BGP speaker requesting IPv4 271 transport''). 273 Definition of this policy (to request transport over IPv4 tunneling 274 or IPv6 tunneling) is the responsibility of the network operator and 275 is beyond the scope of this document. We note that it is possible for 276 that policy to request transport over IPv4 (resp. IPv6) tunneling 277 while the BGP speakers exchange IPv6 VPN reachability information 278 over IPv6 (resp. IPv4). However, in that case, a number of 279 operational implications are worth considering. In particular, an 280 undetected fault affecting the IPv4 (resp. IPv6) tunneling data path 281 and not affecting the IPv6 (resp. IPv4) data path, could remain 282 undetected by BGP, which in turn may result in black-holing of 283 traffic. 285 Control of this policy is beyond the scope of this document and may 286 be based on user configuration. 288 3.2.1.1 BGP speaker requesting IPv6 transport 290 When the IPv6 VPN traffic is to be transported to the BGP speaker 291 using IPv6 tunneling (e.g. IPv6 MPLS LSPs, IPsec-protected IPv6 292 tunnels), the BGP speaker SHALL advertise a Next Hop Network Address 293 field containing a VPN-IPv6 address: 295 - whose 8-byte RD is set to zero, and 297 - whose 16-byte IPv6 address is set to the global IPv6 address of 298 the advertising BGP speaker. 300 potentially followed by another VPN-IPv6 address: 302 - whose 8-byte RD is set to zero, and 304 - whose 16-byte IPv6 address is set to the link-local IPv6 address 305 of the advertising BGP speaker. 307 The value of the Length of the Next Hop Network Address field in the 308 MP_REACH_NLRI attribute shall be set to 24 when only a global address 309 is present, and to 48 if a link-local address is also included in the 310 Next Hop field. 312 In the particular case where the BGP speakers peer using only their 313 link-local IPv6 address (for example in the case where an IPv6 CE 314 peers with an IPv6 PE and the CE does not have any IPv6 global 315 address and eBGP peering is achieved over the link-local addresses), 316 the ''unspecified address'' ([V6ADDR]) is used by the advertising BGP 317 speaker to indicate the absence of the global IPv6 address in the 318 Next Hop Network Address field. 320 The link-local address shall be included in the Next Hop field if and 321 only if the advertising BGP speaker shares a common subnet with the 322 peer the route is being advertised to [RFC2545]. 324 In all other cases, a BGP speaker shall advertise to its peer in the 325 Next Hop Network Address field only the global IPv6 address of the 326 next hop. 328 As a consequence, a BGP speaker that advertises a route to an 329 internal peer may modify the Network Address of Next Hop field by 330 removing the link-local IPv6 address of the next hop. 332 An example scenario where both the global IPv6 address and the link- 333 local IPv6 address shall be included in the BGP Next Hop address 334 field is where the IPv6 VPN service is supported over a multi-AS 335 backbone with redistribution of labeled VPN-IPv6 routes between 336 Autonomous System Border Routers (ASBR) of different ASes sharing a 337 common IPv6 subnet: in that case, both the global IPv6 address and 338 the link-local IPv6 address shall be advertised by the ASBRs. 340 3.2.1.2 BGP Speaker requesting IPv4 transport 342 When the IPv6 VPN traffic is to be transported to the BGP speaker 343 using IPv4 tunneling (e.g. IPv4 MPLS LSPs, IPsec-protected IPv4 344 tunnels), the BGP speaker SHALL advertise to its peer a Next Hop 345 Network Address field containing a VPN-IPv6 address: 347 - whose 8-byte RD is set to zero, and 349 - whose 16-byte IPv6 address is encoded as an IPv4-mapped IPv6 350 address [V6ADDR] containing the IPv4 address of the advertising 351 BGP speaker. This IPv4 address must be routable by the other BGP 352 Speaker. 354 3.3. Route Target 356 The use of route target is specified in [2547bis] and applies to IPv6 357 VPNs. Encoding of the extended community attribute is defined in 358 [BGP-EXTCOM]. 360 3.4 BGP Capability Negotiation 362 In order for two PEs to exchange labeled IPv6 VPN NLRIs, they MUST 363 use BGP Capabilities Negotiation to ensure that they both are capable 364 of properly processing such NLRIs. This is done as specified in 365 [BGP-MP] and [BGP-CAP], by using capability code 1 (multiprotocol 366 BGP), with AFI and SAFI values as specified above in section 3.2. 368 4. Encapsulation 370 The ingress PE Router MUST tunnel IPv6 VPN data over the backbone 371 towards the Egress PE router identified as the BGP Next Hop for the 372 corresponding destination IPv6 VPN prefix. 374 When the 16-byte IPv6 address contained in the BGP Next Hop field is 375 encoded as an IPv4-mapped IPv6 address (see section 3.2.1.2), the 376 ingress PE MUST use IPv4 tunneling unless explicitly configured to do 377 otherwise. The ingress PE might optionally allow, through explicit 378 configuration, the use of IPv6 tunneling when the 16-byte IPv6 379 address contained in the BGP Next Hop field is encoded as an IPv4- 380 mapped IPv6 address. This would allow support of particular 381 deployment environments where IPv6 tunneling is desired but where 382 IPv4-mapped IPv6 addresses happen to be used for IPv6 reachability of 383 the PEs instead of Global IPv6 addresses. 385 When the 16-byte IPv6 address contained in the BGP Next Hop field is 386 not encoded as an IPv4-mapped address (see section 3.2.1.1), the 387 ingress PE MUST use IPv6 tunneling. 389 When a PE receives a packet from an attached CE, it looks up the 390 packet's IPv6 destination address in the VRF corresponding to that 391 CE. This enables it to find a VPN-IPv6 route. The VPN-IPv6 route will 392 have an associated MPLS label and an associated BGP Next Hop. First, 393 this MPLS label is pushed on the packet as the bottom label. Then, 394 this labeled packet is encapsulated into the tunnel for transport to 395 the egress PE identified by the BGP Next Hop. Details of this 396 encapsulation depend on the actual tunneling technique as follows: 398 As with MPLS/BGP for IPv4 VPNs [2547-GRE/IP], when tunneling is done 399 using IPv4 tunnels or IPv6 tunnels (resp. IPv4 GRE tunnels or IPv6 400 GRE tunnels), encapsulation of the labeled IPv6 VPN packet results in 401 an MPLS-in-IP (resp. MPLS-in-GRE) encapsulated packet as specified in 402 [MPLS-in-IP/GRE]. When tunneling is done using L2TPv3, encapsulation 403 of the labeled IPv6 VPN packet results in an MPLS-in-L2TPv3 404 encapsulated packet as specified in [MPLS-in-L2TPv3]. 406 As with MPLS/BGP for IPv4 VPNs, when tunneling is done using an IPsec 407 secured tunnel [2547-IPsec], encapsulation of the labeled IPv6 VPN 408 packet results in an MPLS-in-IP or MPLS-in-GRE encapsulated packet 409 [MPLS-in-IP/GRE]. The IPsec Transport Mode is used to secure this 410 IPv4 or GRE tunnel from ingress PE to egress PE. 412 When tunneling is done using IPv4 tunnels (whether IPsec secured or 413 not), the Ingress PE Router MUST use the IPv4 address which is 414 encoded in the IPv4-mapped IPv6 address field of the BGP next hop 415 field, as the destination address of the prepended IPv4 tunneling 416 header. It uses one of its IPv4 addresses as the source address of 417 the prepended IPv4 tunneling header. 419 When tunneling is done using IPv6 tunnels (whether IPsec secured or 420 not), the Ingress PE Router MUST use the IPv6 address which is 421 contained in the IPv6 address field of the BGP next hop field, as the 422 destination address of the prepended IPv6 tunneling header. It uses 423 one of its IPv6 addresses as the source address of the prepended IPv6 424 tunneling header. 426 When tunneling is done using MPLS LSPs, the LSPs can be established 427 using any label distribution technique (LDP[LDP], RSVP-TE [RSVP-TE], 428 ...). Nevertheless, to ensure interoperability among systems that 429 implement this VPN architecture using MPLS LSPs as the tunneling 430 technology, all such systems MUST support LDP [LDP]. 432 When tunneling is done using MPLS LSPs, the ingress PE Router MUST 433 directly push the LSP tunnel label on the label stack of the labeled 434 IPv6 VPN packet (i.e. without prepending any IPv4 or IPv6 header). 435 This pushed label corresponds to the LSP starting on the ingress PE 436 Router and ending on the egress PE Router. The BGP Next Hop field is 437 used to identify the egress PE router and in turn the label to be 438 pushed on the stack. When the IPv6 address in the BGP Next Hop field 439 is a IPv4-mapped IPv6 address, the embedded IPv4 address will 440 determine the tunnel label to push on the label stack. In any other 441 case, the IPv6 address in the BGP Next Hop field will determine the 442 tunnel label to push on the label stack. 444 5. Address Types 446 Since Link-local unicast addresses are defined for use on a single 447 link only, those may be used on the PE-CE link but they are not 448 supported for reachability across IPv6 VPN Sites and are never 449 advertised via MP-BGP to remote PEs. 451 Global unicast addresses are defined as uniquely identifying 452 interfaces anywhere in the IPv6 Internet. Global addresses are 453 expected to be commonly used within and across IPv6 VPN Sites. They 454 are obviously supported by this IPv6 VPN solution for reachability 455 across IPv6 VPN Sites and advertised via MP-BGP to remote PEs and 456 processed without any specific considerations to their Global scope. 458 Quoting from [UNIQUE-LOCAL]: "This document defines an IPv6 unicast 459 address format that is globally unique and is intended for local 460 communications [IPv6]. These addresses are called Unique Local IPv6 461 Unicast Addresses and are abbreviated in this document as Local IPv6 462 addresses. They are not expected to be routable on the global 463 Internet. They are routable inside of a more limited area such as a 464 site. They may also be routed between a limited set of sites." 466 [UNIQUE-LOCAL] also says in its section 10: "Local IPv6 addresses can 467 be used for inter-site Virtual Private Networks (VPN) if appropriate 468 routes are set up. Because the addresses are unique these VPNs will 469 work reliably and without the need for translation. They have the 470 additional property that they will continue to work if the individual 471 sites are renumbered or merged." 473 In accordance with this, Unique Local IPv6 Unicast Addresses are 474 supported by the IPv6 VPN solution specified in this document for 475 reachability across IPv6 VPN Sites. Hence, reachability to such 476 Unique Local IPv6 Addresses may be advertised via MP-BGP to remote 477 PEs and processed by PEs in the same way as Global Unicast addresses. 479 6. Multicast 481 Multicast operations is outside the scope of this document. 483 7. Carriers' Carriers 484 Sometimes an IPv6 VPN may actually be the network of an IPv6 ISP, 485 with its own peering and routing policies. Sometimes an IPv6 VPN may 486 be the network of an SP which is offering VPN services in turn to its 487 own customers. IPv6 VPNs like these can also obtain backbone service 488 from another SP, the ''Carrier's Carrier'', using the Carriers' 489 Carrier method described in section 9 of [2547bis] but applied to 490 IPv6 traffic. All the considerations discussed in [2547bis] for IPv4 491 VPN Carriers' Carrier apply for IPv6 VPN with the exception that the 492 use of MPLS (including label distribution) between the PE and the CE 493 pertains to IPv6 routes instead of IPv4 routes. 495 8. Multi-AS Backbones 497 The same procedures described in section 10 of [2547bis] can be used 498 (and have the same scalability properties) to address the situation 499 where two sites of an IPv6 VPN are connected to different Autonomous 500 Systems. However some additional points should be noted when applying 501 these procedures for IPv6 VPNs; these are further described in the 502 remainder of this section. 504 Approach (a): VRF-to-VRF connections at the AS (Autonomous System) 505 border routers. 507 This approach is the equivalent for IPv6 VPNs to procedure (a) 508 described in section 10 of [2547bis]. In the case of IPv6 VPNs, IPv6 509 needs to be activated on the inter-ASBR VRF-to-VRF (sub)interfaces. 510 In this approach, the ASBRs exchange IPv6 routes (as opposed to VPN- 511 IPv6 routes) and may peer over IPv6 or over IPv4. The exchange of 512 IPv6 routes MUST be carried out as per [MP-BGP-v6]. This method does 513 not use inter-AS LSPs. 515 Finally note that with this procedure, since every AS independently 516 implements the intra-AS procedures for IPv6 VPNs described in this 517 document, the participating ASes may all internally use IPv4 518 tunneling, or the participating ASes may all internally use IPv6 519 tunneling, or alternatively some participating ASes may internally 520 use IPv4 tunneling while some participating ASes may internally use 521 IPv6 tunneling. 523 Approach (b): EBGP redistribution of labeled VPN-IPv6 routes from AS 524 to neighboring AS. 526 This approach is the equivalent for IPv6 VPNs to procedure (b) 527 described in section 10 of [2547bis]. With this approach, the ASBRs 528 use EBGP to redistribute labeled VPN-IPv4 routes to ASBRs in other 529 ASes. 531 In this approach, IPv6 may or may not be activated on the inter-ASBR 532 links since the ASBRs exchanging VPN-IPv6 routes may peer over IPv4 533 or IPv6 (in which case, IPv6 obviously needs to be activated on the 534 inter-ASBR link). The exchange of labeled VPN-IPv6 routes MUST be 535 carried out as per [MP-BGP-v6] and [LABEL]. When the VPN-IPv6 traffic 536 is to be transported using IPv6 tunneling, the BGP Next Hop Field 537 SHALL contain an IPv6 address. When the VPN-IPv6 traffic is to be 538 transported using IPv4 tunneling, the BGP Next Hop Field SHALL 539 contain an IPv4 address encoded as an IPv4-mapped IPv6 address. 541 This approach requires that there be inter-AS LSPs. As such the 542 corresponding (security) considerations described for procedure (b) 543 in section 10 of [2547bis] apply equally to this approach for IPv6. 545 Finally note that with this procedure, as with procedure (a), since 546 every AS independently implements the intra-AS procedures for IPv6 547 VPNs described in this document, the participating ASes may all 548 internally use IPv4 tunneling, or the participating ASes may all 549 internally use IPv6 tunneling, or alternatively some participating 550 ASes may internally use IPv4 tunneling while some participating ASes 551 may internally use IPv6 tunneling. 553 Approach (c) : Multihop EBGP redistribution of labeled VPN-IPv6 554 routes between source and destination ASes, with EBGP redistribution 555 of labeled IPv4 or IPv6 routes from AS to neighboring AS. 557 This approach is the equivalent for exchange of VPN-IPv6 routes to 558 procedure (c) described in section 10 of [2547bis] for exchange of 559 VPN-IPv4 routes. 561 This approach requires that the participating ASes either all use 562 IPv4 tunneling or alternatively all use IPv6 tunneling. 564 In this approach, VPN-IPv6 routes are neither maintained nor 565 distributed by the ASBR routers. The ASBR routers need not be dual 566 stack. An ASBR needs to maintain labeled IPv4 (or IPv6) routes to the 567 PE routers within its AS. It uses EBGP to distribute these routes to 568 other ASes. ASBRs in any transit ASes will also have to use EBGP to 569 pass along the labeled IPv4 (or IPv6) routes. This results in the 570 creation of an IPv4 (or IPv6) label switch path from ingress PE 571 router to egress PE router. Now PE routers in different ASes can 572 establish multi-hop EBGP connections to each other over IPv4 or IPv6, 573 and can exchange labeled VPN-IPv6 routes over those EBGP connections. 574 Note that the BGP Next Hop field of these distributed VPN-IPv6 routes 575 will contain an IPv6 address when IPv6 tunneling is used or an IPv4- 576 mapped IPv6 address when IPv4 tunneling is used. 578 The considerations described for procedure (c) in section 10 of 579 [2547bis] with respect to possible use of route-reflectors, with 580 respect to possible use of a third label, and with respect to LSPs 581 spanning multiple ASes apply equally to this IPv6 VPN approach. 583 9. Accessing the Internet from a VPN 585 The methods proposed by [2547bis] to access the global IPv4 Internet 586 from an IPv4 VPN can be used in the context of IPv6 VPNs and the 587 global IPv6 Internet. Note however that if the IPv6 packets from 588 IPv6 VPN sites and destined for the global IPv6 Internet need to 589 traverse the SP backbone, and if this is an IPv4 only backbone, these 590 packets must be tunneled through that IPv4 backbone. 592 Clearly, as is the case outside the VPN context, access to the IPv6 593 Internet from an IPv6 VPN requires the use of global IPv6 addresses. 594 In particular, Unique Local IPv6 addresses can not be used for IPv6 595 Internet access. 597 10. Management VPN 599 The management considerations discussed in section 12 of [2547bis] 600 apply to the management of IPv6 VPNs. 602 Where the Service Provider manages the CE of the IPv6 VPN site, the 603 Service Provider may elect to use IPv4 for communication between the 604 management tool and the CE for such management purposes. In that 605 case, regardless of whether a customer IPv4 site is actually 606 connected to the CE or not (in addition to the IPv6 site), the CE is 607 effectively part of an IPv4 VPN in addition to belonging to an IPv6 608 VPN (i.e. the CE is attached to a VRF which supports IPv4 in addition 609 to IPv6). Considerations presented in [2547bis] on how to ensure that 610 the management tool can communicate with such managed CEs from 611 multiple VPNs without allowing undesired reachability across CEs of 612 different VPNs, are applicable to the IPv4 reachability of the VRF to 613 which the CE attaches. 615 Where the Service Provider manages the CE of the IPv6 VPN site, the 616 Service Provider may elect to use IPv6 for communication between the 617 management tool and the CE for such management purposes. 618 Considerations presented in [2547bis] on how to ensure that the 619 management tool can communicate with such managed CEs from multiple 620 VPNs without allowing undesired reachability across CEs of different 621 VPNs, are then applicable to the IPv6 reachability of the VRF to 622 which the CE attaches. 624 11. Security Considerations 626 The extensions defined in this document allow MP-BGP to propagate 627 reachability information about IPv6 VPN routes. 629 Security considerations for the transport of IPv6 reachability 630 information using BGP are discussed in RFC2545, section 5, and are 631 equally applicable for the extensions described in this document. 633 The extensions described in this document for offering IPv6 VPNs use 634 the exact same approach as the approach described in [2547bis]. As 635 such, the same security considerations with regards to Data Plane 636 security, Control Plane security and PE and P device security as 637 described in [2547bis], section 13, apply. 639 12. Quality of Service 641 Since all the QoS mechanisms discussed for IPv4 VPNs in section 14 of 642 [2547bis] operate in the same way for IPv4 and IPv6 (Diffserv, 643 Intserv, MPLS Traffic Engineering), the QoS considerations discussed 644 in [2547bis] are equally applicable to IPv6 VPNs (and this holds 645 whether IPv4 tunneling or IPv6 tunneling is used in the backbone.) 647 13. Scalability 649 Each of the scalability considerations summarized for IPv4 VPNs in 650 section 15 of [2547bis] are equally applicable to IPv6 VPNs. 652 14. IANA Considerations 654 This document specifies (see section 3.2) the use of the BGP AFI 655 (Address Family Identifier) value 2, along with the BGP SAFI 656 (Subsequent Address Family Identifier) value 128, to represent the 657 address family ''VPN-IPv6 Labeled Addresses'', which is defined in 658 this document. 660 The use of AFI value 2 for IP is as currently specified in the IANA 661 registry ''Address Family Identifier'', so IANA need take no action 662 with respect to it. 664 At the time of this writing, the SAFI value 128 is specified as 665 ''Private Use'' in the IANA ''Subsequent Address Family Identifier'' 666 registry. However, as discussed in section 16 of [2547bis], IANA has 667 been requested to change the SAFI value 128 from ''private use'' to 668 ''MPLS-labeled VPN address''. This document is in line with this 669 requested change and no additional IANA action, beyond this change, 670 is needed. 672 15. Acknowledgements 674 We would like to thank Gerard Gastaud and Eric Levy-Abegnoli who 675 contributed to this document. 677 In Memoriam: 679 The authors would like to acknowledge the valuable contribution to 680 this document from Tri T. Nguyen, who passed away in April 2002 after 681 a sudden illness. 683 16. Normative References 685 [2547bis] Rosen et al., "BGP/MPLS VPNs", draft-ietf-l3vpn-rfc2547bis, 686 work in progress 688 [BGP-EXTCOMM] Ramachandra, Tappan, Rekhter, "BGP Extended Communities 689 Attribute", work in progress 691 [BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol Extensions 692 for BGP4", June 2000, RFC2858 694 [IPv6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 695 (IPv6) Specification", RFC2460. 697 [MPLS-ARCH] Rosen, Viswanathan, and Callon, "Multiprotocol Label 698 Switching Architecture", RFC3031 700 [MPLS-BGP] Rekhter and Rosen, "Carrying Label Information in BGP4", 701 RFC3107 703 [MPLS-ENCAPS] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and 704 Conta, "MPLS Label Stack Encoding", RFC3032 706 [BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with 707 BGP-4", November 2002, RFC3392 709 [MPLS-LDP] Andersson, Doolan, Feldman, Fredette, Thomas, "LDP 710 Specification", RFC3036 712 [RFC2545] Marques, P., Dupont, F., "Use of BGP-4 Multiprotocol 713 Extensions for IPv6 Inter-Domain Routing", March 1999, RFC2545 715 17. Informative References 717 [V6ADDR] Deering, S., and Hinden, R., "IP Version 6 Addressing 718 Architecture", April 2003, RFC3513 720 [UNIQUE-LOCAL] R. Hinden and B. Haberman, ''Unique Local IPv6 Unicast 721 Addresses'', draft-ietf-ipv6-unique-local-addr, work in progress 723 [2547-GRE/IP] Rekhter and Rosen, "Use of PE-PE GRE or IP in RFC2547 724 VPNs", draft-ietf-l3vpn-gre-ip-2547, work in progress 726 [2547-IPsec] Rosen, De Clercq, Paridaens, T'Joens, Sargor, "Use of 727 PE-PE IPsec in RFC2547 VPNs", draft-ietf-l3vpn-ipsec-2547, work in 728 progress 730 [TRANS] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6 731 Hosts and Routers", RFC2893. 733 [SCOPE-ARCH] Deering, S., et al., "IPv6 Scoped Address Architecture", 734 draft-ietf-ipv6-scoping-arch, work in progress 736 [RSVP-TE] Awduche, D., et al., "RSVP-TE: Extensions to RSVP for LSP 737 Tunnels", December 2001, RFC3209 739 [MPLS-in-IP/GRE] Worster, T., et al., "Encapsulating MPLS in IP or 740 GRE", draft-ietf-mpls-in-ip-or-gre, work in progress 742 [MPLS-in-L2TPv3] Townsley, M., et al., "Encapsulation of MPLS over 743 Layer-2 Tunneling Protocol Version 3", draft-ietf-mpls-over-l2tpv3, 744 work in progress. 746 18. Authors' Addresses 748 Jeremy De Clercq 749 Alcatel 750 Fr. Wellesplein 1, 2018 Antwerpen, Belgium 751 E-mail: jeremy.de_clercq@alcatel.be 753 Dirk Ooms 754 OneSparrow 755 Belegstraat 13, 2018 Antwerpen, Belgium 756 E-mail: dirk@onesparrow.com 758 Marco Carugi 759 Nortel Networks S.A. 760 Parc d'activites de Magny-Les Jeunes Bois CHATEAUFORT 761 78928 YVELINES Cedex 9 - France 762 E-mail: marco.carugi@nortelnetworks.com 764 Francois Le Faucheur 765 Cisco Systems, Inc. 766 Village d'Entreprise Green Side - Batiment T3 767 400, Avenue de Roumanille 768 06410 Biot-Sophia Antipolis 769 France 770 E-mail: flefauch@cisco.com 772 Intellectual Property Statement 774 The IETF takes no position regarding the validity or scope of any 775 Intellectual Property Rights or other rights that might be claimed to 776 pertain to the implementation or use of the technology described in 777 this document or the extent to which any license under such rights 778 might or might not be available; nor does it represent that it has 779 made any independent effort to identify any such rights. Information 780 on the procedures with respect to rights in RFC documents can be 781 found in BCP 78 and BCP 79. 783 Copies of IPR disclosures made to the IETF Secretariat and any 784 assurances of licenses to be made available, or the result of an 785 attempt made to obtain a general license or permission for the use of 786 such proprietary rights by implementers or users of this 787 specification can be obtained from the IETF on-line IPR repository at 788 http://www.ietf.org/ipr. 790 The IETF invites any interested party to bring to its attention any 791 copyrights, patents or patent applications, or other proprietary 792 rights which may cover technology that may be required to practice 793 this standard. Please address the information to the IETF Executive 794 Director. 796 The IETF invites any interested party to bring to its attention any 797 copyrights, patents or patent applications, or other proprietary 798 rights that may cover technology that may be required to implement 799 this standard. Please address the information to the IETF at 800 ietf-ipr@ietf.org. 802 Full Copyright Statement 804 Copyright (C) The Internet Society (2005). This document is subject 805 to the rights, licenses and restrictions contained in BCP 78, and 806 except as set forth therein, the authors retain all their rights. 808 This document and the information contained herein are provided on 809 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 810 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 811 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 812 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 813 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 814 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 816 Acknowledgment 818 Funding for the RFC Editor function is currently provided by the 819 Internet Society.