idnits 2.17.1 draft-ietf-l3vpn-rfc2547bis-03.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 3667, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2157. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2130. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2137. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2143. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** 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? ** 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. ** 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, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == 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 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 785: '...s routes, the PE MUST filter out all r...' RFC 2119 keyword, line 788: '... MUST remove the RT before convertin...' RFC 2119 keyword, line 878: '...ling technology, all such systems MUST...' RFC 2119 keyword, line 880: '... Unsolicited mode MUST be supported on...' RFC 2119 keyword, line 883: '...m on Demand mode MUST be supported on ...' (3 more instances...) -- The abstract seems to indicate that this document obsoletes RFC2547, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1150 has weird spacing: '...is then sent ...' -- 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 (October 2004) is 7126 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: 'MPLS-in-IP-or-GRE' is mentioned on line 1164, but not defined == Unused Reference: 'IPSEC' is defined on line 2077, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (ref. 'BGP') (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2858 (ref. 'BGP-MP') (Obsoleted by RFC 4760) == Outdated reference: A later version (-09) exists of draft-ietf-idr-bgp-ext-communities-07 ** Obsolete normative reference: RFC 3107 (ref. 'MPLS-BGP') (Obsoleted by RFC 8277) == Outdated reference: A later version (-13) exists of draft-ietf-idr-as4bytes-08 == Outdated reference: A later version (-17) exists of draft-ietf-idr-route-filter-10 -- Obsolete informational reference (is this intentional?): RFC 2796 (ref. 'BGP-RR') (Obsoleted by RFC 4456) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. 'IANA') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. 'IPSEC') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 3036 (ref. 'MPLS-LDP') (Obsoleted by RFC 5036) -- Obsolete informational reference (is this intentional?): RFC 2385 (ref. 'TCP-MD5') (Obsoleted by RFC 5925) == Outdated reference: A later version (-15) exists of draft-rosen-vpn-mcast-07 == Outdated reference: A later version (-06) exists of draft-ietf-l3vpn-ospf-2547-01 Summary: 11 errors (**), 0 flaws (~~), 11 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Eric C. Rosen 3 Internet Draft Cisco Systems, Inc. 4 Expiration Date: April 2005 5 Yakov Rekhter 6 Juniper Networks, Inc. 8 October 2004 10 BGP/MPLS IP VPNs 12 draft-ietf-l3vpn-rfc2547bis-03.txt 14 Status of this Memo 16 By submitting this Internet-Draft, we certify that any applicable 17 patent or other IPR claims of which we are aware have been disclosed, 18 or will be disclosed, and any of which we become aware will be 19 disclosed, in accordance with RFC 3668. 21 This document is an Internet-Draft and is subject to all provisions 22 of Section 10 of RFC2026. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Abstract 42 This document describes a method by which a Service Provider may use 43 an IP backbone to provide IP VPNs (Virtual Private Networks) for its 44 customers. This method uses a "peer model", in which the customers' 45 edge routers ("CE routers") send their routes to the Service 46 Provider's edge routers ("PE routers"); there is no "overlay" visible 47 to the customer's routing algorithm, and CE routers at different 48 sites do not peer with each other. Data packets are tunneled through 49 the backbone, so that the core routers do not need to know the VPN 50 routes. 52 This document obsoletes RFC 2547. 54 Table of Contents 56 1 Introduction ....................................... 4 57 1.1 Virtual Private Networks ........................... 5 58 1.2 Customer Edge and Provider Edge .................... 6 59 1.3 VPNs with Overlapping Address Spaces ............... 8 60 1.4 VPNs with Different Routes to the Same System ...... 8 61 1.5 SP Backbone Routers ................................ 8 62 1.6 Security ........................................... 9 63 2 Sites and CEs ...................................... 9 64 3 VRFs: Multiple Forwarding Tables in PEs ............ 10 65 3.1 VRFs and Attachment Circuits ....................... 10 66 3.2 Associating IP Packets with VRFs ................... 12 67 3.3 Populating the VRFs ................................ 13 68 4 VPN Route Distribution via BGP ..................... 14 69 4.1 The VPN-IPv4 Address Family ........................ 14 70 4.2 Encoding of Route Distinguishers ................... 15 71 4.3 Controlling Route Distribution ..................... 16 72 4.3.1 The Route Target Attribute ......................... 17 73 4.3.2 Route Distribution Among PEs by BGP ................ 19 74 4.3.3 Use of Route Reflectors ............................ 21 75 4.3.4 How VPN-IPv4 NLRI is Carried in BGP ................ 24 76 4.3.5 Building VPNs using Route Targets .................. 24 77 4.3.6 Route Distribution Among VRFs in a Single PE ....... 25 78 5 Forwarding ......................................... 25 79 6 Maintaining Proper Isolation of VPNs ............... 28 80 7 How PEs Learn Routes from CEs ...................... 29 81 8 How CEs learn Routes from PEs ...................... 32 82 9 Carriers' Carriers ................................. 32 83 10 Multi-AS Backbones ................................. 34 84 11 Accessing the Internet from a VPN .................. 36 85 12 Management VPNs .................................... 38 86 13 Security Considerations ............................ 39 87 13.1 Data Plane ......................................... 39 88 13.2 Control Plane ...................................... 41 89 13.3 Security of P and PE devices ....................... 41 90 14 Quality of Service ................................. 41 91 15 Scalability ........................................ 42 92 16 IANA Considerations ................................ 42 93 17 Acknowledgments .................................... 43 94 18 Authors' Addresses ................................. 43 95 19 Contributors ....................................... 44 96 20 Normative References ............................... 46 97 21 Informational References ........................... 47 98 22 Intellectual Property Statement .................... 48 99 23 Full Copyright Statement ........................... 49 101 1. Introduction 103 This document describes a method by which a Service Provider may use 104 an IP backbone to provide IP VPNs (Virtual Private Networks) for its 105 customers. This method uses a "peer model", in which the customers' 106 edge routers ("CE routers") send their routes to the Service 107 Provider's edge routers ("PE routers"). BGP ("Border Gateway 108 Protocol", [BGP,BGP-MP]) is then used by the Service Provider to 109 exchange the routes of a particular VPN among the PE routers that are 110 attached to that VPN. This is done in a way which ensures that 111 routes from different VPNs remain distinct and separate, even if two 112 VPNs have an overlapping address space. The PE routers distribute, 113 to the CE routers in a particular VPN, the routes from other the CE 114 routers in that VPN. The CE routers do not peer with each other, 115 hence there is no "overlay" visible to the VPN's routing algorithm. 116 The term "IP" in "IP VPN" is used to indicate that the PE receives IP 117 datagrams from the CE, examines their IP headers, and routes them 118 accordingly. 120 Each route within a VPN is assigned an MPLS ("Multiprotocol Label 121 Switching", [MPLS-ARCH, MPLS-BGP, MPLS-ENCAPS]) label; when BGP 122 distributes a VPN route, it also distributes an MPLS label for that 123 route. Before a customer data packet travels across the Service 124 Provider's backbone, it is encapsulated with the MPLS label that 125 corresponds, in the customer's VPN, to the route that is the best 126 match to the packet's destination address. This MPLS packet is 127 further encapsulated (e.g., with another MPLS label, or with an IP or 128 GRE ("Generic Routing Encapsulation" tunnel header [MPLS-in-IP-GRE]) 129 so that it gets tunneled across the backbone to the proper PE router. 130 Thus the backbone core routers do not need to know the VPN routes. 132 The primary goal of this method is to support the case in which a 133 client obtains IP backbone services from a Service Provider or 134 Service Providers with which it maintains contractual relationships. 135 The client may be an enterprise, a group of enterprises which need an 136 extranet, an Internet Service Provider, an application service 137 provider, another VPN Service Provider which uses this same method to 138 offer VPNs to clients of its own, etc. The method makes it very 139 simple for the client to use the backbone services. It is also very 140 scalable and flexible for the Service Provider, and allows the 141 Service Provider to add value. 143 1.1. Virtual Private Networks 145 Consider a set of "sites" that are attached to a common network that 146 we call "the backbone". Now apply some policy to create a number of 147 subsets of that set, and impose the following rule: two sites may 148 have IP interconnectivity over that backbone only if at least one of 149 these subsets contains them both. 151 These subsets are "Virtual Private Networks" (VPNs). Two sites have 152 IP connectivity over the common backbone only if there is some VPN 153 which contains them both. Two sites which have no VPN in common have 154 no connectivity over that backbone. 156 If all the sites in a VPN are owned by the same enterprise, the VPN 157 may be thought of as a corporate "intranet". If the various sites in 158 a VPN are owned by different enterprises, the VPN may be thought of 159 as an "extranet". A site can be in more than one VPN; e.g., in an 160 intranet and in several extranets. In general, when we use the term 161 VPN we will not be distinguishing between intranets and extranets. 163 We refer to the owners of the sites as the "customers". We refer to 164 the owners/operators of the backbone as the "Service Providers" 165 (SPs). The customers obtain "VPN service" from the SPs. 167 A customer may be a single enterprise, a set of enterprises, an 168 Internet Service Provider, an Application Service Provider, another 169 SP which offers the same kind of VPN service to its own customers, 170 etc. 172 The policies that determine whether a particular collection of sites 173 is a VPN are the policies of the customers. Some customers will want 174 the implementation of these policies to be entirely the 175 responsibility of the SP. Other customers may want to share with the 176 SP the responsibility for implementing these policies. This document 177 specifies mechanisms that can be used to implement these policies. 178 The mechanisms we describe are general enough to allow these policies 179 to be implemented either by the SP alone, or by a VPN customer 180 together with the SP. Most of the discussion is focused on the 181 former case, however. 183 The mechanisms discussed in this document allow the implementation of 184 a wide range of policies. For example, within a given VPN, one can 185 allow every site to have a direct route to every other site ("full 186 mesh"). Alternatively, one can force traffic between certain pairs 187 of sites to be routed via a third site. This can be useful, e.g., if 188 it is desired that traffic between a pair of sites be passed through 189 a firewall, and the firewall is located at the third site. 191 In this document, we restrict our discussion to the case in which the 192 customer is explicitly purchasing VPN service from an SP, or from a 193 set of SPs that have agreed to cooperate to provide the VPN service. 194 That is, the customer is not merely purchasing internet access from 195 an SP, and the VPN traffic does not pass through a random collection 196 of interconnected SP networks. 198 We also restrict our discussion to the case in which the backbone 199 provides an IP service to the customer, rather than, e.g, a layer 2 200 service such as Frame Relay, ATM (Asynchronous Transfer Mode), 201 ethernet, HDLC ("High Level Data Link Control"), or PPP (Point-to- 202 Point Protocol). The customer may attach to the backbone via one of 203 these (or other) layer 2 services, but the layer 2 service is 204 terminated at the "edge" of the backbone, where the customer's IP 205 datagrams are removed from any layer 2 encapsulation. 207 In the rest of this introduction, we specify some properties which 208 VPNs should have. The remainder of this document specifies a set of 209 mechanisms that can be deployed to provide a VPN model which has all 210 these properties. This section also introduces some of the technical 211 terminology used in the remainder of the document. 213 1.2. Customer Edge and Provider Edge 215 Routers can be attached to each other, or to end systems, in a 216 variety of different ways: PPP connections, ATM VCs ("Virtual 217 Circuits"), Frame Relay VCs, ethernet interfaces, VLANs ("Virtual 218 Local Area Networks") on ethernet interfaces, GRE tunnels, L2TP 219 ("Layer 2 Tunneling Protocol") tunnels, IPsec tunnels, etc. We will 220 use the term "attachment circuit" to refer generally to some such 221 means of attaching to a router. An attachment circuit may be the 222 sort of connection that is usually thought of as a "data link", or it 223 may be a tunnel of some sort; what matters is that it be possible for 224 two devices to be network layer peers over the attachment circuit. 226 Each VPN site must contain one or more Customer Edge (CE) devices. 227 Each CE device is attached, via some sort of attachment circuit, to 228 one or more Provider Edge (PE) routers. 230 Routers in the SP's network which do not attach to CE devices are 231 known as "P routers". 233 CE devices can be hosts or routers. In a typical case, a site 234 contains one or more routers, some of which are attached to PE 235 routers. The site routers which attach to the PE routers would then 236 be the CE devices, or "CE routers". However, there is nothing to 237 prevent a non-routing host from attaching directly to a PE router, in 238 which case the host would be a CE device. 240 Sometimes, what is physically attached to a PE router is a layer 2 241 switch. In this case, we do NOT say that the layer 2 switch is a CE 242 devices. Rather, the CE devices are the hosts and routers that 243 communicate with the PE router through the layer 2 switch; the layer 244 2 infrastructure is transparent. If the layer 2 infrastructure 245 provides a multipoint service, then multiple CE devices can be 246 attached to the PE router over the same attachment circuit. 248 CE devices are logically part of a customer's VPN. PE and P routers 249 are logically part of the SP's network. 251 The attachment circuit over which a packet travels when going from CE 252 to PE is known as that packet's "ingress attachment circuit", and the 253 PE as the packet's "ingress PE". The attachment circuit over which a 254 packet travels when going from PE to CE is known as that packet's 255 "egress attachment circuit", and the PE as the packet's "egress PE". 257 We will say that a PE router is attached to a particular VPN if it is 258 attached to a CE device which is in a site of that VPN. Similarly, 259 we will say that a PE router is attached to a particular site if it 260 is attached to a CE device which is in that site. 262 When the CE device is a router, it is a routing peer of the PE(s) to 263 which it is attached, but it is NOT a routing peer of CE routers at 264 other sites. Routers at different sites do not directly exchange 265 routing information with each other; in fact, they do not even need 266 to know of each other at all. As a consequence, the customer has no 267 backbone or "virtual backbone" to manage, and does not have to deal 268 with any inter-site routing issues. In other words, in the scheme 269 described in this document, a VPN is NOT an "overlay" on top of the 270 SP's network. 272 With respect to the management of the edge devices, clear 273 administrative boundaries are maintained between the SP and its 274 customers. Customers are not required to access the PE or P routers 275 for management purposes, nor is the SP required to access the CE 276 devices for management purposes. 278 1.3. VPNs with Overlapping Address Spaces 280 If two VPNs have no sites in common, then they may have overlapping 281 address spaces. That is, a given address might be used in VPN V1 as 282 the address of system S1, but in VPN V2 as the address of a 283 completely different system S2. This is a common situation when the 284 VPNs each use an RFC1918 private address space. Of course, within 285 each VPN, each address must be unambiguous. 287 Even two VPNs which do have sites in common may have overlapping 288 address spaces, as long as there is no need for any communication 289 between systems with such addresses and systems in the common sites. 291 1.4. VPNs with Different Routes to the Same System 293 Although a site may be in multiple VPNs, it is not necessarily the 294 case that the route to a given system at that site should be the same 295 in all the VPNs. Suppose, for example, we have an intranet 296 consisting of sites A, B, and C, and an extranet consisting of A, B, 297 C, and the "foreign" site D. Suppose that at site A there is a 298 server, and we want clients from B, C, or D to be able to use that 299 server. Suppose also that at site B there is a firewall. We want 300 all the traffic from site D to the server to pass through the 301 firewall, so that traffic from the extranet can be access controlled. 302 However, we don't want traffic from C to pass through the firewall on 303 the way to the server, since this is intranet traffic. 305 It is possible to set up two routes to the server. One route, used 306 by sites B and C, takes the traffic directly to site A. The second 307 route, used by site D, takes the traffic instead to the firewall at 308 site B. If the firewall allows the traffic to pass, it then appears 309 to be traffic coming from site B, and follows the route to site A. 311 1.5. SP Backbone Routers 313 The SP's backbone consists of the PE routers, as well as other 314 routers ("P routers") which do not attach to CE devices. 316 If every router in an SP's backbone had to maintain routing 317 information for all the VPNs supported by the SP, there would be 318 severe scalability problems; the number of sites that could be 319 supported would be limited by the amount of routing information that 320 could be held in a single router. It is important therefore that the 321 routing information about a particular VPN only needs to be present 322 in the PE routers which attach to that VPN. In particular, the P 323 routers do not need to have ANY per-VPN routing information 324 whatsoever. (This condition may need to be relaxed somewhat when 325 multicast routing is considered. This is not considered further in 326 this paper, but is examined in [VPN-MCAST].) 328 So just as the VPN owners do not have a backbone or "virtual 329 backbone" to administer, the SPs themselves do not have a separate 330 backbone or "virtual backbone" to administer for each VPN. Site-to- 331 site routing in the backbone is optimal (within the constraints of 332 the policies used to form the VPNs), and is not constrained in any 333 way by an artificial "virtual topology" of tunnels. 335 Section 10 discusses some of the special issues that arise when the 336 backbone spans several service providers. 338 1.6. Security 340 VPNs of the sort being discussed here, even without making use of 341 cryptographic security measures, are intended to provide a level of 342 security equivalent to that obtainable when a layer 2 backbone (e.g., 343 Frame Relay) is used. That is, in the absence of misconfiguration or 344 deliberate interconnection of different VPNs, it is not possible for 345 systems in one VPN to gain access to systems in another VPN. Of 346 course the methods described herein do not by themselves encrypt the 347 data for privacy, nor do they provide a way to determine whether data 348 has been tampered with en route. If this is desired, cryptographic 349 measures must be applied in addition. (See, e.g., [MPLS/BGP-IPsec]. 350 Security is discussed in more detail in section 13. 352 2. Sites and CEs 354 From the perspective of a particular backbone network, a set of IP 355 systems may be regarded as a "site" if those systems have mutual IP 356 interconnectivity that doesn't require use of the backbone. In 357 general, a site will consist of a set of systems which are in 358 geographic proximity. However, this is not universally true. If two 359 geographic locations are connected via a leased line, over which OSPF 360 ("Open Shortest Path First" protocol, [OSPFv2]) is running, and if 361 that line is the preferred way of communicating between the two 362 locations, then the two locations can be regarded as a single site, 363 even if each location has its own CE router. (This notion of "site" 364 is topological, rather than geographical. If the leased line goes 365 down, or otherwise ceases to be the preferred route, but the two 366 geographic locations can continue to communicate by using the VPN 367 backbone, then one site has become two.) 369 A CE device is always regarded as being in a single site (though as 370 we shall see in section 3.2), a site may consist of multiple "virtual 371 sites"). A site, however, may belong to multiple VPNs. 373 A PE router may attach to CE devices from any number of different 374 sites, whether those CE devices are in the same or in different VPNs. 375 A CE device may, for robustness, attach to multiple PE routers, of 376 the same or of different service providers. If the CE device is a 377 router, the PE router and the CE router will appear as router 378 adjacencies to each other. 380 While we speak mostly of "sites" as being the basic unit of 381 interconnection, nothing here prevents a finer degree of granularity 382 in the control of interconnectivity. For example, certain systems at 383 a site may be members of an intranet as well as members of one or 384 more extranets, while other systems at the same site may be 385 restricted to being members of the intranet only. However, this 386 might require that the site have two attachment circuits to the 387 backbone, one for the intranet and one for the extranet; it might 388 further require that firewall functionality be applied on the 389 extranet attachment circuit. 391 3. VRFs: Multiple Forwarding Tables in PEs 393 Each PE router maintains a number of separate forwarding tables. One 394 of the forwarding tables is the "default forwarding table". The 395 others are "VPN Routing and Forwarding tables", or "VRFs". 397 3.1. VRFs and Attachment Circuits 399 Every PE-CE attachment circuits is associated, by configuration, with 400 one or more VRFs. An attachment circuit which is associated with a 401 VRF is known as a "VRF attachment circuit". 403 In the simplest case and most typical case, a PE-CE attachment 404 circuit is associated with exactly one VRF. When an IP packet is 405 received over a particular attachment circuit, its destination IP 406 address is looked up in the associated VRF. The result of that 407 lookup determines how to route the packet. The VRF used by a 408 packet's ingress PE for routing a particular packet is known as the 409 packet's "ingress VRF". (There is also the notion of a packet's 410 "egress VRF", located at the packet's egress PE; this is discussed in 411 section 5.) 413 If an IP packet arrives over an attachment circuit which is not 414 associated with any VRF, the packet's destination address is looked 415 up in the default forwarding table, and the packet is routed 416 accordingly. Packets forwarded according to the default forwarding 417 table include packets from neighboring P or PE routers, as well as 418 packets from customer-facing attachment circuits that have not been 419 associated with VRFs. 421 Intuitively, one can think of the default forwarding table as 422 containing "public routes", and of the VRFs as containing "private 423 routes". One can similarly think of VRF attachment circuits as being 424 "private", and of non-VRF attachment circuits as being "public". 426 If a particular VRF attachment circuit connects site S to a PE 427 router, then connectivity from S (via that attachment circuit) can be 428 restricted by controlling the set of routes which get entered in the 429 corresponding VRF. The set of routes in that VRF should be limited 430 to the set of routes leading to sites which have at least one VPN in 431 common with S. Then a packet sent from S over a VRF attachment 432 circuit can only be routed by the PE to another site S' if S' is in 433 one of the same VPNs as S. That is, communication (via PE routers) 434 is prevented between any pair of VPN sites which have no VPN in 435 common. Communication between VPN sites and non-VPN sites is 436 prevented by keeping the routes to the VPN sites out of the default 437 forwarding table. 439 If there are multiple attachment circuits leading from S to one or 440 more PE routers, then there might be multiple VRFs that could be used 441 to route traffic from S. To properly restrict S's connectivity, the 442 same set of routes would have to exist in all the VRFs. 443 Alternatively, one could impose different connectivity restrictions 444 over different attachment circuit from S. In that case, some of the 445 VRFs associated with attachment circuits from S would contain 446 different sets of routes than some of the others. 448 We allow the case in which a single attachment circuit is associated 449 with a set of VRFs, rather than with a single VRF. This can be 450 useful if it is desired to divide a single VPN into several "sub- 451 VPNs", each with different connectivity restrictions, where some 452 characteristic of the customer packets is used to select from among 453 the sub-VPNs. For simplicity though, we will usually speak of an 454 attachment circuit as being associated with a single VRF. 456 3.2. Associating IP Packets with VRFs 458 When a PE router receives a packet from a CE device, it must 459 determine the attachment circuit over which the packet arrived, as 460 this determines in turn the VRF (or set of VRFs) that can be used for 461 forwarding that packet. In general, to determine the attachment 462 circuit over which a packet arrived, a PE router takes note of the 463 physical interface over which the packet arrived, and possibly also 464 takes note of some aspect of the packet's layer 2 header. For 465 example, if a packet's ingress attachment circuit is a frame relay 466 VC, the identity of the attachment circuit can be determined from the 467 physical frame relay interface over which the packet arrived, 468 together with the DLCI ("Data Link Connection Identifier") field in 469 the packet's frame relay header. 471 Although the PE's conclusion that a particular packet arrived on a 472 particular Attachment Circuit may be partially determined by the 473 packet's layer 2 header, it must be impossible for a customer, by 474 writing the header fields, to fool the SP into thinking that a packet 475 which was received over one attachment circuit really arrived over a 476 different one. In the example above, although the attachment circuit 477 is determined partially by inspection of the DLCI field in the frame 478 relay header, this field cannot be set freely by the customer. 479 Rather, it must be set to a value specified by the SP, or else the 480 packet cannot arrive at the PE router. 482 In some cases, a particular site may be divided by the customer into 483 several "virtual sites". The SP may designate a particular set of 484 VRFs to be used for routing packets from that site, and may allow the 485 customer to set some characteristic of the packet which is then used 486 for choosing a particular VRF from the set. 488 For example, each virtual site might be realized as a VLAN. The SP 489 and the customer could agree that on packets arriving from a 490 particular CE, certain VLAN values would be used to identify certain 491 VRFs. Of course, packets from that CE would be discarded by the PE 492 if they carry VLAN tag values that are not in the agreed upon set. 493 Another way to accomplish this is to use IP source addresses. In this 494 case PE uses the IP source address in a packet received from the CE, 495 along with the interface over which the packet is received, to assign 496 the packet to a particular VRF. Again, the customer would only be 497 able to select from among the particular set of VRFs which that 498 customer is allowed to use. 500 If it is desired to have a particular host be in multiple virtual 501 sites, then that host must determine, for each packet, which virtual 502 site the packet is associated with. It can do this, e.g., by sending 503 packets from different virtual sites on different VLANs, or out 504 different network interfaces. 506 3.3. Populating the VRFs 508 With what set of routes are the VRFs populated? 510 As an example, let PE1, PE2, and PE3 be three PE routers, and let 511 CE1, CE2, and CE3 be three CE routers. Suppose that PE1 learns, from 512 CE1, the routes which are reachable at CE1's site. If PE2 and PE3 513 are attached respectively to CE2 and CE3, and there is some VPN V 514 containing CE1, CE2, and CE3, then PE1 uses BGP to distribute to PE2 515 and PE3 the routes which it has learned from CE1. PE2 and PE3 use 516 these routes to populate the VRFs which they associate respectively 517 with the sites of CE2 and CE3. Routes from sites which are not in 518 VPN V do not appear in these VRFs, which means that packets from CE2 519 or CE3 cannot be sent to sites which are not in VPN V. 521 When we speak of a PE "learning" routes from a CE, we are not 522 presupposing any particular learning technique. The PE may learn 523 routes by means of a dynamic routing algorithm, but it may also 524 "learn" routes by having those routes configured (i.e., static 525 routing). (In this case, to say that the PE "learned" the routes 526 from the CE is perhaps to exercise a bit of poetic license.) 528 PEs also need to learn, from other PEs, the routes which belong to a 529 given VPN. The procedures to be used for populating the VRFs with 530 the proper sets of routes are specified in section 4. 532 If there are multiple attachment circuits leading from a particular 533 PE router to a particular site, they might all be mapped to the same 534 forwarding table. But if policy dictates, they could be mapped to 535 different forwarding tables. For instance, the policy might be that 536 a particular attachment circuit from a site is used only for intranet 537 traffic, while another attachment circuit from that site is used only 538 for extranet traffic. (Perhaps, e.g., the CE attached to the 539 extranet attachment circuit is a firewall, while the CE attached to 540 the intranet attachment circuit is not.) In this case, the two 541 attachment circuits would be associated with different VRFs. 543 Note that if two attachment circuits are associated with the same 544 VRF, then packets which the PE receives over one of them will be able 545 to reach exactly the same set of destinations as packets which the PE 546 receives over the other. So two attachment circuits cannot be 547 associated with the same VRF unless each CE is in the exact same set 548 of VPNs as is the other. 550 If an attachment circuit leads to a site which is in multiple VPNs, 551 the attachment circuit may still associated with a single VRF, in 552 which case the VRF will contain routes from the full set of VPNs of 553 which the site is a member. 555 4. VPN Route Distribution via BGP 557 PE routers use BGP to distribute VPN routes to each other (more 558 accurately, to cause VPN routes to be distributed to each other). 560 We allow each VPN to have its own address space, which means that a 561 given address may denote different systems in different VPNs. If two 562 routes, to the same IP address prefix, are actually routes to 563 different systems, it is important to ensure that BGP not treat them 564 as comparable. Otherwise BGP might choose to install only one of 565 them, making the other system unreachable. Further, we must ensure 566 that POLICY is used to determine which packets get sent on which 567 routes; given that several such routes are installed by BGP, only one 568 such must appear in any particular VRF. 570 We meet these goals by the use of a new address family, as specified 571 below. 573 4.1. The VPN-IPv4 Address Family 575 The BGP Multiprotocol Extensions [BGP-MP] allow BGP to carry routes 576 from multiple "address families". We introduce the notion of the 577 "VPN-IPv4 address family". A VPN-IPv4 address is a 12-byte quantity, 578 beginning with an 8-byte "Route Distinguisher (RD)" and ending with a 579 4-byte IPv4 address. If several VPNs use the same IPv4 address 580 prefix, the PEs translate these into unique VPN-IPv4 address 581 prefixes. This ensures that if the same address is used in several 582 different VPNs, it is possible for BGP to carry several completely 583 different routes to that address, one for each VPN. 585 Since VPN-IPv4 addresses and IPv4 addresses are different address 586 families, BGP never treats them as comparable addresses. 588 An RD is simply a number, and it does not contain any inherent 589 information; it does not identify the origin of the route or the set 590 of VPNs to which the route is to be distributed. The purpose of the 591 RD is solely to allow one to create distinct routes to a common IPv4 592 address prefix. Other means are used to determine where to 593 redistribute the route (see section 4.3). 595 The RD can also be used to create multiple different routes to the 596 very same system. We have already discussed a situation in which the 597 route to a particular server should be different for intranet traffic 598 than for extranet traffic. This can be achieved by creating two 599 different VPN-IPv4 routes that have the same IPv4 part, but different 600 RDs. This allows BGP to install multiple different routes to the 601 same system, and allows policy to be used (see section 4.3.5) to 602 decide which packets use which route. 604 The RDs are structured so that every service provider can administer 605 its own "numbering space" (i.e., can make its own assignments of 606 RDs), without conflicting with the RD assignments made by any other 607 service provider. An RD consists of three fields: a two-byte type 608 field, an administrator field, and an assigned number field. The 609 value of the type field determines the lengths of the other two 610 fields, as well as the semantics of the administrator field. The 611 administrator field identifies an assigned number authority, and the 612 assigned number field contains a number which has been assigned, by 613 the identified authority, for a particular purpose. For example, one 614 could have an RD whose administrator field contains an Autonomous 615 System number (ASN), and whose (4-byte) number field contains a 616 number assigned by the SP to whom that ASN belongs (having been 617 assigned to that SP by the appropriate authority). 619 RDs are given this structure in order to ensure that an SP which 620 provides VPN backbone service can always create a unique RD when it 621 needs to do so. However, the structure is not meaningful to BGP; when 622 BGP compares two such address prefixes, it ignores the structure 623 entirely. 625 A PE needs to be configured such that routes which lead to particular 626 CE become associated with a particular RD. The configuration may 627 cause all routes leading to the same CE to be associated with the 628 same RD, or it may be cause different routes to be associated with 629 different RDs, even if they lead to the same CE. 631 4.2. Encoding of Route Distinguishers 633 As stated, a VPN-IPv4 address consists of an 8-byte Route 634 Distinguisher followed by a 4-byte IPv4 address. The RDs are encoded 635 as follows: 637 - Type Field: 2 bytes 638 - Value Field: 6 bytes 640 The interpretation of the Value field depends on the value of the 641 Type field. At the present time, three values of the type field are 642 defined: 0, 1, and 2. 644 - Type 0: The Value field consists of two subfields: 646 * Administrator subfield: 2 bytes 647 * Assigned Number subfield: 4 bytes 649 The Administrator subfield must contain an Autonomous System 650 number. If this ASN is from the public ASN space, it must have 651 been assigned by the appropriate authority (use of ASN values 652 from the private ASN space is strongly discouraged). The 653 Assigned Number subfield contains a number from a numbering space 654 which is administered by the enterprise to which the ASN has been 655 assigned by an appropriate authority. 657 - Type 1: The Value field consists of two subfields: 659 * Administrator subfield: 4 bytes 660 * Assigned Number subfield: 2 bytes 662 The Administrator subfield must contain an IP address. If this IP 663 address is from the public IP address space, it must have been 664 assigned by an appropriate authority (use of addresses from the 665 private IP address space is strongly discouraged). The Assigned 666 Number sub-field contains a number from a numbering space which 667 is administered by the enterprise to which the IP address has 668 been assigned. 670 - Type 2: The Value field consists of two subfields: 672 * Administrator subfield: 4 bytes 673 * Assigned Number subfield: 2 bytes 675 The Administrator subfield must contain a 4-byte Autonomous 676 System number [BGP-AS4]. If this ASN is from the public ASN 677 space, it must have been assigned by the appropriate authority 678 (use of ASN values from the private ASN space is strongly 679 discouraged). The Assigned Number subfield contains a number 680 from a numbering space which is administered by the enterprise to 681 which the ASN has been assigned by an appropriate authority. 683 4.3. Controlling Route Distribution 685 In this section, we discuss the way in which the distribution of the 686 VPN-IPv4 routes is controlled. 688 If a PE router is attached to a particular VPN (by being attached to 689 a particular CE in that VPN), it learns some of that VPN's IP routes 690 from the attached CE router. Routes learned from a CE routing peer 691 over a particular attachment circuit may be installed in the VRF 692 associated with that attachment circuit. Exactly which routes are 693 installed in this manner is determined by the way in which the PE 694 learns routes from the CE. In particular, when the PE and CE are 695 routing protocol peers, this is determined by the decision process of 696 the routing protocol; this is discussed in section 7. 698 These routes are then converted to VPN-IP4 routes, and "exported" to 699 BGP. If there is more than one route to a particular VPN-IP4 address 700 prefix, BGP chooses the "best" one, using the BGP decision process. 701 That route is then distributed by BGP to the set of other PEs that 702 need to know about it. At these other PEs, BGP will again choose the 703 best route for a particular VPN-IP4 address prefix. Then the chosen 704 VPN-IP4 routes are converted back into IP routes, and "imported" into 705 one or more VRFs. Whether they are actually installed in the VRFs 706 depends on the decision process of the routing method used between 707 the PE and those CEs that are associated with the VRF in question. 708 Finally, any route installed in a VRF may be distributed to the 709 associated CE routers. 711 4.3.1. The Route Target Attribute 713 Every VRF is associated with one or more "Route Target" (RT) 714 attributes. 716 When a VPN-IPv4 route is created (from an IPv4 route which the PE has 717 learned from a CE) by a PE router, it is associated with one or more 718 "Route Target" attributes. These are carried in BGP as attributes of 719 the route. 721 Any route associated with Route Target T must be distributed to every 722 PE router that has a VRF associated with Route Target T. When such a 723 route is received by a PE router, it is eligible to be installed in 724 those of the PE's VRFs which are associated with Route Target T. 725 (Whether it actually gets installed depends upon the outcome of the 726 BGP decision process, and upon the outcome of the decision process of 727 the IGP (i.e., the intra-domain routing protocol) running on the PE- 728 CE interface.) 730 A Route Target attribute can be thought of as identifying a set of 731 sites. (Though it would be more precise to think of it as 732 identifying a set of VRFs.) Associating a particular Route Target 733 attribute with a route allows that route to be placed in the VRFs 734 that are used for routing traffic which is received from the 735 corresponding sites. 737 There is a set of Route Targets that a PE router attaches to a route 738 received from site S; these may be called the "Export Targets". And 739 there is a set of Route Targets that a PE router uses to determine 740 whether a route received from another PE router could be placed in 741 the VRF associated with site S; these may be called the "Import 742 Targets". The two sets are distinct, and need not be the same. Note 743 that a particular VPN-IPv4 route is only eligible for installation in 744 a particular VRF if there is some Route Target which is both one of 745 the route's Route Targets and one of the VRF's Import Targets. 747 The function performed by the Route Target attribute is similar to 748 that performed by the BGP Communities Attribute. However, the format 749 of the latter is inadequate for present purposes, since it allows 750 only a two-byte numbering space. It is desirable to structure the 751 format, similar to what we have described for RDs (see section 4.2), 752 so that a type field defines the length of an administrator field, 753 and the remainder of the attribute is a number from the specified 754 administrator's numbering space. This can be done using BGP Extended 755 Communities. The Route Targets discussed herein are encoded as BGP 756 Extended Community Route Targets [BGP-EXTCOMM]. They are structured 757 similarly to the RDs. 759 When a BGP speaker has received more than one route to the same VPN- 760 IPv4 prefix, the BGP rules for route preference are used to choose 761 which VPN-IPv4 route is installed by BGP. 763 Note that a route can only have one RD, but it can have multiple 764 Route Targets. In BGP, scalability is improved if one has a single 765 route with multiple attributes, as opposed to multiple routes. One 766 could eliminate the Route Target attribute by creating more routes 767 (i.e., using more RDs), but the scaling properties would be less 768 favorable. 770 How does a PE determine which Route Target attributes to associate 771 with a given route? There are a number of different possible ways. 772 The PE might be configured to associate all routes that lead to a 773 specified site with a specified Route Target. Or the PE might be 774 configured to associate certain routes leading to a specified site 775 with one Route Target, and certain with another. 777 If the PE and the CE are themselves BGP peers (see section 7), then 778 the SP may allow the customer, within limits, to specify how its 779 routes are to be distributed. The SP and the customer would need to 780 agree in advance on the set of RTs which are allowed to be attached 781 to the customer's VPN routes. The CE could then attach one or more 782 of those RTs to each IP route which it distributes to the PE. This 783 gives the customer the freedom to specify in real time, within agreed 784 upon limits, its route distribution policies. If the CE is allowed 785 to attach RTs to its routes, the PE MUST filter out all routes which 786 contain RTs that the customer is not allowed to use. If the CE is 787 not allowed to attach RTs to its routes, but does so anyway, the PE 788 MUST remove the RT before converting the customer's route to a VPN- 789 IPv4 route. 791 4.3.2. Route Distribution Among PEs by BGP 793 If two sites of a VPN attach to PEs which are in the same Autonomous 794 System, the PEs can distribute VPN-IPv4 routes to each other by means 795 of an IBGP connection between them. (The term "IBGP" refers to the 796 set of protocols and procedures used when there is a BGP connection 797 between two BGP speakers in the same Autonomous System. This is 798 distinguished from "EBGP", the set of procedures used between two BGP 799 speakers in different Autonomous Systems.) Alternatively, each can 800 have an IBGP connection to a route reflector [BGP-RR]. 802 When a PE router distributes a VPN-IPv4 route via BGP, it uses its 803 own address as the "BGP next hop". This address is encoded as a 804 VPN-IPv4 address with an RD of 0. ([BGP-MP] requires that the next 805 hop address be in the same address family as the NLRI ("Network Layer 806 Reachability Information".)) It also assigns and distributes an MPLS 807 label. (Essentially, PE routers distribute not VPN-IPv4 routes, but 808 Labeled VPN-IPv4 routes. Cf. [MPLS-BGP]). When the PE processes a 809 received packet that has this label at the top of the stack, the PE 810 will pop the stack, and process the packet appropriately. 812 The PE may distribute the exact set of routes that appears in the 813 VRF, or it may perform summarization and distribute aggregates of 814 those routes, or it may do some of one and some of the other. 816 Suppose that a PE has assigned label L to route R, and has 817 distributed this label mapping via BGP. If R is an aggregate of a 818 set of routes in the VRF, the PE will know that packets from the 819 backbone which arrive with this label must have their destination 820 addresses looked up in a VRF. When the PE looks up the label in its 821 Label Information Base, it learns which VRF must be used. On the 822 other hand, if R is not an aggregate, then when the PE looks up the 823 label, it learns the egress attachment circuit, as well as the 824 encapsulation header for the packet. In this case, no lookup in the 825 VRF is done. 827 We would expect that the most common case would be the case where the 828 route is NOT an aggregate. The case where it is an aggregate can be 829 very useful though if the VRF contains a large number of host routes 830 (e.g., as in dial-in), or if the VRF has an associated LAN (Local 831 Area Network) interface (where there is a different outgoing layer 2 832 header for each system on the LAN, but a route is not distributed for 833 each such system). 835 Whether each route has a distinct label or not is an implementation 836 matter. There are a number of possible algorithms one could use to 837 determine whether two routes get assigned the same label: 839 - One may choose to have a single label for an entire VRF, so that 840 a single label is shared by all the routes from that VRF. Then 841 when the egress PE receives a packet with that label, it must 842 look up the packet's IP destination address in that VRF (the 843 packet's "egress VRF"), in order to determine the packet's egress 844 attachment circuit and the corresponding data link encapsulation. 846 - One may choose to have a single label for each attachment 847 circuit, so that a single label is shared by all the routes with 848 the same "outgoing attachment circuit". This enables one to 849 avoid doing a lookup in the egress VRF, though some sort of 850 lookup may need to be done in order to determine the data link 851 encapsulation, e.g, an ARP ("Address Resolution Protocol") 852 lookup. 854 - One may choose to have a distinct label for each route. Then if 855 a route is potentially reachable over more than one attachment 856 circuit, the PE/CE routing can switch the preferred path for a 857 route from one attachment circuit to another, without there being 858 any need to distribute new a label for that route. 860 There may be other possible algorithms as well. The choice of 861 algorithm is entirely at the discretion of the egress PE, and is 862 otherwise transparent. 864 In using BGP-distributed MPLS labels in this manner, we presuppose 865 that an MPLS packet carrying such a label can be tunneled from the 866 router that installs the corresponding BGP-distributed route to the 867 router which is the BGP next hop of that route. This requires either 868 that a label switched path exist between those two routers, or else 869 that some other tunneling technology (e.g., [MPLS-in-IP-GRE]) can be 870 used between them. 872 This tunnel may follow a "best effort" route, or it may follow a 873 traffic engineered route. Between a given pair of routers there may 874 be one such tunnel, or there may be several, perhaps with different 875 QoS characteristics. All that matters for the VPN architecture is 876 that some such tunnel exists. To ensure interoperability among 877 systems which implement this VPN architecture using MPLS label 878 switched paths as the tunneling technology, all such systems MUST 879 support LDP ("Label Distribution Protocol", [MPLS-LDP]). In 880 particular, Downstream Unsolicited mode MUST be supported on 881 interfaces which are neither LC-ATM ("Label Controlled ATM") [MPLS- 882 ATM] nor LC-FR ("Label Controlled Frame Relay") [MPLS-FR] interfaces, 883 and Downstream on Demand mode MUST be supported on LC-ATM interfaces 884 and LC-FR interfaces. 886 If the tunnel follows a best effort route, then the PE finds the 887 route to the remote endpoint by looking up its IP address in the 888 default forwarding table. 890 A PE router, UNLESS it is a Route Reflector (see section 4.3.3) or an 891 Autonomous System border router for an inter-provider VPN (see 892 section 10) should not install a VPN-IPv4 route unless it has at 893 least one VRF with an Import Target identical to one of the route's 894 Route Target attributes. Inbound filtering should be used to cause 895 such routes to be discarded. If a new Import Target is later added 896 to one of the PE's VRFs (a "VPN Join" operation), it must then 897 acquire the routes it may previously have discarded. This can be 898 done using the refresh mechanism described in [BGP-RFSH]. The 899 outbound route filtering mechanism of [BGP-ORF] can also be used to 900 advantage to make the filtering more dynamic. 902 Similarly, if a particular Import Target is no longer present in any 903 of a PE's VRFs (as a result of one or more "VPN Prune" operations), 904 the PE may discard all routes which, as a result, no longer have any 905 of the PE's VRF's Import Targets as one of their Route Target 906 Attributes. 908 A router which is not attached to any VPN, and which is not a Route 909 Reflector (i.e., a P router), never installs any VPN-IPv4 routes at 910 all. 912 Note that VPN Join and Prune operations are non-disruptive, and do 913 not require any BGP connections to be brought down, as long as the 914 refresh mechanism of [BGP-RFSH] is used. 916 As a result of these distribution rules, no one PE ever needs to 917 maintain all routes for all VPNs; this is an important scalability 918 consideration. 920 4.3.3. Use of Route Reflectors 922 Rather than having a complete IBGP mesh among the PEs, it is 923 advantageous to make use of BGP Route Reflectors [BGP-RR] to improve 924 scalability. All the usual techniques for using route reflectors to 925 improve scalability, e.g., route reflector hierarchies, are 926 available. 928 Route reflectors are the only systems which need to have routing 929 information for VPNs to which they are not directly attached. 930 However, there is no need to have any one route reflector know all 931 the VPN-IPv4 routes for all the VPNs supported by the backbone. 933 We outline below two different ways to partition the set of VPN-IPv4 934 routes among a set of route reflectors. 936 1. Each route reflector is preconfigured with a list of Route 937 Targets. For redundancy, more than one route reflector may be 938 preconfigured with the same list. A route reflector uses the 939 preconfigured list of Route Targets to construct its inbound 940 route filtering. The route reflector may use the techniques of 941 [BGP-ORF] to install on each of its peers (regardless of 942 whether the peer is another route reflector, or a PE) the set 943 of "Outbound Route Filters" (ORFs) that contain the list of its 944 preconfigured Route Targets. Note that route reflectors should 945 accept ORFs from other route reflectors, which means that route 946 reflectors should advertise the ORF capability to other route 947 reflectors. 949 A service provider may modify the list of preconfigured Route 950 Targets on a route reflector. When this is done, the route 951 reflector modifies the ORFs it installs on all of its IBGP 952 peers. To reduce the frequency of configuration changes on 953 route reflectors, each route reflector may be preconfigured 954 with a block of Route Targets. This way, when a new Route 955 Target is needed for a new VPN, there is already one or more 956 route reflectors that are (pre)configured with this Route 957 Target. 959 Unless a given PE is a client of all route reflectors, when a 960 new VPN is added to the PE ("VPN Join"), it will need to become 961 a client of the route reflector(s) that maintain routes for 962 that VPN. Likewise, deleting an existing VPN from the PE ("VPN 963 Prune") may result in a situation where the PE no longer need 964 to be a client of some route reflector(s). In either case, the 965 Join or Prune operation is non-disruptive (as long as [BGP- 966 RFSH] is used, and never requires a BGP connection to be 967 brought down, only to be brought right back up. 969 (By "adding a new VPN to a PE", we really mean adding a new 970 import Route Target to one of its VRFs, or adding a new VRF 971 with an import Route Target not had by any of the PE's other 972 VRFs.) 974 2. Another method is to have each PE be a client of some subset of 975 the route reflectors. A route reflector is not preconfigured 976 with the list of Route Targets, and does not perform inbound 977 route filtering of routes received from its clients (PEs); 978 rather it accepts all the routes received from all of its 979 clients (PEs). The route reflector keeps track of the set of 980 the Route Targets carried by all the routes it receives. When 981 the route reflector receives from its client a route with a 982 Route Target that is not in this set, this Route Target is 983 immediately added to the set. On the other hand, when the route 984 reflector no longer has any routes with a particular Route 985 Target that is in the set, the route reflector should delay (by 986 a few hours) the deletion of this Route Target from the set. 988 The route reflector uses this set to form the inbound route 989 filters that it applies to routes received from other route 990 reflectors. The route reflector may also use ORFs to install 991 the appropriate outbound route filtering on other route 992 reflectors. Just like with the first approach, a route 993 reflector should accept ORFs from other route reflectors. To 994 accomplish this, a route reflector advertises ORF capability to 995 other route reflectors. 997 When the route reflector changes the set, it should immediately 998 change its inbound route filtering. In addition, if the route 999 reflector uses ORFs, then the ORFs have to be immediately 1000 changed to reflect the changes in the set. If the route 1001 reflector doesn't use ORFs, and a new Route Target is added to 1002 the set, the route reflector, after changing its inbound route 1003 filtering, must issue BGP Refresh to other route reflectors. 1005 The delay of "a few hours" mentioned above allows a route 1006 reflector to hold onto routes with a given RT, even after it 1007 loses the last of its clients which are interested in such 1008 routes. This protects against the need to reacquire all such 1009 routes if the clients' "disappearance" is only temporary. 1011 With this procedure, VPN Join and Prune operations are also 1012 non-disruptive. 1014 Note that this technique will not work properly if some client 1015 PE has a VRF with an import Route Target that is not one of its 1016 export Route Targets. 1018 In these procedures, a PE router which attaches to a particular VPN 1019 "auto-discovers" the other PEs which attach to the same VPN. When a 1020 new PE router is added, or when an existing PE router attaches to a 1021 new VPN, no reconfiguration of other PE routers is needed. 1023 Just as there is no one PE router that needs to know all the VPN-IPv4 1024 routes that are supported over the backbone, these distribution rules 1025 ensure that there is no one RR ("Route Reflector") which needs to 1026 know all the VPN-IPv4 routes that are supported over the backbone. 1027 As a result, the total number of such routes that can be supported 1028 over the backbone is not bounded by the capacity of any single 1029 device, and therefore can increase virtually without bound. 1031 4.3.4. How VPN-IPv4 NLRI is Carried in BGP 1033 The BGP Multiprotocol Extensions [BGP-MP] are used to encode the 1034 NLRI. If the AFI (Address Family Identifier) field is set to 1, and 1035 the SAFI (Subsequent Address Family Identifier) field is set to 128, 1036 the NLRI is an MPLS-labeled VPN-IPv4 address. AFI 1 is used since 1037 the network layer protocol associated with the NLRI is still IP. 1038 Note that this VPN architecture does not require the capability to 1039 distribute unlabeled VPN-IPv4 addresses. 1041 In order for two BGP speakers to exchange labeled VPN-IPv4 NLRI, they 1042 must use BGP Capabilities Advertisement to ensure that they both are 1043 capable of properly processing such NLRI. This is done as specified 1044 in [BGP-MP], by using capability code 1 (multiprotocol BGP), with an 1045 AFI of 1 and an SAFI of 128. 1047 The labeled VPN-IPv4 NLRI itself is encoded as specified in [MPLS- 1048 BGP], where the prefix consists of an 8-byte RD followed by an IPv4 1049 prefix. 1051 4.3.5. Building VPNs using Route Targets 1053 By setting up the Import Targets and Export Targets properly, one can 1054 construct different kinds of VPNs. 1056 Suppose it is desired to create a a fully meshed closed user group, 1057 i.e., a set of sites where each can send traffic directly to the 1058 other, but traffic cannot be sent to or received from other sites. 1059 Then each site is associated with a VRF, a single Route Target 1060 attribute is chosen, that Route Target is assigned to each VRF as 1061 both the Import Target and the Export Target, and that Route Target 1062 is not assigned to any other VRFs as either the Import Target or the 1063 Export Target. 1065 Alternatively, suppose one desired, for whatever reason, to create a 1066 "hub and spoke" kind of VPN. This could be done by the use of two 1067 Route Target values, one meaning "Hub" and one meaning "Spoke". At 1068 the VRFs attached to the hub sites, "Hub" is the Export Target and 1069 "Spoke" is the Import Target. At the VRFs attached to the spoke 1070 site, "Hub" is the Import Target and "Spoke" is the Export Target. 1072 Thus the methods for controlling the distribution of routing 1073 information among various sets of sites are very flexible, which in 1074 turn provides great flexibility in constructing VPNs. 1076 4.3.6. Route Distribution Among VRFs in a Single PE 1078 It is possible to distribute routes from one VRF to another, even if 1079 both VRFs are in the same PE, even though in this case one cannot say 1080 that the route has been distributed by BGP. Nevertheless, the 1081 decision to distribute a particular route from one VRF to another 1082 within a single PE is the same decision that would be made if the 1083 VRFs were on different PEs. That is, it depends on the route target 1084 attribute which is assigned to the route (or would be assigned if the 1085 route were distributed by BGP), and the import target of the second 1086 VRF. 1088 5. Forwarding 1090 If the intermediate routers in the backbone do not have any 1091 information about the routes to the VPNs, how are packets forwarded 1092 from one VPN site to another? 1094 When a PE receives an IP packet from a CE device, it chooses a 1095 particular VRF in which to look up the packet's destination address. 1096 This choice is based on the packet's ingress attachment circuit. 1097 Assume that a match is found. As a result we learn the packet's 1098 "next hop". 1100 If the packet's next hop is reached directly over a VRF attachment 1101 circuit from this PE (i.e., the packet's egress attachment circuit is 1102 on the same PE as its ingress attachment circuit), then the packet is 1103 sent on the egress attachment circuit, and no MPLS labels are pushed 1104 onto the packet's label stack. 1106 If the ingress and egress attachment circuits are on the same PE, but 1107 are associated with different VRFs, and if the route which best 1108 matches the destination address in the ingress attachment circuit's 1109 VRF is an aggregate of several routes in the egress attachment 1110 circuit's VRF, it may be necessary to look up the packet's 1111 destination address in the egress VRF as well. 1113 If the packet's next hop is NOT reached through a VRF attachment 1114 circuit, then the packet must travel at least one hop through the 1115 backbone. The packet thus has a "BGP Next Hop", and the BGP Next Hop 1116 will have assigned an MPLS label for the route that best matches the 1117 packet's destination address. Call this label the "VPN route label". 1118 The IP packet is turned into an MPLS packet with the VPN route label 1119 as the sole label on the label stack. 1121 The packet must then be tunneled to the BGP Next Hop. 1123 If the backbone supports MPLS, this is done as follows: 1125 - The PE routers (and any Autonomous System border routers) which 1126 redistribute VPN-IPv4 addresses need to insert /32 address 1127 prefixes for themselves into the IGP routing tables of the 1128 backbone. This enables MPLS, at each node in the backbone 1129 network, to assign a label corresponding to the route to each PE 1130 router. To ensure interoperability among different 1131 implementations, it is required to support LDP for setting up the 1132 label switched paths across the backbone. However, other methods 1133 of setting up these label switched paths are also possible. 1134 (Some of these other methods may not require the presence of the 1135 /32 address prefixes in the IGP.) 1137 - If there are any traffic engineering tunnels to the BGP next hop, 1138 and if one or more of those is available for use by the packet in 1139 question, one of these tunnels is chosen. This tunnel will be 1140 associated with an MPLS label, the "tunnel label". The tunnel 1141 label gets pushed on the MPLS label stack, and the packet is 1142 forwarded to the tunnel's next hop. 1144 - Otherwise, 1146 * The packet will have an "IGP Next Hop", which is the next hop 1147 along the IGP route to the BGP Next Hop. 1149 * If the BGP Next Hop and the IGP Next Hop are the same, and if 1150 penultimate hop popping is used, the packet is then sent to 1151 the IGP next hop, carrying only the VPN route label. 1153 * Otherwise, the IGP Next Hop will have assigned a label for 1154 the route which best matches the address of the BGP Next Hop. 1155 Call this the "tunnel label". The tunnel label gets pushed 1156 on as the packet's top label. The packet is then forwarded 1157 to the IGP next hop. 1159 - MPLS will then carry the packet across the backbone to the BGP 1160 Next Hop, where the VPN label will be examined. 1162 If the backbone does not support MPLS, the MPLS packet carrying only 1163 the VPN route label may be tunneled to the BGP Next Hop using the 1164 techniques of [MPLS-in-IP-or-GRE]. When the packet emerges from the 1165 tunnel, it will be at the BGP Next Hop, where the VPN route label 1166 will be examined. 1168 At the BGP Next Hop, the treatment of the packet depends on the VPN 1169 route label (see section 4.3.2). In many cases, the PE will be able 1170 to determine, from this label, the attachment circuit over which the 1171 packet should be transmitted (to a CE device), as well as the proper 1172 data link layer header for that interface. In other cases, the PE 1173 may only be able to determine that the packet's destination address 1174 needs to be looked up in a particular VRF before being forwarded to a 1175 CE device. There are also intermediate cases in which the VPN route 1176 label may determine the packet's egress attachment circuit, but a 1177 lookup (e.g., ARP) still needs to be done in order to determine the 1178 packet's data link header on that attachment circuit. 1180 Information in the MPLS header itself, and/or information associated 1181 with the label, may also be used to provide QoS on the interface to 1182 the CE. 1184 In any event, if the packet was an unlabeled IP packet when it 1185 arrived at its ingress PE, it will again be an unlabeled packet when 1186 it leaves its egress PE. 1188 The fact that packets with VPN route labels are tunneled through the 1189 backbone is what makes it possible to keep all the VPN routes out of 1190 the P routers. This is crucial to ensuring the scalability of the 1191 scheme. The backbone does not even need to have routes to the CEs, 1192 only to the PEs. 1194 With respect to the tunnels, it is worth noting that this 1195 specification: 1197 - DOES NOT require that the tunnels be point-to-point; multipoint- 1198 to-point can be used; 1200 - DOES NOT require that there be any explicit setup of the tunnels, 1201 either via signaling or via manual configuration. 1203 - DOES NOT require that there be any tunnel-specific signaling; 1205 - DOES NOT require that there be any tunnel-specific state in the P 1206 or PE routers, beyond what is necessary to maintain the routing 1207 information and (if used) the MPLS label information. 1209 Of course, this specification is compatible with the use of point- 1210 to-point tunnels that must be explicitly configured and/or signaled, 1211 and in some situations there may be reasons for using such tunnels. 1213 The considerations which are relevant to choosing a particular 1214 tunneling technology are outside the scope of this specification. 1216 6. Maintaining Proper Isolation of VPNs 1218 To maintain proper isolation of one VPN from another, it is important 1219 that no router in the backbone accept a tunneled packet from outside 1220 the backbone, unless it is sure that both endpoints of that tunnel 1221 are outside the backbone. 1223 If MPLS is being used as the tunneling technology, this means that a 1224 router in the backbone MUST NOT accept a labeled packet from any 1225 adjacent non-backbone device unless the following two conditions 1226 hold: 1228 1. the label at the top of the label stack was actually 1229 distributed by that backbone router to that non-backbone 1230 device, and 1232 2. the backbone router can determine that use of that label will 1233 cause the packet to leave the backbone before any labels lower 1234 in the stack will be inspected, and before the IP header will 1235 be inspected. 1237 The first condition ensure that any labeled packets received from 1238 non-backbone routers have a legitimate and properly assigned label at 1239 the top of the label stack. The second condition ensures that the 1240 backbone routers will never look below that top label. Of course, 1241 the simplest way to meet these two conditions is just to have the 1242 backbone devices refuse to accept labeled packets from non-backbone 1243 devices. 1245 If MPLS is not being used as the tunneling technology, then filtering 1246 must be done to ensure that an MPLS-in-IP or MPLS-in-GRE packet can 1247 be accepted into the backbone only if the packet's IP destination 1248 address will cause it to be sent outside the backbone. 1250 7. How PEs Learn Routes from CEs 1252 The PE routers which attach to a particular VPN need to know, for 1253 each attachment circuit leading to that VPN, which of the VPN's 1254 addresses should be reached over that attachment circuit. 1256 The PE translates these addresses into VPN-IPv4 addresses, using a 1257 configured RD. The PE then treats these VPN-IPv4 routes as input to 1258 BGP. Routes from a VPN site are NOT leaked into the backbone's IGP. 1260 Exactly which PE/CE route distribution techniques are possible 1261 depends on whether a particular CE is in a "transit VPN" or not. A 1262 "transit VPN" is one which contains a router that receives routes 1263 from a "third party" (i.e., from a router which is not in the VPN, 1264 but is not a PE router), and that redistributes those routes to a PE 1265 router. A VPN which is not a transit VPN is a "stub VPN". The vast 1266 majority of VPNs, including just about all corporate enterprise 1267 networks, would be expected to be "stubs" in this sense. 1269 The possible PE/CE distribution techniques are: 1271 1. Static routing (i.e., configuration) may be used. (This is 1272 likely to be useful only in stub VPNs.) 1274 2. PE and CE routers may be RIP ("Routing Information Protocol", 1275 [RIP]) peers, and the CE may use RIP to tell the PE router the 1276 set of address prefixes which are reachable at the CE router's 1277 site. When RIP is configured in the CE, care must be taken to 1278 ensure that address prefixes from other sites (i.e., address 1279 prefixes learned by the CE router from the PE router) are never 1280 advertised to the PE. More precisely: if a PE router, say 1281 PE1, receives a VPN-IPv4 route R1, and as a result distributes 1282 an IPv4 route R2 to a CE, then R2 must not be distributed back 1283 from that CE's site to a PE router, say PE2, (where PE1 and PE2 1284 may be the same router or different routers), unless PE2 maps 1285 R2 to a VPN-IPv4 route which is different than (i.e., contains 1286 a different RD than) R1. 1288 3. The PE and CE routers may be OSPF peers. A PE router which is 1289 an OSPF peer of a CE router appears, to the CE router, to be an 1290 area 0 router. If a PE router is an OSPF peer of CE routers 1291 which are in distinct VPNs, the PE must of course be running 1292 multiple instances of OSPF. 1294 IPv4 routes which the PE learns from the CE via OSPF are 1295 redistributed into BGP as VPN-IPv4 routes. Extended community 1296 attributes are used to carry, along with the route, all the 1297 information needed to enable the route to be distributed to 1298 other CE routers in the VPN in the proper type of OSPF LSA. 1299 OSPF route tagging is used to ensure that routes received from 1300 the MPLS/BGP backbone are not sent back into the backbone. 1302 Specification of the complete set of procedures for the use of 1303 OSPF between PE and CE can be found in [VPN-OSPF] and [OSPF- 1304 2547-DNBIT]. 1306 4. The PE and CE routers may be BGP peers, and the CE router may 1307 use BGP (in particular, EBGP to tell the PE router the set of 1308 address prefixes which are at the CE router's site. (This 1309 technique can be used in stub VPNs or transit VPNs.) 1311 This technique has a number of advantages over the others: 1313 a) Unlike the IGP alternatives, this does not require the PE 1314 to run multiple routing algorithm instances in order to 1315 talk to multiple CEs 1317 b) BGP is explicitly designed for just this function: 1318 passing routing information between systems run by 1319 different administrations 1321 c) If the site contains "BGP backdoors", i.e., routers with 1322 BGP connections to routers other than PE routers, this 1323 procedure will work correctly in all circumstances. The 1324 other procedures may or may not work, depending on the 1325 precise circumstances. 1327 d) Use of BGP makes it easy for the CE to pass attributes of 1328 the routes to the PE. A complete specification of the 1329 set of attributes and their use is outside the scope of 1330 this document. However, some examples of the way this 1331 may be used are the following: 1333 - The CE may suggest a particular Route Target for each 1334 route, from among the Route Targets that the PE is 1335 authorized to attach to the route. The PE would then 1336 attach only the suggested Route Target, rather than 1337 the full set. This gives the CE administrator some 1338 dynamic control of the distribution of routes from 1339 the CE. 1341 - Additional types of Extended Community attributes may 1342 be defined, where the intention is to have those 1343 attributes passed transparently (i.e., without being 1344 changed by the PE routers) from CE to CE. This would 1345 allow CE administrators to implement additional route 1346 filtering, beyond that which is done by the PEs. 1347 This additional filtering would not require 1348 coordination with the SP. 1350 On the other hand, using BGP may be something new for the CE 1351 administrators. 1353 If a site is not in a transit VPN, note that it need not have a 1354 unique Autonomous System Number (ASN). Every CE whose site is 1355 not in a transit VPN can use the same ASN. This can be chosen 1356 from the private ASN space, and it will be stripped out by the 1357 PE. Routing loops are prevented by use of the Site of Origin 1358 Attribute (see below). 1360 What if a set of sites constitute a transit VPN? This will 1361 generally be the case only if the VPN is itself an Internet 1362 Service Provider's (ISP's) network, where the ISP is itself 1363 buying backbone services from another SP. The latter SP may be 1364 called a "Carrier's Carrier". In this case, the best way to 1365 provide the VPN is to have the CE routers support MPLS, and to 1366 use the technique described in section 9. 1368 When we do not need to distinguish among the different ways in which 1369 a PE can be informed of the address prefixes which exist at a given 1370 site, we will simply say that the PE has "learned" the routes from 1371 that site. This includes the case where the PE has been manually 1372 configured with the routes. 1374 Before a PE can redistribute a VPN-IPv4 route learned from a site, it 1375 must assign a Route Target attribute (see section 4.3.1) to the 1376 route, and it may assign a Site of Origin attribute to the route. 1378 The Site of Origin attribute, if used, is encoded as a Route Origin 1379 Extended Community [BGP-EXTCOMM]. The purpose of this attribute is 1380 to uniquely identify the set of routes learned from a particular 1381 site. This attribute is needed in some cases to ensure that a route 1382 learned from a particular site via a particular PE/CE connection is 1383 not distributed back to the site through a different PE/CE 1384 connection. It is particularly useful if BGP is being used as the 1385 PE/CE protocol, but different sites have not been assigned distinct 1386 ASNs. 1388 8. How CEs learn Routes from PEs 1390 In this section, we assume that the CE device is a router. 1392 If the PE places a particular route in the VRF it uses to route 1393 packets received from a particular CE, then in general, the PE may 1394 distribute that route to the CE. Of course the PE may distribute 1395 that route to the CE only if this is permitted by the rules of the 1396 PE/CE protocol. (For example, if a particular PE/CE protocol has 1397 "split horizon", certain routes in the VRF cannot be redistributed 1398 back to the CE.) We add one more restriction on the distribution of 1399 routes from PE to CE: if a route's Site of Origin attribute 1400 identifies a particular site, that route must never be redistributed 1401 to any CE at that site. 1403 In most cases, however, it will be sufficient for the PE to simply 1404 distribute the default route to the CE. (In some cases, it may even 1405 be sufficient for the CE to be configured with a default route 1406 pointing to the PE.) This will generally work at any site which does 1407 not itself need to distribute the default route to other sites. 1408 (E.g., if one site in a corporate VPN has the corporation's access to 1409 the Internet, that site might need to have default distributed to the 1410 other site, but one could not distribute default to that site 1411 itself.) 1413 Whatever procedure is used to distribute routes from CE to PE will 1414 also be used to distribute routes from PE to CE. 1416 9. Carriers' Carriers 1418 Sometimes a VPN may actually be the network of an ISP, with its own 1419 peering and routing policies. Sometimes a VPN may be the network of 1420 an SP which is offering VPN services in turn to its own customers. 1421 VPNs like these can also obtain backbone service from another SP, the 1422 "carrier's carrier", using essentially the same methods described in 1423 this document. However, it is necessary in these cases that the CE 1424 routers support MPLS. In particular: 1426 - The CE routers should distribute to the PE routers ONLY those 1427 routes which are internal to the VPN. This allows the VPN to be 1428 handled as a stub VPN. 1430 - The CE routers should support MPLS, in that they should be able 1431 to receive labels from the PE routers, and send labeled packets 1432 to the PE routers. They do not need to distribute labels of 1433 their own though. 1435 - The PE routers should distribute, to the CE routers, labels for 1436 the routes they distribute to the CE routers. 1438 The PE must not distribute the same label to two different CEs 1439 unless one of the following conditions holds: 1441 * The two CEs are associated with exactly the same set of VRFs; 1443 * The PE maintains a different Incoming Label Map ([MPLS-ARCH]) 1444 for each CE. 1446 Further, when the PE receives a labeled packet from a CE, it must 1447 verify that the top label is one that was distributed to that CE. 1449 - Routers at the different sites should establish BGP connections 1450 among themselves for the purpose of exchanging external routes 1451 (i.e., routes which lead outside of the VPN). 1453 - All the external routes must be known to the CE routers. 1455 Then when a CE router looks up a packet's destination address, the 1456 routing lookup will resolve to an internal address, usually the 1457 address of the packet's BGP next hop. The CE labels the packet 1458 appropriately and sends the packet to the PE. The PE, rather than 1459 looking up the packet's IP destination address in a VRF, uses the 1460 packet's top MPLS label to select the "BGP next hop". As a result, 1461 if the BGP next hop is more than one hop away, the top label will be 1462 replaced by two labels, a tunnel label and a VPN route label. If the 1463 BGP next hop is one hop away, the top label may be replaced by just 1464 the VPN route label. If the ingress PE is also the egress PE, the 1465 top label will just be popped. When the packet is sent from its 1466 egress PE to a CE, the packet will have one fewer MPLS labels than it 1467 had when it was first received by its ingress PE. 1469 In the above procedure, the CE routers are the only routers in the 1470 VPN which need to support MPLS. If, on the other hand, all the 1471 routers at a particular VPN site support MPLS, then it is no longer 1472 required that the CE routers know all the external routes. All that 1473 is required is that the external routes be known to whatever routers 1474 are responsible for putting the label stack on a hitherto unlabeled 1475 packet, and that there be label switched path that leads from those 1476 routers to their BGP peers at other sites. In this case, for each 1477 internal route that a CE router distributes to a PE router, it must 1478 also distribute a label. 1480 10. Multi-AS Backbones 1482 What if two sites of a VPN are connected to different Autonomous 1483 Systems (e.g., because the sites are connected to different SPs)? 1484 The PE routers attached to that VPN will then not be able to maintain 1485 IBGP connections with each other, or with a common route reflector. 1486 Rather, there needs to be some way to use EBGP to distribute VPN-IPv4 1487 addresses. 1489 There are a number of different ways of handling this case, which we 1490 present in order of increasing scalability. 1492 a) VRF-to-VRF connections at the AS (Autonomous System) border 1493 routers. 1495 In this procedure, a PE router in one AS attaches directly to a 1496 PE router in another. The two PE routers will be attached by 1497 multiple sub-interfaces, at least one for each of the VPNs 1498 whose routes need to be passed from AS to AS. Each PE will 1499 treat the other as if it were a CE router. That is, the PEs 1500 associate each such sub-interface with a VRF, and use EBGP to 1501 distribute unlabeled IPv4 addresses to each other. 1503 This is a procedure that "just works", and that does not 1504 require MPLS at the border between ASes. However, it does not 1505 scale as well as the other procedures discussed below. 1507 b) EBGP redistribution of labeled VPN-IPv4 routes from AS to 1508 neighboring AS. 1510 In this procedure, the PE routers use IBGP to redistribute 1511 labeled VPN-IPv4 routes either to an Autonomous System Border 1512 Router (ASBR), or to a route reflector of which an ASBR is a 1513 client. The ASBR then uses EBGP to redistribute those labeled 1514 VPN-IPv4 routes to an ASBR in another AS, which in turn 1515 distributes them to the PE routers in that AS, or perhaps to 1516 another ASBR which in turn distributes them ... 1518 When using this procedure, VPN-IPv4 routes should only be 1519 accepted on EBGP connections at private peering points, as part 1520 of a trusted arrangement between SPs. VPN-IPv4 routes should 1521 neither be distributed to nor accepted from the public 1522 Internet, or from any BGP peers which are not trusted. An ASBR 1523 should never accept a labeled packet from an EBGP peer unless 1524 it has actually distributed the top label to that peer. 1526 If there are many VPNs having sites attached to different 1527 Autonomous Systems, there does not need to be a single ASBR 1528 between those two ASes which holds all the routes for all the 1529 VPNs; there can be multiple ASBRs, each of which holds only the 1530 routes for a particular subset of the VPNs. 1532 This procedure requires that there be a label switched path 1533 leading from a packet's ingress PE to its egress PE. Hence the 1534 appropriate trust relationships must exist between and among 1535 the set of ASes along the path. Also, there must be agreement 1536 among the set of SPs as to which border routers need to receive 1537 routes with which Route Targets. 1539 c) Multihop EBGP redistribution of labeled VPN-IPv4 routes between 1540 source and destination ASes, with EBGP redistribution of 1541 labeled IPv4 routes from AS to neighboring AS. 1543 In this procedure, VPN-IPv4 routes are neither maintained nor 1544 distributed by the ASBRs. An ASBR must maintain labeled IPv4 1545 /32 routes to the PE routers within its AS. It uses EBGP to 1546 distribute these routes to other ASes. ASBRs in any transit 1547 ASes will also have to use EBGP to pass along the labeled /32 1548 routes. This results in the creation of a label switched path 1549 from the ingress PE router to the egress PE router. Now PE 1550 routers in different ASes can establish multi-hop EBGP 1551 connections to each other, and can exchange VPN-IPv4 routes 1552 over those connections. 1554 If the /32 routes for the PE routers are made known to the P 1555 routers of each AS, everything works normally. If the /32 1556 routes for the PE routers are NOT made known to the P routers 1557 (other than the ASBRs), then this procedure requires a packet's 1558 ingress PE to put a three label stack on it. The bottom label 1559 is assigned by the egress PE, corresponding to the packet's 1560 destination address in a particular VRF. The middle label is 1561 assigned by the ASBR, corresponding to the /32 route to the 1562 egress PE. The top label is assigned by the ingress PE's IGP 1563 Next Hop, corresponding to the /32 route to the ASBR. 1565 To improve scalability, one can have the multi-hop EBGP 1566 connections exist only between a route reflector in one AS and 1567 a route reflector in another. (However, when the route 1568 reflectors distribute routes over this connection, they do not 1569 modify the BGP next hop attribute of the routes.) The actual 1570 PE routers would then only have IBGP connections to the route 1571 reflectors in their own AS. 1573 This procedure is very similar to the "Carrier's Carrier" 1574 procedures described in section 9. Like the previous procedure, 1575 it requires that there be a label switched path leading from a 1576 packet's ingress PE to its egress PE. 1578 11. Accessing the Internet from a VPN 1580 Many VPN sites will need to be able to access the public Internet, as 1581 well as to access other VPN sites. The following describes some of 1582 the alternative ways of doing this. 1584 1. In some VPNs, one or more of the sites will obtain Internet 1585 Access by means of an "Internet gateway" (perhaps a firewall) 1586 attached to a non-VRF interface to an ISP. The ISP may or may 1587 not be the same organization as the SP which is providing the 1588 VPN service. Traffic to/from the Internet gateway would then 1589 be routed according to the PE router's default forwarding 1590 table. 1592 In this case, the sites which have Internet Access may be 1593 distributing a default route to their PEs, which in turn 1594 redistribute it to other PEs and hence into other sites of the 1595 VPN. This provides Internet Access for all of the VPN's sites. 1597 In order to properly handle traffic from the Internet, the ISP 1598 must distribute, to the Internet, routes leading to addresses 1599 that are within the VPN. This is completely independent of any 1600 of the route distribution procedures described in this 1601 document. The internal structure of the VPN will in general 1602 not be visible from the Internet; such routes would simply lead 1603 to the non-VRF interface that attaches to the VPN's Internet 1604 gateway. 1606 In this model, there is no exchange of routes between a PE 1607 router's default forwarding table and any of its VRFs. VPN 1608 route distribution procedures and Internet route distribution 1609 procedures are completely independent. 1611 Note that although some sites of the VPN use a VRF interface to 1612 communicate with the Internet, ultimately all packets to/from 1613 the Internet traverse a non-VRF interface before 1614 leaving/entering the VPN, so we refer to this as "non-VRF 1615 Internet Access". 1617 Note that the PE router to which the non-VRF interface attaches 1618 does not necessarily need to maintain all the Internet routes 1619 in its default forwarding table. The default forwarding table 1620 could have as few as one route, "default", which leads to 1621 another router (probably an adjacent one) which has the 1622 Internet routes. A variation of this scheme is to tunnel 1623 packets received over the non-VRF interface from the PE router 1624 to another router, where this other router maintains the full 1625 set of Internet routes. 1627 2. Some VPNs may obtain Internet access via a VRF interface ("VRF 1628 Internet Access"). If a packet is received by a PE over a VRF 1629 interface, and if the packet's destination address does not 1630 match any route in the VRF, then it may be matched against the 1631 PE's default forwarding table. If a match is made there, the 1632 packet can be forwarded natively through the backbone to the 1633 Internet, instead of being forwarded by MPLS. 1635 In order for traffic to flow natively in the opposite direction 1636 (from Internet to VRF interface), some of the routes from the 1637 VRF must be exported to the Internet forwarding table. 1638 Needless to say, any such routes must correspond to globally 1639 unique addresses. 1641 In this scheme, the default forwarding table might have the 1642 full set of Internet routes, or it might have a little as a 1643 single default route leading to another router which does have 1644 the full set of Internet routes in its default forwarding 1645 table. 1647 3. Suppose the PE has the capability to store "non-VPN routes" in 1648 a VRF. If a packet's destination address matches a "non-VPN 1649 route", then the packet is transmitted natively, rather than 1650 being transmitted via MPLS. If the VRF contains a non-VPN 1651 default route, all packets for the public Internet will match 1652 it, and be forwarded natively to the default route's next hop. 1653 At that next hop, the packets' destination addresses will be 1654 looked up in the default forwarding table, and may match more 1655 specific routes. 1657 This technique would only be available if none of the CE 1658 routers is distributing a default route. 1660 4. It is also possible to obtain Internet access via a VRF 1661 interface by having the VRF contain the Internet routes. 1662 Compared with model 2, this eliminates the second lookup, but 1663 it has the disadvantage of requiring the Internet routes to be 1664 replicated in each such VRF. 1666 If this technique is used, the SP may want to make its 1667 interface to the Internet be a VRF interface, and to use the 1668 techniques of section 4 to distribute Internet routes, as VPN- 1669 IPv4 routes, to other VRFs. 1671 It should be clearly understood that by default, there is no exchange 1672 of routes between a VRF and the default forwarding table. This is 1673 done ONLY upon agreement between a customer and a SP, and only if it 1674 suits the customer's policies. 1676 12. Management VPNs 1678 This specification does not require that the sub-interface connecting 1679 a PE router and a CE router be a "numbered" interface. If it is a 1680 numbered interface, this specification allows the addresses assigned 1681 to the interface to come from either the address space of the VPN or 1682 the address space of the SP. 1684 If a CE router is being managed by the Service Provider, then the 1685 Service Provider will likely have a network management system which 1686 needs to be able to communicate with the CE router. In this case, 1687 the addresses assigned to the sub-interface connecting the CE and PE 1688 routers should come from the SP's address space, and should be unique 1689 within that space. The network management system should itself 1690 connect to a PE router (more precisely, be at a site which connects 1691 to a PE router) via a VRF interface. The address of the network 1692 management system will be exported to all VRFs which are associated 1693 with interfaces to CE routers that are managed by the SP. The 1694 addresses of the CE routers will be exported to the VRF associated 1695 with the Network Management system, but not to any other VRFs. 1697 This allows communication between CE and Network Management system, 1698 but does not allow any undesired communication to or among the CE 1699 routers. 1701 One way to ensure that the proper route import/exports are done is to 1702 use two Route Targets, call them T1 and T2. If a particular VRF 1703 interface attaches to a CE router that is managed by the SP, then 1704 that VRF is configured to: 1706 - import routes that have T1 attached to them, and 1708 - attach T2 to addresses assigned to each end of its VRF 1709 interfaces. 1711 If a particular VRF interface attaches to the SP's Network Management 1712 system, then that VRF is configured to attach T1 to the address of 1713 that system, and to import routes that have T2 attached to them. 1715 13. Security Considerations 1717 13.1. Data Plane 1719 By security in the "data plane", we mean protection against the 1720 following possibilities: 1722 - Packets from within a VPN travel to a site outside the VPN, other 1723 than in a manner consistent with the policies of the VPN. 1725 - Packets from outside a VPN enter one of the VPN's sites, other 1726 than in a manner consistent with the policies of the VPN. 1728 Under the following conditions: 1730 1. a backbone router does not accept labeled packets over a 1731 particular data link, unless it is known that that data link 1732 attaches only to trusted systems, or unless it is known that 1733 such packets will leave the backbone before the IP header or 1734 any labels lower in the stack will be inspected, and 1736 2. labeled VPN-IPv4 routes are not accepted from untrusted or 1737 unreliable routing peers, 1739 3. no successful attacks have been mounted on the control plane, 1741 the data plane security provided by this architecture is virtually 1742 identical to that provided to VPNs by Frame Relay or ATM backbones. 1743 If the devices under the control of the SP are properly configured, 1744 data will not enter or leave a VPN unless authorized to do so. 1746 Condition 1 above can be stated more precisely. One should discard a 1747 labeled packet received from a particular neighbor unless one of the 1748 following two conditions holds: 1750 - the packet's top label has a label value which the receiving 1751 system has distributed to that neighbor, or 1753 - the packet's top label has a label value which the receiving 1754 system has distributed to a system beyond that neighbor (i.e., 1755 when it is known that the path from the system to which the label 1756 was distributed to the receiving system may be via that 1757 neighbor). 1759 Condition 2 above is of most interest in the case of inter-provider 1760 VPNs (see section 10). For inter-provider VPNs constructed according 1761 to scheme b) of section 10, condition 2 is easily checked. (The 1762 issue of security when scheme c) of section 10 is used is for further 1763 study.) 1765 It is worth noting that the use of MPLS makes it much simpler to 1766 provide data plane security than might be possible if one attempted 1767 to use some form of IP tunneling in place of the MPLS outer label. 1768 It is a simple matter to have one's border routers refuse to accept a 1769 labeled packet unless the first of the above conditions applies to 1770 it. It is rather more difficult to configure a router to refuse to 1771 accept an IP packet if that packet is an IP tunneled packet whose 1772 destination address is that of a PE router; certainly this is not 1773 impossible to do, but it has both management and performance 1774 implications. 1776 MPLS-in-IP and MPLS-in-GRE tunneling are specified in [MPLS-in-IP- 1777 GRE]. If it is desired to use such tunnels to carry VPN packets, 1778 then the security considerations described in section 8 of that 1779 document must be fully understood. Any implementation of BGP/MPLS IP 1780 VPNs which allows VPN packets to be tunneled as described in that 1781 document MUST contain an implementation of IPsec which can be used as 1782 therein described. If the tunnel is not secured by IPsec, then the 1783 technique of IP address filtering at the border routers, described in 1784 section 8.2 of that document, is the only means of ensuring that a 1785 packet which exits the tunnel at a particular egress PE was actually 1786 placed in the tunnel by the proper tunnel head node (i.e., that the 1787 packet does not have a spoofed source address). Since border routers 1788 frequently filter only source addresses, packet filtering may not be 1789 effective unless the egress PE can check the IP source address of any 1790 tunneled packet it receives, and compare it to a list of IP addresses 1791 which are valid tunnel head addresses. Any implementation which 1792 allows MPLS-in-IP and/or MPLS-in-GRE tunneling to be used without 1793 IPsec MUST allow the egress PE to validate in this manner the IP 1794 source address of any tunneled packet that it receives. 1796 In the case where a number of CE routers attach to a PE router via a 1797 LAN interface, to ensure proper security, one of the following 1798 conditions must hold: 1800 1. All the CE routers on the LAN belong to the same VPN, or 1802 2. A trusted and secured LAN switch divides the LAN into multiple 1803 VLANs, with each VLAN containing only systems of a single VPN; 1804 in this case the switch will attach the appropriate VLAN tag to 1805 any packet before forwarding it to the PE router. 1807 Cryptographic privacy is not provided by this architecture, nor by 1808 Frame Relay or ATM VPNs. These architectures are all compatible with 1809 the use of cryptography on a CE-CE basis, if that is desired. 1811 The use of cryptography on a PE-PE basis is for further study. 1813 13.2. Control Plane 1815 The data plane security of the previous section depends on the 1816 security of the control plane. To ensure security, neither BGP nor 1817 LDP connections should be made with untrusted peers. The TCP/IP MD5 1818 authentication option [TCP-MD5] should be used with both these 1819 protocols. The routing protocol within the SP's network should also 1820 be secured in a similar manner. 1822 13.3. Security of P and PE devices 1824 If the physical security of these devices is compromised, data plane 1825 security may also be compromised. 1827 The usual steps should be take to ensure that IP traffic from the 1828 public Internet cannot be used to modify the configuration of these 1829 devices, or to mount Denial of Service attacks on them. 1831 14. Quality of Service 1833 Although not the focus of this paper, Quality of Service is a key 1834 component of any VPN service. In MPLS/BGP VPNs, existing L3 QoS 1835 capabilities can be applied to labeled packets through the use of the 1836 "experimental" bits in the shim header [MPLS-ENCAPS], or, where ATM 1837 is used as the backbone, through the use of ATM QoS capabilities. 1838 The traffic engineering work discussed in [MPLS-RSVP] is also 1839 directly applicable to MPLS/BGP VPNs. Traffic engineering could even 1840 be used to establish label switched paths with particular QoS 1841 characteristics between particular pairs of sites, if that is 1842 desirable. Where an MPLS/BGP VPN spans multiple SPs, the 1843 architecture described in [PASTE] may be useful. An SP may apply 1844 either intserv (Integrated Services) or diffserv (Differentiated 1845 Services) capabilities to a particular VPN, as appropriate. 1847 15. Scalability 1849 We have discussed scalability issues throughout this paper. In this 1850 section, we briefly summarize the main characteristics of our model 1851 with respect to scalability. 1853 The Service Provider backbone network consists of (a) PE routers, (b) 1854 BGP Route Reflectors, (c) P routers (which are neither PE routers nor 1855 Route Reflectors), and, in the case of multi-provider VPNs, (d) 1856 ASBRs. 1858 P routers do not maintain any VPN routes. In order to properly 1859 forward VPN traffic, the P routers need only maintain routes to the 1860 PE routers and the ASBRs. The use of two levels of labeling is what 1861 makes it possible to keep the VPN routes out of the P routers. 1863 A PE router maintains VPN routes, but only for those VPNs to which it 1864 is directly attached. 1866 Route reflectors can be partitioned among VPNs so that each partition 1867 carries routes for only a subset of the VPNs supported by the Service 1868 Provider. Thus no single route reflector is required to maintain 1869 routes for all VPNs. 1871 For inter-provider VPNs, if the ASBRs maintain and distribute VPN- 1872 IPv4 routes, then the ASBRs can be partitioned among VPNs in a 1873 similar manner, with the result that no single ASBR is required to 1874 maintain routes for all the inter-provider VPNs. If multi-hop EBGP 1875 is used, then the ASBRs need not maintain and distribute VPN-IPv4 1876 routes at all. 1878 As a result, no single component within the Service Provider network 1879 has to maintain all the routes for all the VPNs. So the total 1880 capacity of the network to support increasing numbers of VPNs is not 1881 limited by the capacity of any individual component. 1883 16. IANA Considerations 1885 IANA ("Internet Assigned Numbers Authority") needs to create a new 1886 registry for the "Route Distinguisher Type Field" (see section 4.2). 1887 This is a two-byte field. Types 0, 1, and 2 are defined by this 1888 document. Additional Route Distinguisher Type field values with a 1889 high-order bit of 0 may be allocated by IANA on a "First Come, First 1890 Served" basis [IANA]. Values with a high-order bit of 1 may be 1891 allocated by IANA based on "IETF consensus" [IANA]. 1893 This document specifies (see section 4.3.4) the use of the BGP AFI 1894 (Address Family Identifier) value 1, along with the BGP SAFI 1895 (Subsequent Address Family Identifier) value 128, to represent the 1896 address family "VPN-IPv4 Labeled Addresses", which is defined in this 1897 document. 1899 The use of AFI value 1 for IP is as currently specified in the IANA 1900 registry "Address Family Identifier", so IANA need take no action 1901 with respect to it. 1903 At the time of this writing, the SAFI value 128 is specified as 1904 "Private Use" in the IANA "Subsequent Address Family Identifier" 1905 registry. As this value is used in a large number of deployments, 1906 and it is not feasible to change it. Therefore IANA should change 1907 the SAFI value 128 from "private use" to "MPLS-labeled VPN address". 1909 17. Acknowledgments 1911 The full list of contributors can be found in section 20. 1913 Significant contributions to this work have also been made by Ravi 1914 Chandra, Dan Tappan and Bob Thomas. 1916 We also wish to thank Shantam Biswas for his review and 1917 contributions. 1919 18. Authors' Addresses 1921 Eric C. Rosen 1922 Cisco Systems, Inc. 1923 1414 Massachusetts Avenue 1924 Boxborough, MA 01719 1925 E-mail: erosen@cisco.com 1927 Yakov Rekhter 1928 Juniper Networks 1929 1194 N. Mathilda Avenue 1930 Sunnyvale, CA 94089 1931 E-mail: yakov@juniper.net 1933 19. Contributors 1935 Tony Bogovic 1936 Telcordia Technologies 1937 445 South Street, Room 1A264B 1938 Morristown, NJ 07960 1939 E-mail: tjb@research.telcordia.com 1941 Stephen John Brannon 1942 Swisscom AG 1943 Postfach 1570 1944 CH-8301 1945 Glattzentrum (Zuerich), Switzerland 1946 E-mail: stephen.brannon@swisscom.com 1948 Marco Carugi 1949 Nortel Networks S.A. 1950 Parc d'activit�s de Magny-Les Jeunes Bois CHATEAUFORT 1951 78928 YVELINES Cedex 9 - FRANCE 1952 Email : marco.carugi@nortelnetworks.com 1954 Christopher J. Chase 1955 AT&T 1956 200 Laurel Ave 1957 Middletown, NJ 07748 1958 USA 1959 E-mail: chase@att.com 1961 Ting Wo Chung 1962 Bell Nexxia 1963 181 Bay Street 1964 Suite 350 1965 Toronto, Ontario 1966 M5J2T3 1967 E-mail: ting_wo.chung@bellnexxia.com 1969 Eric Dean 1970 Jeremy De Clercq 1971 Alcatel Network Strategy Group 1972 Francis Wellesplein 1 1973 2018 Antwerp, Belgium 1974 E-mail: jeremy.de_clercq@alcatel.be 1976 Luyuan Fang 1977 AT&T 1978 IP Backbone Architecture 1979 200 Laurel Ave. 1980 Middletown, NJ 07748 1981 E-mail: luyuanfang@att.com 1983 Paul Hitchen 1984 BT 1985 BT Adastral Park 1986 Martlesham Heath, 1987 Ipswich IP5 3RE 1988 UK 1989 E-mail: paul.hitchen@bt.com 1991 Manoj Leelanivas 1992 Juniper Networks, Inc. 1993 385 Ravendale Drive 1994 Mountain View, CA 94043 USA 1995 E-mail: manoj@juniper.net 1997 Dave Marshall 1998 Worldcom 1999 901 International Parkway 2000 Richardson, Texas 75081 2001 E-mail: dave.marshall@wcom.com 2003 Luca Martini 2004 Level 3 Communications, LLC. 2005 1025 Eldorado Blvd. 2006 Broomfield, CO, 80021 2007 E-mail: luca@level3.net 2008 Monique Jeanne Morrow 2009 Cisco Systems, Inc. 2010 Glatt-com, 2nd floor 2011 CH-8301 2012 Glattzentrum, Switzerland 2013 E-mail: mmorrow@cisco.com 2015 Ravichander Vaidyanathan 2016 Telcordia Technologies 2017 445 South Street, Room 1C258B 2018 Morristown, NJ 07960 2019 E-mail: vravi@research.telcordia.com 2021 Adrian Smith 2022 BT 2023 BT Adastral Park 2024 Martlesham Heath, 2025 Ipswich IP5 3RE 2026 UK 2027 E-mail: adrian.ca.smith@bt.com 2029 Vijay Srinivasan 2030 1200 Bridge Parkway 2031 Redwood City, CA 94065 2032 E-mail: vsriniva@cosinecom.com 2034 Alain Vedrenne 2035 Equant 2036 Heraklion, 1041 route des Dolines, BP347 2037 06906 Sophia Antipolis, Cedex, france 2038 Email: Alain.Vedrenne@equant.com 2040 20. Normative References 2042 [BGP] "Border Gateway Protocol 4 (BGP-4)", Rekhter and Li, RFC 1771, 2043 March 1995 2045 [BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol Extensions 2046 for BGP4", RFC 2858, June 2000 2048 [BGP-EXTCOMM] Sangli, Tappan, and Rekhter, "BGP Extended Communities 2049 Attribute", draft-ietf-idr-bgp-ext-communities-07.txt, March 2004 2051 [MPLS-ARCH] Rosen, Viswanathan, and Callon, "Multiprotocol Label 2052 Switching Architecture", RFC 3031, January 2001 2054 [MPLS-BGP] Rekhter and Rosen, "Carrying Label Information in BGP4", 2055 RFC 3107, May 2001 2057 [MPLS-ENCAPS] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and 2058 Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001 2060 21. Informational References 2062 [BGP-AS4] Vohra and Chen, "BGP Support for Four-Octet AS Number 2063 Space", draft-ietf-idr-as4bytes-08.txt, March 2004 2065 [BGP-ORF] Chen, Rekhter, "Cooperative Route Filtering Capability for 2066 BGP-4", draft-ietf-idr-route-filter-10.txt, March 2004 2068 [BGP-RFSH] Chen, "Route Refresh Capability for BGP-4", RFC 2918, 2069 March 2000 2071 [BGP-RR] Bates, Chandra, and Chen, "BGP Route Reflection: An 2072 alternative to full mesh IBGP", RFC 2796, April 2000 2074 [IANA] Narten, Alvestrand, "Guidelines for Writing an IANA 2075 Considerations Section in RFCs", RFC 2434, October 1998 2077 [IPSEC] Kent and Atkinson, "Security Architecture for the Internet 2078 Protocol", RFC 2401, November 1998 2080 [MPLS-ATM] Davie, Doolan, Lawrence, McCloghrie, Rosen, Swallow, and 2081 Rekhter, "MPLS using LDP and ATM VC Switching", RFC 3035, January 2082 2001 2084 [MPLS/BGP-IPsec] Rosen, De Clercq, Paridaen, T'Joens, and Sargor, 2085 "Use of PE-PE IPsec in RFC2547 VPNs", draft-ietf-l3vpn-ipsec-2547- 2086 02.txt, March 2004 2088 [MPLS-FR] Conta, Doolan, Malis, "Use of Label Switching on Frame 2089 Relay Networks Specification" RFC 3034, January 2001 2091 [MPLS-in-IP-GRE] Worster, Rekhter, and Rosen, "Encapsulating MPLS in 2092 IP or GRE", draft-ietf-mpls-in-ip-or-gre-08.txt, June 2004 2094 [MPLS-LDP] Andersson, Doolan, Feldman, Fredette, Thomas, "LDP 2095 Specification", RFC 3036, January 2001 2097 [MPLS-RSVP] Awduche, Berger, Gan, Li, Srinavasan, Swallow, "RSVP-TE: 2098 Extensions to RSVP for LSP Tunnels", RFC 3209, February 2001 2100 [OSPFv2] Moy, "OSPF Version 2", RFC 2328, April 1998 2102 [PASTE] Li and Rekhter, "A Provider Architecture for Differentiated 2103 Services and Traffic Engineering (PASTE)", RFC 2430, October 1998 2105 [RIP] Malkin, "RIP Version 2", RFC 2453, November 1998 2107 [OSPF-2547-DNBIT] Rosen, Psenak, and Pillay-Esnault, "Using an LSA 2108 Options Bit to Prevent Looping in BGP/MPLS IP VPNs", draft-ietf- 2109 ospf-2547-dnbit-04.txt, March 2004 2111 [TCP-MD5] Heffernan, "Protection of BGP Sessions via the TCP MD5 2112 Signature Option", RFC 2385, August 1998 2114 [VPN-MCAST] Rosen, Cai, Wijsnands, "Multicast in MPLS/BGP VPNs", 2115 draft-rosen-vpn-mcast-07.txt, May 2004 2117 [VPN-OSPF] Rosen, Psenak and Pillay-Esnault, "OSPF as the PE/CE 2118 Protocol in BGP/MPLS VPNs", draft-ietf-l3vpn-ospf-2547-01.txt, 2119 February 2004 2121 22. Intellectual Property Statement 2123 The IETF takes no position regarding the validity or scope of any 2124 Intellectual Property Rights or other rights that might be claimed to 2125 pertain to the implementation or use of the technology described in 2126 this document or the extent to which any license under such rights 2127 might or might not be available; nor does it represent that it has 2128 made any independent effort to identify any such rights. Information 2129 on the procedures with respect to rights in RFC documents can be 2130 found in BCP 78 and BCP 79. 2132 Copies of IPR disclosures made to the IETF Secretariat and any 2133 assurances of licenses to be made available, or the result of an 2134 attempt made to obtain a general license or permission for the use of 2135 such proprietary rights by implementers or users of this 2136 specification can be obtained from the IETF on-line IPR repository at 2137 http://www.ietf.org/ipr. 2139 The IETF invites any interested party to bring to its attention any 2140 copyrights, patents or patent applications, or other proprietary 2141 rights that may cover technology that may be required to implement 2142 this standard. Please address the information to the IETF at ietf- 2143 ipr@ietf.org. 2145 23. Full Copyright Statement 2147 Copyright (C) The Internet Society (2004). This document is subject 2148 to the rights, licenses and restrictions contained in BCP 78 and 2149 except as set forth therein, the authors retain all their rights. 2151 This document and the information contained herein are provided on an 2152 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2153 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2154 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2155 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2156 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2157 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.