idnits 2.17.1 draft-ietf-l3vpn-bgp-ipv6-05.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.a on line 21. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 763. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 782. ** Found boilerplate matching RFC 3979, Section 5, paragraph 3 (on line 782), which is fine, but *also* found old RFC 2026, Section 10.4B text on line 776. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 163: '...E-PE tunnel mesh MAY be used for both;...' RFC 2119 keyword, line 205: '... IPv6-capable, the same RD MAY be used...' RFC 2119 keyword, line 223: '...iBGP connections MAY be over IPv4 or o...' RFC 2119 keyword, line 234: '...routes, the advertising PE router MUST...' RFC 2119 keyword, line 244: '... NLRI. The AFI and SAFI fields MUST be...' (14 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 == Line 124 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 (February 2005) is 6981 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 225, but not defined == Missing Reference: 'BGP-EXTCOM' is mentioned on line 349, but not defined == Missing Reference: 'LDP' is mentioned on line 421, but not defined == Missing Reference: 'MP-BGP-v6' is mentioned on line 527, but not defined == Missing Reference: 'LABEL' is mentioned on line 527, but not defined == Unused Reference: 'BGP-EXTCOMM' is defined on line 670, but no explicit reference was found in the text == Unused Reference: 'MPLS-ARCH' is defined on line 679, but no explicit reference was found in the text == Unused Reference: 'MPLS-ENCAPS' is defined on line 685, but no explicit reference was found in the text == Unused Reference: 'MPLS-LDP' is defined on line 691, but no explicit reference was found in the text == Unused Reference: 'TRANS' is defined on line 712, but no explicit reference was found in the text == Unused Reference: 'SCOPE-ARCH' is defined on line 715, 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: 15 errors (**), 0 flaws (~~), 16 warnings (==), 8 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 February 2005 12 Expires August, 2005 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 is aware have been 20 or will be disclosed, and any of which he becomes aware will be 21 disclosed, in accordance with RFC 3668. 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 .................... 7 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. This 118 document only concerns itself with handling of the IPv6 packets. 120 As such the inter-working between an IPv4 site and an IPv6 site is 121 outside the scope of this document. 123 In a similar manner to how IPv4 VPN routes are distributed in 124 [2547bis], BGP and its extensions are used to distribute routes from 125 an IPv6 VPN site to all the other PE routers connected to a site of 126 the same IPv6 VPN. PEs use "VPN Routing and Forwarding tables" (VRFs) 127 to separately maintain the reachability information and forwarding 128 information of each IPv6 VPN. 130 As it is done for IPv4 VPNs [2547bis], we allow each IPv6 VPN to have 131 its own IPv6 address space, which means that a given address may 132 denote different systems in different VPNs. This is achieved via a 133 new address family, the VPN-IPv6 Address Family, in a fashion similar 134 to the VPN-IPv4 address family defined in [2547bis] and which 135 prepends a Route Distinguisher to the IP address. 137 In addition to its operation over MPLS Label Switched Paths (LSPs), 138 the IPv4 BGP/MPLS VPN solution has been extended to allow operation 139 over other tunneling techniques including GRE tunnels, IP-in-IP 140 tunnels [2547-GRE/IP], L2TPv3 tunnels [MPLS-in-L2TPv3] and IPsec- 141 protected tunnels [2547-IPsec]. In a similar manner, this document 142 allows support of an IPv6 VPN service over MPLS LSPs as well as over 143 other tunneling techniques including GRE tunnels, IP-in-IP tunnels, 144 L2TPv3 tunnels and IPsec-protected tunnels. 146 This document allows support for an IPv6 VPN service over an IPv4 147 backbone as well as over an IPv6 backbone. The IPv6 VPN service 148 supported is identical in both cases. 150 The IPv6 VPN solution defined in this document offers the following 151 benefits: 153 o from both the Service Provider perspective and the customer 154 perspective, the VPN service that can be supported for IPv6 sites 155 is identical to the one that can be supported for IPv4 sites; 157 o from the Service Provider perspective, operations of the IPv6 158 VPN service require the exact same skills, procedures and 159 mechanisms as for the IPv4 VPN service; 161 o where both IPv4 VPNs and IPv6 VPN services are supported over an 162 IPv4 core, the same single set of MP-BGP peering relationships and 163 the same single PE-PE tunnel mesh MAY be used for both; 165 o the IPv6 VPN service is independent of whether the core runs 166 IPv4 or IPv6. So that the IPv6 VPN service supported before, and 167 after a migration of the core from IPv4 to IPv6 is 168 undistinguishable to the VPN customer. 170 2. The VPN-IPv6 Address Family 172 The BGP Multiprotocol Extensions [BGP-MP] allow BGP to carry routes 173 from multiple "address families". We introduce the notion of the 174 "VPN-IPv6 address family", that is similar to the VPN-IPv4 address 175 family introduced in [2547bis]. 177 A VPN-IPv6 address is a 24-byte quantity, beginning with an 8-byte 178 "Route Distinguisher" (RD) and ending with a 16-byte IPv6 address. 179 If two VPNs use the same IPv6 address prefix (effectively denoting 180 different physical systems), the PEs translate these into unique 181 VPN-IPv6 address prefixes using different RDs. This ensures that if 182 the same address is used in two different VPNs, it is possible to 183 install two completely different routes to that address, one for each 184 VPN. 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]. As it is possible per [2547bis], the RD 189 can also be used to create multiple different routes to the very same 190 system. This can be achieved by creating two different VPN-IPv6 191 routes that have the same IPv6 part, but different RDs. This allows 192 BGP to install multiple different routes to the same system, and 193 allows policy to be used to decide which packets use which route. 195 Note that VPN-IPv6 addresses and IPv6 addresses are always considered 196 by BGP to be incomparable. 198 A VRF may have multiple equal-cost VPN-IPv6 routes for a single IPv6 199 address prefix. When a packet's destination address is matched in a 200 VRF against a VPN-IPv6 route, only the IPv6 part is actually matched. 202 The Route Distinguisher format and encoding is as specified in 203 [2547bis]. 205 When a site is IPv4-capable and IPv6-capable, the same RD MAY be used 206 for the advertisement of IPv6 addresses and IPv4 addresses. 207 Alternatively, a different RD may be used for the advertisement of 208 the IPv4 addresses and of the IPv6 addresses. Note however that in 209 the scope of this specification, IPv4 addresses and IPv6 addresses 210 will always be handled in separate contexts and no IPv4-IPv6 inter- 211 working issues and techniques will be discussed. 213 3. VPN-IPv6 route distribution 215 3.1. Route Distribution Among PEs by BGP 217 As described in [2547bis], if two sites of a VPN attach to PEs which 218 are in the same Autonomous System, the PEs can distribute VPN routes 219 to each other by means of an (IPv4) iBGP connection between them. 220 Alternatively, each PE can have iBGP connections to route reflectors. 221 Similarly, for IPv6 VPN route distribution, PEs can use iBGP 222 connections between them or use iBGP connections to route reflectors. 223 For IPv6 VPN, the iBGP connections MAY be over IPv4 or over IPv6. 225 The PE routers exchange, via MP-BGP [MP-BGP], reachability 226 information for the IPv6 prefixes in the IPv6 VPNs and thereby 227 announce themselves as the BGP Next Hop. 229 The rules for encoding the reachability information and the BGP Next 230 Hop address are specified in the following sections. 232 3.2 VPN IPv6 NLRI encoding 234 When distributing IPv6 VPN routes, the advertising PE router MUST 235 assign and distribute MPLS labels with the IPv6 VPN routes. 236 Essentially, PE routers do not distribute IPv6 VPN routes, but 237 Labeled IPv6 VPN routes [MPLS-BGP]. When the advertising PE then 238 receives a packet that has this particular advertised label, the PE 239 will pop the MPLS stack, and process the packet appropriately (i.e. 240 forward it directly based on the label or perform a lookup in the 241 corresponding IPv6-VPN context). 243 The BGP Multiprotocol Extensions [BGP-MP] are used to advertise the 244 IPv6 VPN routes in the MP_REACH NLRI. The AFI and SAFI fields MUST be 245 set as follows: 247 - AFI: 2; for IPv6 249 - SAFI: 128; for MPLS labeled VPN-IPv6 251 The NLRI field itself is encoded as specified in [MPLS-BGP]. In the 252 context of this extension, the prefix belongs to the VPN-IPv6 Address 253 Family and thus consists of an 8-byte Route Distinguisher followed by 254 an IPv6 prefix as specified in section 2 above. 256 3.2.1 BGP Next Hop encoding 258 The encoding of the BGP Next Hop depends on whether the policy of the 259 BGP speaker is to request that IPv6 VPN traffic be transported to 260 that BGP Next Hop using IPv6 tunneling (''BGP speaker requesting IPv6 261 transport'') or using IPv4 tunneling (''BGP speaker requesting IPv4 262 transport''). 264 Definition of this policy (to request transport over IPv4 tunneling 265 or IPv6 tunneling) is the responsibility of the network operator and 266 is beyond the scope of this document. We note that it is possible for 267 that policy to request transport over IPv4 (resp. IPv6) tunneling 268 while the BGP speakers exchange IPv6 VPN reachability information 269 over IPv6 (resp. IPv4). However, in that case, a number of 270 operational implications are worth considering. In particular, an 271 undetected fault affecting the IPv4 (resp. IPv6) tunneling data path 272 and not affecting the IPv6 (resp. IPv4) data path, could remain 273 undetected by BGP, which in turn may result in back-holing of 274 traffic. 276 Control of this policy is beyond the scope of this document and may 277 be based on user configuration. 279 3.2.1.1 BGP speaker requesting IPv6 transport 281 When the IPv6 VPN traffic is to be transported to the BGP speaker 282 using IPv6 tunneling (e.g. IPv6 MPLS LSPs, IPsec-protected IPv6 283 tunnels), the BGP speaker SHALL advertise a Next Hop Network Address 284 field containing a VPN-IPv6 address: 286 - whose 8-byte RD is set to zero, and 288 - whose 16-byte IPv6 address is set to the global IPv6 address of 289 the advertising BGP speaker. 291 potentially followed by another VPN-IPv6 address: 293 - whose 8-byte RD is set to zero, and 295 - whose 16-byte IPv6 address is set to the link-local IPv6 address 296 of the advertising BGP speaker. 298 The value of the Length of the Next Hop Network Address field in the 299 MP_REACH_NLRI attribute shall be set to 24 when only a global address 300 is present, and to 48 if a link-local address is also included in the 301 Next Hop field. 303 In the particular case where the BGP speakers peer using only their 304 link-local IPv6 address (for example in the case where an IPv6 CE 305 peers with an IPv6 PE and the CE does not have any IPv6 global 306 address and eBGP peering is achieved over the link-local addresses), 307 the ''unspecified address'' ([V6ADDR]) is used by the advertising BGP 308 speaker to indicate the absence of the global IPv6 address in the 309 Next Hop Network Address field. 311 The link-local address shall be included in the Next Hop field if and 312 only if the advertising BGP speaker shares a common subnet with the 313 peer the route is being advertised to [RFC2545]. 315 In all other cases, a BGP speaker shall advertise to its peer in the 316 Next Hop Network Address field only the global IPv6 address of the 317 next hop. 319 As a consequence, a BGP speaker that advertises a route to an 320 internal peer may modify the Network Address of Next Hop field by 321 removing the link-local IPv6 address of the next hop. 323 An example scenario where both the global IPv6 address and the link- 324 local IPv6 address shall be included in the BGP Next Hop address 325 field is where the IPv6 VPN service is supported over a multi-AS 326 backbone with redistribution of labeled VPN-IPv6 routes between ASBRs 327 (of different AS) sharing a common IPv6 subnet: in that case, both 328 the global IPv6 address and the link-local IPv6 address shall be 329 advertised by the ASBRs. 331 3.2.1.2 BGP Speaker requesting IPv4 transport 333 When the IPv6 VPN traffic is to be transported to the BGP speaker 334 using IPv4 tunneling (e.g. IPv4 MPLS LSPs, IPsec-protected IPv4 335 tunnels), the BGP speaker SHALL advertise to its peer a Next Hop 336 Network Address field containing a VPN-IPv6 address: 338 - whose 8-byte RD is set to zero, and 340 - whose 16-byte IPv6 address is encoded as an IPv4-mapped IPv6 341 address [V6ADDR] containing the IPv4 address of the advertising 342 BGP speaker. This IPv4 address must be routable by the other BGP 343 Speaker. 345 3.3. Route Target 347 The use of route target is specified in [2547bis] and applies to IPv6 348 VPNs. Encoding of the extended community attribute is defined in 349 [BGP-EXTCOM]. 351 3.4 BGP Capability Negotiation 353 In order for two PEs to exchange labeled IPv6 VPN NLRIs, they MUST 354 use BGP Capabilities Negotiation to ensure that they both are capable 355 of properly processing such NLRIs. This is done as specified in 356 [BGP-MP] and [BGP-CAP], by using capability code 1 (multiprotocol 357 BGP), with AFI and SAFI values as specified above in section 3.2. 359 4. Encapsulation 361 The ingress PE Router MUST tunnel IPv6 VPN data over the backbone 362 towards the Egress PE router identified as the BGP Next Hop for the 363 corresponding destination IPv6 VPN prefix. 365 When the 16-byte IPv6 address contained in the BGP Next Hop field is 366 encoded as an IPv4-mapped IPv6 address (see section 3.2.1.2), the 367 ingress PE MUST use IPv4 tunneling unless explicitly configured to do 368 otherwise. The ingress PE might optionally allow, through explicit 369 configuration, the use of IPv6 tunneling when the 16-byte IPv6 370 address contained in the BGP Next Hop field is encoded as an IPv4- 371 mapped IPv6 address. This would allow support of particular 372 deployment environments where IPv6 tunneling is desired but where 373 IPv4-mapped IPv6 addresses happen to be used for IPv6 reachability of 374 the PEs instead of Global IPv6 addresses. 376 When the 16-byte IPv6 address contained in the BGP Next Hop field is 377 not encoded as an IPv4-mapped address (see section 3.2.1.1), the 378 ingress PE MUST use IPv6 tunneling. 380 When a PE receives a packet from an attached CE, it looks up the 381 packet's IPv6 destination address in the VRF corresponding to that 382 CE. This enables it to find a VPN-IPv6 route. The VPN-IPv6 route will 383 have an associated MPLS label and an associated BGP Next Hop. First, 384 this MPLS label is pushed on the packet as the bottom label. Then, 385 this labeled packet is encapsulated into the tunnel for transport to 386 the egress PE identified by the BGP Next Hop. Details of this 387 encapsulation depend on the actual tunneling technique as follows: 389 As with MPLS/BGP for IPv4 VPNs [2547-GRE/IP], when tunneling is done 390 using IPv4 tunnels or IPv6 tunnels (resp. IPv4 GRE tunnels or IPv6 391 GRE tunnels), encapsulation of the labeled IPv6 VPN packet results in 392 an MPLS-in-IP (resp. MPLS-in-GRE) encapsulated packet as specified in 393 [MPLS-in-IP/GRE]. When tunneling is done using L2TPv3, encapsulation 394 of the labeled IPv6 VPN packet results in an MPLS-in-L2TPv3 395 encapsulated packet as specified in [MPLS-in-L2TPv3]. 397 As with MPLS/BGP for IPv4 VPNs, when tunneling is done using an IPsec 398 secured tunnel [2547-IPsec], encapsulation of the labeled IPv6 VPN 399 packet results in an MPLS-in-IP or MPLS-in-GRE encapsulated packet 400 [MPLS-in-IP/GRE]. The IPsec Transport Mode is used to secure this 401 IPv4 or GRE tunnel from ingress PE to egress PE. 403 When tunneling is done using IPv4 tunnels (whether IPsec secured or 404 not), the Ingress PE Router MUST use the IPv4 address which is 405 encoded in the IPv4-mapped IPv6 address field of the BGP next hop 406 field, as the destination address of the prepended IPv4 tunneling 407 header. It uses one of its IPv4 addresses as the source address of 408 the prepended IPv4 tunneling header. 410 When tunneling is done using IPv6 tunnels (whether IPsec secured or 411 not), the Ingress PE Router MUST use the IPv6 address which is 412 contained in the IPv6 address field of the BGP next hop field, as the 413 destination address of the prepended IPv6 tunneling header. It uses 414 one of its IPv6 addresses as the source address of the prepended IPv6 415 tunneling header. 417 When tunneling is done using MPLS LSPs, the LSPs can be established 418 using any label distribution technique (LDP[LDP], RSVP-TE [RSVP-TE], 419 ...). Nevertheless, to ensure interoperability among systems that 420 implement this VPN architecture using MPLS LSPs as the tunneling 421 technology, all such systems MUST support LDP [LDP]. 423 When tunneling is done using MPLS LSPs, the ingress PE Router MUST 424 directly push the LSP tunnel label on the label stack of the labeled 425 IPv6 VPN packet (i.e. without prepending any IPv4 or IPv6 header). 426 This pushed label corresponds to the LSP starting on the ingress PE 427 Router and ending on the egress PE Router. The BGP Next Hop field is 428 used to identify the egress PE router and in turn the label to be 429 pushed on the stack. In case the IPv6 address in the BGP Next Hop 430 field is a IPv4-mapped IPv6 address, the embedded IPv4 address will 431 determine the tunnel label to push on the label stack. In any other 432 case, the IPv6 address in the BGP Next Hop field will determine the 433 tunnel label to push on the label stack. 435 5. Address Types 437 Since Link-local unicast addresses are defined for use on a single 438 link only, those may be used on the PE-CE link but they are not 439 supported for reachability across IPv6 VPN Sites and are never 440 advertised via MP-BGP to remote PEs. 442 Global unicast addresses are defined as uniquely identifying 443 interfaces anywhere in the IPv6 Internet. Global addresses are 444 expected to be commonly used within and across IPv6 VPN Sites. They 445 are obviously supported by this IPv6 VPN solution for reachability 446 across IPv6 VPN Sites and advertised via MP-BGP to remote PEs and 447 processed without any specific considerations to their Global scope. 449 Quoting from [UNIQUE-LOCAL]: "This document defines an IPv6 unicast 450 address format that is globally unique and is intended for local 451 communications [IPv6]. These addresses are called Unique Local IPv6 452 Unicast Addresses and are abbreviated in this document as Local IPv6 453 addresses. They are not expected to be routable on the global 454 Internet. They are routable inside of a more limited area such as a 455 site. They may also be routed between a limited set of sites." 457 [UNIQUE-LOCAL] also says in its section 10: "Local IPv6 addresses can 458 be used for inter-site Virtual Private Networks (VPN) if appropriate 459 routes are set up. Because the addresses are unique these VPNs will 460 work reliably and without the need for translation. They have the 461 additional property that they will continue to work if the individual 462 sites are renumbered or merged." 464 In accordance with this, Unique Local IPv6 Unicast Addresses are 465 supported by the IPv6 VPN solution specified in this document for 466 reachability across IPv6 VPN Sites. Hence, reachability to such 467 Unique Local IPv6 Addresses may be advertised via MP-BGP to remote 468 PEs and processed by PEs in the same way as Global Unicast addresses. 470 6. Multicast 472 Multicast operations is outside the scope of this document. 474 7. Carriers' Carriers 476 Sometimes an IPv6 VPN may actually be the network of an IPv6 ISP, 477 with its own peering and routing policies. Sometimes an IPv6 VPN may 478 be the network of an SP which is offering VPN services in turn to its 479 own customers. IPv6 VPNs like these can also obtain backbone service 480 from an other SP, the ''Carrier's Carrier'', using the Carriers' 481 Carrier method described in section 9 of [2547bis] but applied to 482 IPv6 traffic. All the considerations discussed in [2547bis] for IPv4 483 VPN Carriers' Carrier apply for IPv6 VPN with the exception that the 484 use of MPLS (including label distribution) between the PE and the CE 485 pertains to IPv6 routes instead of IPv4 routes. 487 8. Multi-AS Backbones 489 The same procedures described in section 10 of [2547bis] can be used 490 (and have the same scalability properties) to address the situation 491 where two sites of an IPv6 VPN are connected to different Autonomous 492 Systems. However some additional points should be noted when applying 493 these procedures for IPv6 VPNs; these are further described in the 494 remainder of this section. 496 Approach (a): VRF-to-VRF connections at the AS (Autonomous System) 497 border routers. 499 This approach is the equivalent for IPv6 VPNs to procedure (a) 500 described in section 10 of [2547bis]. In the case of IPv6 VPNs, IPv6 501 needs to be activated on the inter-ASBR VRF-to-VRF (sub)interfaces. 502 In this approach, the ASBRs exchange IPv6 routes (as opposed to VPN- 503 IPv6 routes) and may peer over IPv6 or over IPv4. The exchange of 504 IPv6 routes MUST be carried out as per [MP-BGP-v6]. This method does 505 not use inter-AS LSPs. 507 Finally note that with this procedure, since every AS independently 508 implements the intra-AS procedures for IPv6 VPNs described in this 509 document, the participating ASes may all internally use IPv4 510 tunneling, or the participating ASes may all internally use IPv6 511 tunneling, or alternatively some participating ASes may internally 512 use IPv4 tunneling while some participating ASes may internally use 513 IPv6 tunneling. 515 Approach (b): EBGP redistribution of labeled VPN-IPv6 routes from AS 516 to neighboring AS 518 This approach is the equivalent for IPv6 VPNs to procedure (b) 519 described in section 10 of [2547bis]. With this approach, the ASBRs 520 use EBGP to redistribute labeled VPN-IPv4 routes to ASBRs in other 521 ASes. 523 In this approach, IPv6 may or may not be activated on the inter-ASBR 524 links since the ASBRs exchanging VPN-IPv6 routes may peer over IPv4 525 or IPv6 (in which case, IPv6 obviously needs to be activated on the 526 inter-ASBR link). The exchange of labeled VPN-IPv6 routes MUST be 527 carried out as per [MP-BGP-v6] and [LABEL]. When the VPN-IPv6 traffic 528 is to be transported using IPv6 tunneling, the BGP Next Hop Field 529 SHALL contain an IPv6 address. When the VPN-IPv6 traffic is to be 530 transported using IPv4 tunneling, the BGP Next Hop Field SHALL 531 contain an IPv4 address encoded as an IPv4-mapped IPv6 address. 533 This approach requires that there be inter-AS LSPs. As such the 534 corresponding (security) considerations described for procedure (b) 535 in section 10 of [2547bis] apply equally to this approach for IPv6. 537 Finally note that with this procedure, as with procedure (a), since 538 every AS independently implements the intra-AS procedures for IPv6 539 VPNs described in this document, the participating ASes may all 540 internally use IPv4 tunneling, or the participating ASes may all 541 internally use IPv6 tunneling, or alternatively some participating 542 ASes may internally use IPv4 tunneling while some participating ASes 543 may internally use IPv6 tunneling. 545 Approach (c) : Multihop EBGP redistribution of labeled VPN-IPv6 546 routes between source and destination ASes, with EBGP redistribution 547 of labeled IPv4 or IPv6 routes from AS to neighboring AS. 549 This approach is the equivalent for exchange of VPN-IPv6 routes to 550 procedure (c) described in section 10 of [2547bis] for exchange of 551 VPN-IPv4 routes. 553 This approach requires that the participating ASes either all use 554 IPv4 tunneling or alternatively all use IPv6 tunneling. 556 In this approach, VPN-IPv6 routes are neither maintained nor 557 distributed by the ASBR routers. The ASBR routers need not be dual 558 stack. An ASBR needs to maintain labeled IPv4 (or IPv6) routes to the 559 PE routers within its AS. It uses EBGP to distribute these routes to 560 other ASes. ASBRs in any transit ASes will also have to use EBGP to 561 pass along the labeled IPv4 (or IPv6) routes. This results in the 562 creation of an IPv4 (or IPv6) label switch path from ingress PE 563 router to egress PE router. Now PE routers in different ASes can 564 establish multi-hop EBGP connections to each other over IPv4 or IPv6, 565 and can exchange labeled VPN-IPv6 routes over those EBGP connections. 566 Note that the BGP Next Hop field of these distributed VPN-IPv6 routes 567 will contain an IPv6 address when IPv6 tunneling is used or an IPv4- 568 mapped IPv6 address when IPv4 tunneling is used. 570 The considerations described for procedure (c) in section 10 of 571 [2547bis] with respect to possible use of route-reflectors, with 572 respect to possible use of a third label, and with respect to LSPs 573 spanning multiple ASes apply equally to this IPv6 VPN approach. 575 9. Accessing the Internet from a VPN 577 The methods proposed by [2547bis] to access the global IPv4 Internet 578 from an IPv4 VPN can be used in the context of IPv6 VPNs and the 579 global IPv6 Internet. Note however that if the IPv6 packets from 580 IPv6 VPN sites and destined for the global IPv6 Internet need to 581 traverse the SP backbone, and if this is an IPv4 only backbone, these 582 packets must be tunneled through that IPv4 backbone. 584 Clearly, as is the case outside the VPN context, access to the IPv6 585 Internet from an IPv6 VPN requires the use of global IPv6 addresses. 586 In particular, Unique Local IPv6 addresses can not be used for IPv6 587 Internet access. 589 10. Management VPN 591 The management considerations discussed in section 12 of [2547bis] 592 apply to the management of IPv6 VPNs. 594 Where the Service Provider manages the CE of the IPv6 VPN site, the 595 Service Provider may elect to use IPv4 for communication between the 596 management tool and the CE for such management purposes. In that 597 case, regardless of whether a customer IPv4 site is actually 598 connected to the CE or not (in addition to the IPv6 site), the CE is 599 effectively part of an IPv4 VPN in addition to belonging to an IPv6 600 VPN (i.e. the CE is attached to a VRF which supports IPv4 in addition 601 to IPv6). Considerations presented in [2547bis] on how to ensure that 602 the management tool can communicate with such managed CEs from 603 multiple VPNs without allowing undesired reachability across CEs of 604 different VPNs, are applicable to the IPv4 reachability of the VRF to 605 which the CE attaches. 607 Where the Service Provider manages the CE of the IPv6 VPN site, the 608 Service Provider may elect to use IPv6 for communication between the 609 management tool and the CE for such management purposes. 610 Considerations presented in [2547bis] on how to ensure that the 611 management tool can communicate with such managed CEs from multiple 612 VPNs without allowing undesired reachability across CEs of different 613 VPNs, are then applicable to the IPv6 reachability of the VRF to 614 which the CE attaches. 616 11. Security Considerations 618 The security considerations discussed for IPv4 VPNs in section 13 of 619 [2547bis] are equally applicable to IPv6 VPNs. 621 12. Quality of Service 623 Since all the QoS mechanisms discussed for IPv4 VPNs in section 14 of 624 [2547bis] operate in the same way for IPv4 and IPv6 (Diffserv, 625 Intserv, MPLS Traffic Engineering), the QoS considerations discussed 626 in [2547bis] are equally applicable to IPv6 VPNs (and this holds 627 whether IPv4 tunneling or IPv6 tunneling is used in the backbone.) 629 13. Scalability 631 The scalability considerations summarized for IPv4 VPNs in section 15 632 of [2547bis] are equally applicable to IPv6 VPNs. 634 14. IANA Considerations 636 This document specifies (see section 3.2) the use of the BGP AFI 637 (Address Family Identifier) value 2, along with the BGP SAFI 638 (Subsequent Address Family Identifier) value 128, to represent the 639 address family ''VPN-IPv6 Labeled Addresses'', which is defined in 640 this document. 642 The use of AFI value 2 for IP is as currently specified in the IANA 643 registry ''Address Family Identifier'', so IANA need take no action 644 with respect to it. 646 At the time of this writing, the SAFI value 128 is specified as 647 ''Private Use'' in the IANA ''Subsequent Address Family Identifier'' 648 registry. However, as discussed in section 16 of [2547bis], IANA has 649 been requested to change the SAFI value 128 from ''private use'' to 650 ''MPLS-labeled VPN address''. This document is in line with this 651 requested change and no additional IANA action, beyond this change, 652 is needed. 654 15. Acknowledgements 656 We would like to thank Gerard Gastaud and Eric Levy-Abegnoli who 657 contributed to this document. 659 In Memoriam: 661 The authors would like to acknowledge the valuable contribution to 662 this document from Tri T. Nguyen, who passed away in April 2002 after 663 a sudden illness. 665 16. Normative References 667 [2547bis] Rosen et al., "BGP/MPLS VPNs", draft-ietf-l3vpn-rfc2547bis, 668 work in progress 670 [BGP-EXTCOMM] Ramachandra, Tappan, Rekhter, "BGP Extended Communities 671 Attribute", work in progress 673 [BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol Extensions 674 for BGP4", June 2000, RFC2858 676 [IPv6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 677 (IPv6) Specification", RFC2460. 679 [MPLS-ARCH] Rosen, Viswanathan, and Callon, "Multiprotocol Label 680 Switching Architecture", RFC3031 682 [MPLS-BGP] Rekhter and Rosen, "Carrying Label Information in BGP4", 683 RFC3107 685 [MPLS-ENCAPS] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and 686 Conta, "MPLS Label Stack Encoding", RFC3032 688 [BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with 689 BGP-4", November 2002, RFC3392 691 [MPLS-LDP] Andersson, Doolan, Feldman, Fredette, Thomas, "LDP 692 Specification", RFC3036 694 [RFC2545] Marques, P., Dupont, F., "Use of BGP-4 Multiprotocol 695 Extensions for IPv6 Inter-Domain Routing", March 1999, RFC2545 697 17. Informative References 699 [V6ADDR] Deering, S., and Hinden, R., "IP Version 6 Addressing 700 Architecture", April 2003, RFC3513 702 [UNIQUE-LOCAL] R. Hinden and B. Haberman, ''Unique Local IPv6 Unicast 703 Addresses'', draft-ietf-ipv6-unique-local-addr, work in progress 705 [2547-GRE/IP] Rekhter and Rosen, "Use of PE-PE GRE or IP in RFC2547 706 VPNs", draft-ietf-l3vpn-gre-ip-2547, work in progress 708 [2547-IPsec] Rosen, De Clercq, Paridaens, T'Joens, Sargor, "Use of 709 PE-PE IPsec in RFC2547 VPNs", draft-ietf-l3vpn-ipsec-2547, work in 710 progress 712 [TRANS] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6 713 Hosts and Routers", RFC2893. 715 [SCOPE-ARCH] Deering, S., et al., "IPv6 Scoped Address Architecture", 716 draft-ietf-ipv6-scoping-arch, work in progress 718 [RSVP-TE] Awduche, D., et al., "RSVP-TE: Extensions to RSVP for LSP 719 Tunnels", December 2001, RFC3209 721 [MPLS-in-IP/GRE] Worster, T., et al., "Encapsulating MPLS in IP or 722 GRE", draft-ietf-mpls-in-ip-or-gre, work in progress 724 [MPLS-in-L2TPv3] Townsley, M., et al., "Encapsulation of MPLS over 725 Layer-2 Tunneling Protocol Version 3", draft-ietf-mpls-over-l2tpv3, 726 work in progress. 728 18. Authors' Addresses 730 Jeremy De Clercq 731 Alcatel 732 Fr. Wellesplein 1, 2018 Antwerpen, Belgium 733 E-mail: jeremy.de_clercq@alcatel.be 735 Dirk Ooms 736 OneSparrow 737 Belegstraat 13, 2018 Antwerpen, Belgium 738 E-mail: dirk@onesparrow.com 740 Marco Carugi 741 Nortel Networks S.A. 742 Parc d'activites de Magny-Les Jeunes Bois CHATEAUFORT 743 78928 YVELINES Cedex 9 - France 744 E-mail: marco.carugi@nortelnetworks.com 746 Francois Le Faucheur 747 Cisco Systems, Inc. 748 Village d'Entreprise Green Side - Batiment T3 749 400, Avenue de Roumanille 750 06410 Biot-Sophia Antipolis 751 France 752 E-mail: flefauch@cisco.com 754 Intellectual Property Statement 756 The IETF takes no position regarding the validity or scope of any 757 Intellectual Property Rights or other rights that might be claimed to 758 pertain to the implementation or use of the technology described in 759 this document or the extent to which any license under such rights 760 might or might not be available; nor does it represent that it has 761 made any independent effort to identify any such rights. Information 762 on the procedures with respect to rights in RFC documents can be 763 found in BCP 78 and BCP 79. 765 Copies of IPR disclosures made to the IETF Secretariat and any 766 assurances of licenses to be made available, or the result of an 767 attempt made to obtain a general license or permission for the use of 768 such proprietary rights by implementors or users of this 769 specification can be obtained from the IETF on-line IPR repository at 770 http://www.ietf.org/ipr. 772 The IETF invites any interested party to bring to its attention any 773 copyrights, patents or patent applications, or other proprietary 774 rights which may cover technology that may be required to practice 775 this standard. Please address the information to the IETF Executive 776 Director. 778 The IETF invites any interested party to bring to its attention any 779 copyrights, patents or patent applications, or other proprietary 780 rights that may cover technology that may be required to implement 781 this standard. Please address the information to the IETF at 782 ietf-ipr@ietf.org. 784 Full Copyright Statement 786 Copyright (C) The Internet Society (2004). This document is subject 787 to the rights, licences and restrictions contained in BCP 78 and 788 except as set forth therein, the authors retain all their rights. 790 This document and the information contained herein are provided on 791 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANISATION HE/SHE 792 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 793 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 794 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 795 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 796 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 798 Acknowledgment 800 Funding for the RFC Editor function is currently provided by the 801 Internet Society.