Internet Draft Network Working Group Eric C. Rosen Internet Draft Yakov Rekhter Expiration Date: September 2000 Cisco Systems, Inc. Stephen John Brannon Monique Jeanne Morrow Swisscom AG Marco Carugi France Telecom Christopher J. Chase AT&T Eric Dean Global One Paul Hitchin Adrian Smith BT Manoj Leelanivas Juniper Networks, Inc. Luca Martini Level 3 Communications, LLC Vijay Srinivasan Ericsson IP Infrastructure Alain Vedrenne SITA EQUANT March 2000 BGP/MPLS VPNs draft-rosen-rfc2547bis-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that Rosen, et al. [Page 1] Internet Draft draft-rosen-rfc2547bis-00.txt March 2000 other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document describes a method by which a Service Provider may use an IP backbone to provide VPNs for its customers. MPLS is used for forwarding packets over the backbone, and BGP is used for distributing routes over the backbone. The primary goal of this method is to support the case in which a client obtains IP backbone services from a Service Provider or Service Providers with which it maintains contractual relationships. The client may be an enterprise, a group of enterprises which need an extranet, an Internet Service Provider, another VPN Service Provider (even one which uses this same method to offer VPNs to clients of its own), an application service provider, etc. The method makes it very simple for the client to use the backbone services. It is also very scalable and flexible for the Service Provider, and allows the Service Provider to add value. This document obsoletes RFC 2547. Rosen, et al. [Page 2] Internet Draft draft-rosen-rfc2547bis-00.txt March 2000 Table of Contents 1 Introduction ....................................... 3 1.1 Virtual Private Networks ........................... 4 1.2 Edge Devices ....................................... 5 1.3 VPNs with Overlapping Address Spaces ............... 6 1.4 VPNs with Different Routes to the Same System ...... 6 1.5 Multiple Forwarding Tables in PEs .................. 7 1.6 SP Backbone Routers ................................ 7 1.7 Security ........................................... 8 2 Sites and CEs ...................................... 8 3 VRFs: Per-Site Forwarding Tables in the PEs ........ 9 3.1 Virtual Sites ...................................... 10 4 VPN Route Distribution via BGP ..................... 11 4.1 The VPN-IPv4 Address Family ........................ 11 4.2 Encoding of Route Distinguishers ................... 12 4.3 Controlling Route Distribution ..................... 13 4.3.1 The Route Target Attribute ......................... 13 4.3.2 Route Distribution Among PEs by BGP ................ 15 4.3.3 How VPN-IPv4 NLRI is Carried in BGP ................ 18 4.3.4 Building VPNs using Route Targets .................. 18 5 Forwarding Across the Backbone ..................... 19 6 How PEs Learn Routes from CEs ...................... 20 7 How CEs learn Routes from PEs ...................... 23 8 Carriers' Carriers ................................. 24 9 Security ........................................... 24 10 Quality of Service ................................. 25 11 Scalability ........................................ 25 12 Intellectual Property Considerations ............... 26 13 Acknowledgments .................................... 26 14 Authors' Addresses ................................. 26 15 References ......................................... 29 16 Full Copyright Statement ........................... 29 1. Introduction Rosen, et al. [Page 3] Internet Draft draft-rosen-rfc2547bis-00.txt March 2000 1.1. Virtual Private Networks Consider a set of "sites" which are attached to a common network which we may call the "backbone". Let's apply some policy to create a number of subsets of that set, and let's impose the following rule: two sites may have IP interconnectivity over that backbone only if at least one of these subsets contains them both. The subsets we have created are "Virtual Private Networks" (VPNs). Two sites have IP connectivity over the common backbone only if there is some VPN which contains them both. Two sites which have no VPN in common have no connectivity over that backbone. If all the sites in a VPN are owned by the same enterprise, the VPN is a corporate "intranet". If the various sites in a VPN are owned by different enterprises, the VPN is an "extranet". A site can be in more than one VPN; e.g., in an intranet and several extranets. We regard both intranets and extranets as VPNs. In general, when we use the term VPN we will not be distinguishing between intranets and extranets. We wish to consider the case in which the backbone is owned and operated by one or more Service Providers (SPs). The owners of the sites are the "customers" of the SPs. The policies that determine whether a particular collection of sites is a VPN are the policies of the customers. Some customers will want the implementation of these policies to be entirely the responsibility of the SP. Other customers may want to implement these policies themselves, or to share with the SP the responsibility for implementing these policies. In this document, we are primarily discussing mechanisms that may be used to implement these policies. The mechanisms we describe are general enough to allow these policies to be implemented either by the SP alone, or by a VPN customer together with the SP. Most of the discussion is focused on the former case, however. The mechanisms discussed in this document allow the implementation of a wide range of policies. For example, within a given VPN, we can allow every site to have a direct route to every other site ("full mesh"), or we can restrict certain pairs of sites from having direct routes to each other ("partial mesh"). In this document, we are interested in the case where the common backbone offers an IP service. We are NOT focused on the case where the common backbone is part of the public Internet, but rather on the case where it the backbone network of an SP or set of SPs with which the customer maintains contractual relationships. The customer should be thought of as purchasing VPN service from the SP, not merely as purchasing Internet access from it. The customer itself Rosen, et al. [Page 4] Internet Draft draft-rosen-rfc2547bis-00.txt March 2000 may be a single enterprise, a set of enterprises needing an extranet, an Internet Service Provider, or even another SP which offers the same kind of VPN service to its own customers. In the rest of this introduction, we specify some properties which VPNs should have. The remainder of this document outlines a VPN model which has all these properties. 1.2. Edge Devices We suppose that at each site, there are one or more Customer Edge (CE) devices, each of which is attached via some sort of data link (e.g., PPP, ATM, ethernet, Frame Relay, GRE tunnel, etc.) to one or more Provider Edge (PE) routers. Routers in the Provider's network which do not attach to CE devices are known as "P routers". If a particular site has a single host, that host may be the CE device. If a particular site has a single subnet, the CE device may be a switch. In general, the CE device can be expected to be a router, which we call the CE router. We will say that a PE router is attached to a particular VPN if it is attached to a CE device which is in that VPN. Similarly, we will say that a PE router is attached to a particular site if it is attached to a CE device which is in that site. When the CE device is a router, it is a routing peer of the PE(s) to which it is attached, but is not a routing peer of CE routers at other sites. Routers at different sites do not directly exchange routing information with each other; in fact, they do not even need to know of each other at all. As a consequence, very large VPNs (i.e., VPNs with a very large number of sites) are easily supported, while the routing strategy for each individual site is greatly simplified. It is important that the scheme allow clear administrative boundaries to be maintained between the SP and its customers. There is no requirement for the PE or P routers to be managed by the customers, or for the CE devices to be managed by the SP. Rosen, et al. [Page 5] Internet Draft draft-rosen-rfc2547bis-00.txt March 2000 1.3. VPNs with Overlapping Address Spaces We assume that any two non-intersecting VPNs (i.e., VPNs with no sites in common) may have overlapping address spaces; the same address may be reused, for different systems, in different VPNs. (This allows the SP to support the common case of VPNs which use the RFC1918 addressing space, for example.) As long as a given endsystem has an address which is unique within the scope of the VPNs that it belongs to, the endsystem itself does not need to know anything about VPNs. In this model, the VPN owners do not have a backbone to administer, not even a "virtual backbone." Nor do the SPs have to administer a separate backbone or "virtual backbone" for each VPN. Site-to-site routing in the backbone is optimal (within the constraints of the policies used to form the VPNs), and is not constrained in any way by an artificial "virtual topology" of tunnels. 1.4. VPNs with Different Routes to the Same System Although a site may be in multiple VPNs, it is not necessarily the case that the route to a given system at that site should be the same in all the VPNs. Suppose, for example, we have an intranet consisting of sites A, B, and C, and an extranet consisting of A, B, C, and the "foreign" site D. Suppose that at site A there is a server, and we want clients from B, C, or D to be able to use that server. Suppose also that at site B there is a firewall. We want all the traffic from site D to the server to pass through the firewall, so that traffic from the extranet can be access controlled. However, we don't want traffic from C to pass through the firewall on the way to the server, since this is intranet traffic. This means that it needs to be possible to set up two routes to the server. One route, used by sites B and C, takes the traffic directly to site A. The second route, used by site D, takes the traffic instead to the firewall at site B. If the firewall allows the traffic to pass, it then appears to be traffic coming from site B, and follows the route to site A. Rosen, et al. [Page 6] Internet Draft draft-rosen-rfc2547bis-00.txt March 2000 1.5. Multiple Forwarding Tables in PEs Each PE router needs to maintain a number of separate forwarding tables. Every site to which the PE is attached must be mapped to one of those forwarding tables. When a packet is received from a particular site, the forwarding table associated with that site is consulted in order to determine how to route the packet. The forwarding table associated with a particular site S is populated only with routes that lead to other sites which have at least one VPN in common with S. This prevents communication between sites which have no VPN in common, and it allows two VPNs with no site in common to use address spaces that overlap with each other. 1.6. SP Backbone Routers The SP's backbone consists of the PE routers, as well as other routers ("P routers") which do not attach to CE devices. If every router in an SP's backbone had to maintain routing information for all the VPNs supported by the SP, this model would have severe scalability problems; the number of sites that could be supported would be limited by the amount of routing information that could be held in a single router. It is important therefore that the routing information about a particular VPN is only required to be present in those PE routers which attach to that VPN. In particular, the P routers should not need to have ANY per-VPN routing information whatsoever. (This condition may need to be relaxed somewhat when multicast routing is considered. This is hnot considered further in this paper.) VPNs may span multiple service providers. There are a number of possible methods for implementing this. In one approach, when the path between PE routers crosses a boundary between SP networks, the ASBRs use EBGP to exchange VPN-IPv4 routes, and label switched paths cross the boundary between providers. The presupposition is that this is done via a private peering arrangement, at which there exists mutual trust between the two providers. In particular, each provider must trust the other to pass it only correct routing information, and to pass it labeled (in the sense of MPLS [MPLS-ARCH]) packets only if those packets have been labeled by trusted sources. A variety of other approaches are also possible. Rosen, et al. [Page 7] Internet Draft draft-rosen-rfc2547bis-00.txt March 2000 1.7. Security A VPN model should, even without the use of cryptographic security measures, provide a level of security equivalent to that obtainable when a level 2 backbone (e.g., Frame Relay) is used. That is, in the absence of misconfiguration or deliberate interconnection of different VPNs, it should not be possible for systems in one VPN to gain access to systems in another VPN. 2. Sites and CEs From the perspective of a particular backbone network, a set of IP systems constitutes a site if those systems have mutual IP interconnectivity, and communication between them occurs without use of the backbone. In general, a site will consist of a set of systems which are in geographic proximity. However, this is not universally true. If two geographic locations are connected via a leased line, over which OSPF is running, and if that line is the preferred way of communicating between the two locations, then the two locations can be regarded as a single site, even if each location has its own CE router. A CE device is always regarded as being in a single site (though as we shall see, a site may consist of multiple "virtual sites"). A site, however, may belong to multiple VPNs. A PE router may attach to CE devices in any number of different sites, whether those CE devices are in the same or in different VPNs. A CE device may, for robustness, attach to multiple PE routers, of the same or of different service providers. If the CE device is a router, the PE router and the CE router will appear as router adjacencies to each other. While the basic unit of interconnection is the site, the architecture described herein allows a finer degree of granularity in the control of interconnectivity. For example, certain systems at a site may be members of an intranet as well as members of one or more extranets, while other systems at the same site may be restricted to being members of the intranet only. Rosen, et al. [Page 8] Internet Draft draft-rosen-rfc2547bis-00.txt March 2000 3. VRFs: Per-Site Forwarding Tables in the PEs Each PE router maintains one or more "per-site forwarding tables." These are known as VRFs, or "VPN Routing and Forwarding" tables. Every site to which the PE router is attached is associated with one of these tables. A particular packet's IP destination address is looked up in a particular VRF only if that packet has arrived directly from a site which is associated with that table. How are the VRFs populated? As an example, let PE1, PE2, and PE3 be three PE routers, and let CE1, CE2, and CE3 be three CE routers. Suppose that PE1 learns, from CE1, the routes which are reachable at CE1's site. If PE2 and PE3 are attached respectively to CE2 and CE3, and there is some VPN V containing CE1, CE2, and CE3, then PE1 uses BGP to distribute to PE2 and PE3 the routes which it has learned from CE1. PE2 and PE3 use these routes to populate the VRFs which they associate respectively with the sites of CE2 and CE3. Routes from sites which are not in VPN V do not appear in these VRFs, which means that packets from CE2 or CE3 cannot be sent to sites which are not in VPN V. If a site is in multiple VPNs, the VRF associated with that site can contain routes from the full set of VPNs of which the site is a member. A PE generally associates only one VRF to each site, even if it is multiply connected to that site. However, different sites can share the same VRF if they are meant to use exactly the same set of routes. Routes from the Internet do not need to be present in the VRF associated with a given interface, even if the SP is providing Internet access over that interface. There are two basic methods for providing Internet access over an interface that is associated with a VRF: 1. The VRF may contain a default route which leads to a firewall. This ensures that packets headed towards the Internet are always passed through a firewall first. 2. If a packet is received over a particular interface, and its destination address does not match any entry in the VRF, then the packet's destination address may be matched against the PE's Internet forwarding table. This can be useful if the packets have already been through a firewall, for instance. Note that only one Internet forwarding table per PE is needed in this case; the Internet routes do not need to be present in the VRFs. Rosen, et al. [Page 9] Internet Draft draft-rosen-rfc2547bis-00.txt March 2000 Of course, if Internet access is not provided over a particular interface, and the packet's destination address has no match in the associated VRF, the packet is treated as undeliverable. The VRFs in a PE are ONLY used for packets which arrive from a site which is directly attached to the PE. They are not used for routing packets which arrive from other routers that belong to the SP backbone. As a result, there may be multiple different routes to the same system, where the route followed by a given packet is determined by the site from which the packet enters the backbone. E.g., one may have one route to a given system for packets from the extranet (where the route leads to a firewall), and a different route to the same system for packets from the intranet (including packets that have already passed through the firewall). 3.1. Virtual Sites In some cases, a particular site may be divided by the customer into several virtual sites, perhaps by the use of VLANs. Each virtual site may be a member of a different set of VPNs. The PE then needs to contain a separate VRF for each virtual site. For example, if a CE supports VLANs, and wants each VLAN mapped to a separate VPN, the packets sent between CE and PE could be contained in the site's VLAN encapsulation. Then the VLAN tag could be used by the PE, along with the interface over which the packet is received, to assign the packet to a particular VPN. Alternatively, one could divide the interface into multiple "sub- interfaces" (particularly if the interface is Frame Relay or ATM), and assign the packet to a VPN based on the sub-interface over which it arrives. Or one could simply use a different interface for each virtual site. In any case, only one CE router is ever needed per site, even if there are multiple virtual sites. Of course, a different CE router could be used for each virtual site, if that is desired. Note that in all these cases, the mechanisms, as well as the policy, for controlling which traffic is in which VPN are in the hand of the customer. If it is desired to have a particular host be in multiple virtual sites, then that host must determine, for each packet, which virtual site the packet is associated with. It can do this, e.g., by sending packets from different virtual sites on different VLANs, our out different network interfaces. Rosen, et al. [Page 10] Internet Draft draft-rosen-rfc2547bis-00.txt March 2000 4. VPN Route Distribution via BGP PE routers use BGP to distribute VPN routes to each other (more accurately, to cause VPN routes to be distributed to each other). We allow each VPN to have its own address space, which means that a given address may denote different systems in different VPNs. If two routes, to the same IP address prefix, are actually routes to different systems, it is important to ensure that BGP not treat them as comparable. Otherwise BGP might choose to install only one of them, making the other system unreachable. Further, we must ensure that POLICY is used to determine which packets get sent on which routes; given that several such routes are installed by BGP, only one such must appear in any particular VRF. We meet these goals by the use of a new address family, as specified below. 4.1. The VPN-IPv4 Address Family The BGP Multiprotocol Extensions [BGP-MP] allow BGP to carry routes from multiple "address families". We introduce the notion of the "VPN-IPv4 address family". A VPN-IPv4 address is a 12-byte quantity, beginning with an 8-byte "Route Distinguisher (RD)" and ending with a 4-byte IPv4 address. If two VPNs use the same IPv4 address prefix, the PEs translate these into unique VPN-IPv4 address prefixes. This ensures that if the same address is used in two different VPNs, it is possible to install two completely different routes to that address, one for each VPN. The RD does not by itself impose any semantics; it contains no information about the origin of the route or about the set of VPNs to which the route is to be distributed. The purpose of the RD is solely to allow one to create distinct routes to a common IPv4 address prefix. Other means are used to determine where to redistribute the route (see section 4.2). The RD can also be used to create multiple different routes to the very same system. In section 3, we gave an example where the route to a particular server had to be different for intranet traffic than for extranet traffic. This can be achieved by creating two different VPN-IPv4 routes that have the same IPv4 part, but different RDs. This allows BGP to install multiple different routes to the same system, and allows policy to be used (see section 4.2.3) to decide which packets use which route. The RDs are structured so that every service provider can administer Rosen, et al. [Page 11] Internet Draft draft-rosen-rfc2547bis-00.txt March 2000 its own "numbering space" (i.e., can make its own assignments of RDs), without conflicting with the RD assignments made by any other service provider. An RD consists of a two-byte type field, an administrator field, and an assigned number field. The value of the type field determines the lengths of the other two fields, as well as the semantics of the administrator field. The administrator field identifies an assigned number authority, and the assigned number field contains a number which has been assigned, by the identified authority, for a particular purpose. For example, one could have an RD whose administrator field contains an Autonomous System number (ASN), and whose (4-byte) number field contains a number assigned by the SP to whom IANA has assigned that ASN. RDs are given this structure in order to ensure that an SP which provides VPN backbone service can always create a unique RD when it needs to do so. However, the structuring provides no semantics. When BGP compares two such address prefixes, it ignores the structure entirely. Note that VPN-IPv4 addresses and IPv4 addresses are always considered by BGP to be incomparable. A VRF may have multiple equal cost VPN-IPv4 routes for a single IPv4 address prefix. When a packet's destination address is matched against a VPN-IPv4 route, only the IPv4 part is actually matched. A PE needs to be configured to associate routes which lead to particular CE with a particular RD. The PE may be configured to associate all routes leading to the same CE with the same RD, or it may be configured to associate different routes with different RDs, even if they lead to the same CE. 4.2. Encoding of Route Distinguishers As stated, a VPN-IPv4 address consists of an 8-byte Route Distinguisher followed by a 4-byte IPv4 address. The RDs are encoded as follows: - Type Field: 2 bytes - Value Field: 6 bytes The interpretation of the Value field depends on the value of the Type field. At the present time, two values of the type field are defined: 0 and 1. Rosen, et al. [Page 12] Internet Draft draft-rosen-rfc2547bis-00.txt March 2000 - Type 0: The Value field consists of two subfields: * Administrator subfield: 2 bytes * Assigned Number subfield: 4 bytes The Administrator subfield must contain an Autonomous System number. If this ASN is from the public ASN space, it must have been assigned by IANA (use of ASN values from the private ASN space is strongly discouraged). The Assigned Number subfield contains a number from a numbering space which is administered by the enterprise to which the ASN has been assigned by IANA. - Type 1: The Value field consists of two subfields: * Administrator subfield: 4 bytes * Assigned Number subfield: 2 bytes The Administrator subfield must contain an IP address. If this IP address has been assigned by IANA to a particular enterprise, the Assigned Number sub-field contains a number from a numbering space which is administered by the enterprise to which the IP address has been assigned (use of addresses from the private IP address space is strongly discouraged). 4.3. Controlling Route Distribution In this section, we discuss the way in which the distribution of the VPN-IPv4 routes is controlled. 4.3.1. The Route Target Attribute Every VRF is associated with one or more "Route Target" attributes. When a VPN-IPv4 route is created by a PE router, it is associated with one or more "Route Target" attributes. These are carried in BGP as attributes of the route. Any route associated with Route Target T must be distributed to every PE router that has a VRF associated with Route Target T. When such a route is received by a PE router, it is eligible to be installed in each of the PE's VRFs that is associated with Route Target T. (Whether it actually gets installed depends on the outcome of the BGP decision process.) A Route Target attribute can be thought of as identifying a set of sites. (Though it would be more precise to think of it as Rosen, et al. [Page 13] Internet Draft draft-rosen-rfc2547bis-00.txt March 2000 identifying a set of VRFs.) Associating a particular Route Target attribute with a route allows that route to be placed in the VRFs that are used for routing traffic which is received from the corresponding sites. There is a set of Route Targets that a PE router attaches to a route received from site S; these may be called the "Export Targets". And there is a set of Route Targets that a PE router uses to determine whether a route received from another PE router could be placed in the VRF associated with site S; these may be called the "Import Targets". The two sets are distinct, and need not be the same. Note that a particular VPN-IPv4 route is only eligible for installation in a particular VRF if there is some Route Target which is both one of the route's Route Targets and one of the VRF's Import Targets. The function performed by the Route Target attribute is similar to that performed by the BGP Communities Attribute. However, the format of the latter is inadequate, since it allows only a two-byte numbering space. It is desirable to structure the format, similar to what we have described for RDs (see section 4.1), so that a type field defines the length of an administrator field, and the remainder of the attribute is a number from the specified administrator's numbering space. This can be done using BGP Extended Communities. The Route Targets discussed herein are encoded as BGP Extended Community Route Targets [BGP-EXTCOMM]. When a BGP speaker has received more than one route to the same VPN- IPv4 prefix, the BGP rules for route preference are used to choose which route are installed. Note that a route can only have one RD, but it can have multiple Route Targets. In BGP, scalability is improved if one has a single route with multiple attributes, as opposed to multiple routes. One could eliminate the Route Target attribute by creating more routes (i.e., using more RDs), but the scaling properties would be less favorable. How does a PE determine which Route Target attributes to associate with a given route? There are a number of different possible ways. The PE might be configured to associate all routes that lead to a particular site with a particular Route Target. Or the PE might be configured to associate certain routes leading to a particular site with one Route Target, and certain with another. Or the CE router, when it distributes these routes to the PE (see section 6), might specify one or more Route Targets for each route. The latter method shifts the control of the mechanisms used to implement the VPN policies from the SP to the customer. If this method is used, it may still be desirable to have the PE eliminate any Route Targets that, Rosen, et al. [Page 14] Internet Draft draft-rosen-rfc2547bis-00.txt March 2000 according to its own configuration, are not allowed, and/or to add in some Route Targets that according to its own configuration are mandatory. 4.3.2. Route Distribution Among PEs by BGP If two sites of a VPN attach to PEs which are in the same Autonomous System, the PEs can distribute VPN-IPv4 routes to each other by means of an IBGP connection between them. Alternatively, each can have an IBGP connection to a route reflector. What if two sites of a VPN are in different Autonomous Systems (e.g., because they are connected to different SPs)? One way to handle this is to have the PE routers use IBGP to redistribute VPN-IPv4 routes either to an Autonomous System Border Router (ASBR), or to a route reflector of which an ASBR is a client. The ASBR then needs to use EBGP to redistribute those routes to an ASBR in another AS. This allows one to connect different VPN sites to different Service Providers. However, VPN-IPv4 routes should only be accepted on EBGP connections at private peering points, as part of a trusted arrangement between SPs. VPN-IPv4 routes should neither be distributed to nor accepted from the public Internet. If there are many VPNs having sites attached to different Autonomous Systems, there does not need to be a single ASBR between those two ASes which holds all the routes for all the VPNs; there can be multiple ASBRs, each of which holds only the routes for a particular subset of the VPNs. There are other ways of handling the multi-provider case as well. For example, something similar to the Carrier's Carrier architecture described in section 8 can be used. The PE routers could only distribute their internal routes to the ASBRs, and PE routers in different ASes could form multi-hop EBGP connections to distribute their external routes. When a PE router distributes a VPN-IPv4 route via BGP, it uses its own address as the "BGP next hop". This address is encoded as a VPN-IPv4 address with an RD of 0. ([BGP-MP] requires that the next hop address be in the same address family as the NLRI.) It also assigns and distributes an MPLS label. (Essentially, PE routers distribute not VPN-IPv4 routes, but Labeled VPN-IPv4 routes. Cf. [MPLS-BGP]) When the PE processes a received packet that has this label at the top of the stack, the PE will pop the stack, and send the packet directly to the site from to which the route leads. This will usually mean that it just sends the packet to the CE router from which it learned the route. The label may also determine the data Rosen, et al. [Page 15] Internet Draft draft-rosen-rfc2547bis-00.txt March 2000 link encapsulation. In most cases, the label assigned by a PE will cause the packet to be sent directly to a CE, and the PE which receives the labeled packet will not look up the packet's destination address in any VRF. However, it is also possible for the PE to assign a label which implicitly identifies a particular VRF. In this case, the PE receiving a packet with that label would look up the packet's destination address in the associated VRF. This allows the route distributed and labeled by BGP to be an aggregate of several routes which appear in the VRF. This can be very useful if the VRF contains a large number of host routes (e.g., as in dial-in), or if the VRF has an associated LAN interface (where there is a different outgoing layer 2 header for each system on the LAN, but a route is not distributed for each such system). However, we do not consider this further in this paper. Note that the MPLS label that is distributed in this way is only usable if there is a label switched path between the router that installs a route and the BGP next hop of that route. It may be a "best effort" route, or it may be a traffic engineered route. Between a particular PE router and its BGP next hop for a particular route there may be one label switched path, or there may be several, perhaps with different QoS characteristics. All that matters for the VPN architecture is that some label switched path between the router and its BGP next hop exists. However, to ensure interoperability among systems which implement this VPN architecture, all such systems must support LDP [MPLS-LDP]. All the usual techniques for using route reflectors [BGP-RR] to improve scalability, e.g., route reflector hierarchies, are available. If route reflectors are used, there is no need to have any one route reflector know all the VPN-IPv4 routes for all the VPNs supported by the backbone. The following outlines two possible approaches to partition all the VPN-IPv4 routes among the route reflectors. In the first approach each route reflector is preconfigured with a list of Route Targets. For redundancy more than one route reflector may be preconfigured with the same list. A route reflector uses the preconfigured list of Route Targets to construct its inbound route filtering. On all of its IBGP peers (regardless of whether the peer is another route reflector, or a PE), the route reflector may use the techniques of [BGP-ORF] to install on its peer route reflectors the set of "Outbound Route Filters" (ORFs) that contain the list of its preconfigured Route Targets. Note that route reflectors should accept ORFs from other route reflectors, which means that route reflectors should advertise the ORF capability to other route reflectors. Rosen, et al. [Page 16] Internet Draft draft-rosen-rfc2547bis-00.txt March 2000 A service provider may modify the list of preconfigured Route Targets on a route reflector. When this is done, the route reflector modifies the ORFs it installs on all of its IBGP peers. To reduce the frequency of configuration changes on route reflectors, each route reflector may be preconfigured with a block of Route Targets. This way, when a new Route Target is needed for a new VPN, there is already one or more route reflectors that are (pre)configured with this Route Target. Unless a given PE is a client of all route reflectors, adding a new VPN to the PE may require the PE to become a client of the route reflector(s) that maintain routes for that VPN. Likewise, deleting an existing VPN from the PE may result in a situation where the PE no longer need to be a client of some route reflector(s). In the second approach each PE is a client of some subset of route reflectors. A route reflector is not preconfigured with the list of Route Targets, and does not perform inbound route filtering of routes received from its clients (PEs); rather it accepts all the routes received from all of its clients (PEs). The route reflector keeps track of the set of the Route Targets carried by all the routes it receives. When the route reflector receives from its client a route with a Route Target that is not in this set, this Route Target is immediately added to the set. On the other hand, when the route reflector no longer has any routes with a particular Route Target that is in the set, the route reflector should delay (by a few hours) the deletion of this Route Target from the set. The route reflector uses this set to form the inbound route filters that it applies to routes received from other route reflectors. The route reflector may also use ORFs to install the appropriate outbound route filtering on other route reflectors. Just like with the first approach, a route reflector should accept ORFs from other route reflectors. To accomplish this, a route reflector advertises ORF capability to other route reflectors. When the route reflector changes the set, it should immediately change its inbound route filtering. In addition, if the route reflector uses ORFs, then the ORFs have to be immediately changed to reflect the changes in the set. If the route reflector doesn't use ORFs, and a new Route Target is added to the set, the route reflector, after changing its inbound route filtering, must issue BGP Refresh to other router reflectors. A PE router (other than a Route Reflector) should not install a VPN- IPv4 route unless it has at least one VRF with an Import Target identical to one of the route's Route Target attributes. Inbound filtering should be used to cause such routes to be discarded. If a Rosen, et al. [Page 17] Internet Draft draft-rosen-rfc2547bis-00.txt March 2000 new Import Target is later added to the PE, it must then acquire the routes it may previously have discarded. This can be done using the refresh mechanism described in [BGP-RFSH]. The outbound route filtering mechanism of [BGP-ORF] can also be used to advantage to make the filtering more dynamic. A router which is not attached to any VPN, i.e., a P router, never installs any VPN-IPv4 routes at all. These distribution rules ensure that there is no one box which needs to know all the VPN-IPv4 routes that are supported over the backbone. As a result, the total number of such routes that can be supported over the backbone is not bounded by the capacity of any single device, and therefore can increase virtually without bound. 4.3.3. How VPN-IPv4 NLRI is Carried in BGP The BGP Multiprotocol Extensions [BGP-MP] are used to encode the NLRI. If the AFI field is set to 1, and the SAFI field is set to 128, the NLRI is an MPLS-labeled VPN-IPv4 address. AFI 1 is used since the network layer protocol associated with the NLRI is still IP. Note that this VPN architecture never distributes unlabeled VPN-IPv4 addresses. In order for two BGP speakers to exchange labeled VPN-IPv4 NLRI, they must use BGP Capabilities Negotiation to ensure that they both are capable of properly processing such NLRI. This is done as specified in [BGP-MP], by using capability code 1 (multiprotocol BGP), with an AFI of 1 and an SAFI of 128. The labeled VPN-IPv4 NLRI itself is encoded as specified in [MPLS- BGP], where the prefix consists of an 8-byte RD followed by an IPv4 prefix. 4.3.4. Building VPNs using Route Targets By setting up the Import Targets and Export Targets properly, one can construct different kinds of VPNs. Suppose it is desired to create a a fully meshed closed user group, i.e., a set of sites where each can send traffic directly to the other, but traffic cannot be sent to or received from other sites. Then each site is associated with a VRF, a single Route Target attribute is chosen, that Route Target is assigned to each VRF as both the Import Target and the Export Target, and that Route Target is not assigned to any other VRFs as either the Import Target or the Rosen, et al. [Page 18] Internet Draft draft-rosen-rfc2547bis-00.txt March 2000 Export Target. Alternatively, suppose one desired, for whatever reason, to create a "hub and spoke" kind of VPN. This could be done by the use of two Route Target values, one meaning "Hub" and one meaning "Spoke". At the VRFs attached to the hub sites, "Hub" is the Export Target and "Spoke" is the Import Target. At the VRFs attached to the spoke site, "Hub" is the Import Target and "Spoke" is the Export Target. Thus the methods for controlling the distribution of routing information among various sets of sites are very flexible, which in turn provides great flexibility in constructing VPNs. 5. Forwarding Across the Backbone If the intermediate routers in the backbone do not have any information about the routes to the VPNs, how are packets forwarded from one VPN site to another? This is done by means of MPLS with a two-level label stack. PE routers (and ASBRs which redistribute VPN-IPv4 addresses) need to insert /32 address prefixes for themselves into the IGP routing tables of the backbone. This enables MPLS, at each node in the backbone network, to assign a label corresponding to the route to each PE router. To ensure interoperability among different implementations, it is required to support LDP for setting up the label switched paths across the backbone. However, other methods of setting up these label switched paths are also possible. (Some of these other methods may not require the presence of the /32 address prefixes in the IGP.) When a PE receives a packet from a CE device, it chooses a particular VRF in which to look up the packet's destination address. Assume that a match is found. If the packet's next hop is a CE device attached to this same PE, the packet is sent directly to that CE device, If the packet's next hop is NOT a CE device attached to this same PE, the packet's "BGP Next Hop" is found, as well as the label which that BGP next hop assigned for the packet's destination address. This label is pushed onto the packet's label stack, and becomes the bottom label. Then the PE looks up the IGP route to the BGP Next Hop, and thus determines the IGP next hop, as well as the label assigned to the address of the BGP next hop by the IGP next hop. This label gets pushed on as the packet's top label, and the packet is then forwarded Rosen, et al. [Page 19] Internet Draft draft-rosen-rfc2547bis-00.txt March 2000 to the IGP next hop. (If the BGP next hop is the same as the IGP next hop, the second label may not need to be pushed on, however.) At this point, MPLS will carry the packet across the backbone. The egress PE router's treatment of the packet will depend on the label that was first pushed on by the ingress PE. In many cases, the PE will be able to determine, from this label, the interface over which the packet should be transmitted (to a CE device), as well as the proper data link layer header for that interface. In other cases, the PE may only be able to determine that the packet's destination address needs to be looked up in a particular VRF before being forwarded to a CE device. Information in the MPLS header itself, and/or information associated with the label, may also be used to provide QoS on the interface to the CE. In any event, when the packet finally gets to a CE device, it will again be an ordinary unlabeled IP packet. Note that it is the two-level labeling that makes it possible to keep all the VPN routes out of the P routers, and this in turn is crucial to ensuring the scalability of the model. The backbone does not even need to have routes to the CEs, only to the PEs. To maintain proper isolation of one VPN from another, it is important that no router in the backbone accept a labeled packet from any adjacent non-backbone device unless (a) the label at the top of the label stack was actually distributed by the backbone router to the non-backbone device, and (b) the backbone router can determine that use of that label will cause the packet to leave the backbone before any labels lower in the stack will be inspected, and before the IP header will be inspected. These restrictions are necessary in order to prevent packets from entering a VPN where they do not belong. 6. How PEs Learn Routes from CEs The PE routers which attach to a particular VPN need to know, for each of that VPN's sites, which addresses in that VPN are at each site. In the case where the CE device is a host or a switch, this set of addresses will generally be configured into the PE router attaching to that device. In the case where the CE device is a router, there are a number of possible ways that a PE router can obtain this set of addresses. The PE translates these addresses into VPN-IPv4 addresses, using a configured RD. The PE then treats these VPN-IPv4 routes as input to BGP. In no case will routes from a site ever be leaked into the Rosen, et al. [Page 20] Internet Draft draft-rosen-rfc2547bis-00.txt March 2000 backbone's IGP. Exactly which PE/CE route distribution techniques are possible depends on whether a particular CE is in a "transit VPN" or not. A "transit VPN" is one which contains a router that receives routes from a "third party" (i.e., from a router which is not in the VPN, but is not a PE router), and that redistributes those routes to a PE router. A VPN which is not a transit VPN is a "stub VPN". The vast majority of VPNs, including just about all corporate enterprise networks, would be expected to be "stubs" in this sense. The possible PE/CE distribution techniques are: 1. Static routing (i.e., configuration) may be used. (This is likely to be useful only in stub VPNs.) 2. PE and CE routers may be RIP peers, and the CE may use RIP to tell the PE router the set of address prefixes which are reachable at the CE router's site. When RIP is configured in the CE, care must be taken to ensure that address prefixes from other sites (i.e., address prefixes learned by the CE router from the PE router) are never advertised to the PE. More precisely: if a PE router, say PE1, receives a VPN-IPv4 route R1, and as a result distributes an IPv4 route R2 to a CE, then R2 must not be distributed back from that CE's site to a PE router, say PE2, (where PE1 and PE2 may be the same router or different routers), unless PE2 maps R2 to a VPN-IPv4 route which is different than (i.e., contains a different RD than) R1. 3. The PE and CE routers may be OSPF peers. A PE router which is an OSPF peer of a CE router appears, to the CE router, to be an area 0 router. If a PE router is an OSPF peer of CE routers which are in distinct VPNs, the PE must of course be running multiple instances of OSPF. IPv4 routes which the PE learns from the CE via OSPF are redistributed into BGP as VPN-IPv4 routes. Extended community attributes are used to carry, along with the route, all the information needed to enable the route to be distributed to other CE routers in the VPN in the proper type of OSPF LSA. OSPF route tagging is used to ensure that routes received from the MPLS/BGP backbone are not sent back into the backbone. 4. The PE and CE routers may be BGP peers, and the CE router may use BGP (in particular, EBGP to tell the PE router the set of address prefixes which are at the CE router's site. (This technique can be used in stub VPNs or transit VPNs.) Rosen, et al. [Page 21] Internet Draft draft-rosen-rfc2547bis-00.txt March 2000 From a purely technical perspective, this is by far the best technique: a) Unlike the IGP alternatives, this does not require the PE to run multiple routing algorithm instances in order to talk to multiple CEs b) BGP is explicitly designed for just this function: passing routing information between systems run by different administrations c) If the site contains "BGP backdoors", i.e., routers with BGP connections to routers other than PE routers, this procedure will work correctly in all circumstances. The other procedures may or may not work, depending on the precise circumstances. d) Use of BGP makes it easy for the CE to pass attributes of the routes to the PE. For example, the CE may suggest a particular Target for each route, from among the Target attributes that the PE is authorized to attach to the route. On the other hand, using BGP is likely to be something new for the CE administrators, except in the case where the customer itself is already an Internet Service Provider (ISP). If a site is not in a transit VPN, note that it need not have a unique Autonomous System Number (ASN). Every CE whose site which is not in a transit VPN can use the same ASN. This can be chosen from the private ASN space, and it will be stripped out by the PE. Routing loops are prevented by use of the Site of Origin Attribute (see below). What if a set of sites constitute a transit VPN? This will generally be the case only if the VPN is itself an ISP's network, where the ISP is itself buying backbone services from another SP. The latter SP may be called a "Carrier's Carrier". In this case, the best way to provide the VPN is to have the CE routers support MPLS, and to use the technique described in section 8. When we do not need to distinguish among the different ways in which a PE can be informed of the address prefixes which exist at a given site, we will simply say that the PE has "learned" the routes from that site. Rosen, et al. [Page 22] Internet Draft draft-rosen-rfc2547bis-00.txt March 2000 Before a PE can redistribute a VPN-IPv4 route learned from a site, it must assign a Route Target attribute (see section 4.2.1) to the route, and it may assign a Site of Origin attribute to the route. The Site of Origin attribute, if used, is encoded as a Route Origin Extended Community [BGP-EXTCOMM]. The purpose of this attribute is to uniquely identify the set of routes learned from a particular site. This attribute is needed in some cases to ensure that a route learned from a particular site via a particular PE/CE connection is not distributed back to the site through a different PE/CE connection. It is particularly useful if BGP is being used as the PE/CE protocol, but different sites have not been assigned distinct ASNs. 7. How CEs learn Routes from PEs In this section, we assume that the CE device is a router. If the PE places a particular route in the VRF which is uses to route packets received from a particular CE, then in general, the PE may distribute that route to the CE. Of course the PE may distribute that route to the CE only if this is permitted by the rules of the PE/CE protocol. (For example, if a particular PE/CE protocol has "split horizon", certain routes in the VRF cannot be redistributed back to the CE.) We add one more restriction on the distribution of routes from PE to CE: if a route's Site of Origin attribute identifies a particular site, that route must never be redistributed to any CE at that site. In most cases, however, it will be sufficient for the PE to simply distribute the default route to the CE. (In some cases, it may even be sufficient for the CE to be configured with a default route pointing to the PE.) This will generally work at any site which does not itself need to distribute the default route to other sites. (E.g., if one site in a corporate VPN has the corporation's access to the Internet, that site might need to have default distributed to the other site, but one could not distribute default to that site itself.) Whatever procedure is used to distribute routes from CE to PE will also be used to distribute routes from PE to CE. Rosen, et al. [Page 23] Internet Draft draft-rosen-rfc2547bis-00.txt March 2000 8. Carriers' Carriers Sometimes a VPN may actually be the network of an ISP, with its own peering and routing policies. Sometimes a VPN may be the network of an SP which is offering VPN services in turn to its own customers. VPNs like these can also obtain backbone service from another SP, the "carrier's carrier", using essentially the same methods described in this document. In particular: - The CE routers should distribute to the PE routers only those routes which are internal to the VPN. This allows the VPN to be handled as a stub VPN. - The CE routers should support MPLS, and should distribute to the PE routers labels for the internal routes that they distribute to the PEs. - The PE routers should distribute, to the CE routers, labels for the routes they distribute to the CE routers. - Routers at the different sites should establish BGP connections among themselves for the purpose of exchanging external routes. - All the external routes must be known to the CE routers. Then when a CE router looks up a packet's destination address, the routing lookup will resolve to an internal address, usually the address of the packet's BGP next hop. The CE labels the packet appropriately and sends the packet to the PE. Note that the CE router itself need not know all the external routes if the other routers at the site also support MPLS. All that is necessary is that MPLS labels can be pushed onto IP packets by the routes which do know the external routes, and that MPLS can be used to move the packets from those routers to the PE router. 9. Security Under the following conditions: a) labeled packets are not accepted by backbone routers from untrusted or unreliable sources, unless it is known that such packets will leave the backbone before the IP header or any labels lower in the stack will be inspected, and Rosen, et al. [Page 24] Internet Draft draft-rosen-rfc2547bis-00.txt March 2000 b) labeled VPN-IPv4 routes are not accepted from untrusted or unreliable sources, the security provided by this architecture is virtually identical to that provided to VPNs by Frame Relay or ATM backbones. It is worth noting that the use of MPLS makes it much simpler to provide this level of security than would be possible if one attempted to use some form of IP-within-IP tunneling in place of MPLS. It is a simple matter to refuse to accept a labeled packet unless the first of the above conditions applies to it. It is rather more difficult to configure a router to refuse to accept an IP packet if that packet is an IP-within-IP tunnelled packet which is going to a "wrong" place. The use of MPLS also allows a VPN to span multiple SPs without depending in any way on the inter-domain distribution of IPv4 routing information. 10. Quality of Service Although not the focus of this paper, Quality of Service is a key component of any VPN service. In MPLS/BGP VPNs, existing L3 QoS capabilities can be applied to labeled packets through the use of the "experimental" bits in the shim header [MPLS-ENCAPS], or, where ATM is used as the backbone, through the use of ATM QoS capabilities. The traffic engineering work discussed in [MPLS-RSVP] is also directly applicable to MPLS/BGP VPNs. Traffic engineering could even be used to establish label switched paths with particular QoS characteristics between particular pairs of sites, if that is desirable. Where an MPLS/BGP VPN spans multiple SPs, the architecture described in [PASTE] may be useful. An SP may apply either intserv or diffserv capabilities to a particular VPN, as appropriate. 11. Scalability We have discussed scalability issues throughout this paper. In this section, we briefly summarize the main characteristics of our model with respect to scalability. The Service Provider backbone network consists of (a) PE routers, (b) BGP Route Reflectors, (c) P routers (which are neither PE routers nor Route Reflectors), and, in the case of multi-provider VPNs, (d) ASBRs. Rosen, et al. [Page 25] Internet Draft draft-rosen-rfc2547bis-00.txt March 2000 P routers do not maintain any VPN routes. In order to properly forward VPN traffic, the P routers need only maintain routes to the PE routers and the ASBRs. The use of two levels of labeling is what makes it possible to keep the VPN routes out of the P routers. A PE router maintains VPN routes, but only for those VPNs to which it is directly attached. Route reflectors and ASBRs can be partitioned among VPNs so that each partition carries routes for only a subset of the VPNs provided by the Service Provider. Thus no single Route Reflector or ASBR is required to maintain routes for all the VPNs. As a result, no single component within the Service Provider network has to maintain all the routes for all the VPNs. So the total capacity of the network to support increasing numbers of VPNs is not limited by the capacity of any individual component. 12. Intellectual Property Considerations Cisco Systems may seek patent or other intellectual property protection for some of all of the technologies disclosed in this document. If any standards arising from this document are or become protected by one or more patents assigned to Cisco Systems, Cisco intends to disclose those patents and license them on reasonable and non-discriminatory terms. 13. Acknowledgments Significant contributions to this work have been made by Ravi Chandra, Dan Tappan and Bob Thomas. 14. Authors' Addresses Eric C. Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 E-mail: erosen@cisco.com Rosen, et al. [Page 26] Internet Draft draft-rosen-rfc2547bis-00.txt March 2000 Yakov Rekhter Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134 E-mail: yakov@cisco.com Stephen John Brannon Swisscom AG Postfach 1570 CH-8301 Glattzentrum (Zuerich), Switzerland E-mail: stephen.brannon@swisscom.com Marco Carugi France Telecom / CNET Research Centre IP networks and services CNET/DAC/NTR Technopole Anticipa 2, av. P. Marzin 22307 Lannion E-mail: marco.carugi@cnet.francetelecom.fr Christopher J. Chase AT&T 200 Laurel Ave Middletown, NJ 07748 USA E-mail: chase@att.com Eric Dean Global One 12490 Sunrise Valley Dr. Reston, VA 20170 USA E-mail: edean@gip.net Paul Hitchin BT BT Adastral Park Martlesham Heath, Ipswich IP5 3RE UK E-mail: paul.hitchen@bt.com Rosen, et al. [Page 27] Internet Draft draft-rosen-rfc2547bis-00.txt March 2000 Manoj Leelanivas Juniper Networks, Inc. 385 Ravendale Drive Mountain View, CA 94043 USA E-mail: manoj@juniper.net Luca Martini Level 3 Communications, LLC. 1025 Eldorado Blvd. Broomfield, CO, 80021 E-mail: luca@level3.net Monique Jeanne Morrow Swisscom AG Postfach 1570 CH-8301 Glattzentrum (Zuerich), Switzerland E-mail: monique.morrow@swisscom.com Adrian Smith BT BT Adastral Park Martlesham Heath, Ipswich IP5 3RE UK E-mail: adrian.ca.smith@bt.com Vijay Srinivasan Ericsson IP Infrastructure 920 Main Campus Drive, Suite 500 Raleigh, NC 27606 E-mail: vijay@torrentnet.com Alain Vedrenne SITA EQUANT 3100 Cumberland Blvd, Suite 200 Atlanta, GA, 30339 USA Email:Alain.Vedrenne@sita.int Alain.Vedrenne@equant.com Rosen, et al. [Page 28] Internet Draft draft-rosen-rfc2547bis-00.txt March 2000 15. References [BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol Extensions for BGP4", February 1998, RFC 2283 [BGP-EXTCOMM] Ramachandra, Tappan, "BGP Extended Communities Attribute", February 2000, work in progress [BGP-ORF] Chen, Rekhter, "Cooperative Route Filtering Capability for BGP-4", February 2000, work in progress [BGP-RFSH] Chen, "Route Refresh Capability for BGP-4", December, 1999, work in progress [BGP-RR] Bates and Chandrasekaran, "BGP Route Reflection: An alternative to full mesh IBGP", RFC 1966, June 1996 [IPSEC] Kent and Atkinson, "Security Architecture for the Internet Protocol", November 1998, RFC 2401 [MPLS-ARCH] Rosen, Viswanathan, and Callon, "Multiprotocol Label Switching Architecture", August 1999, work in progress [MPLS-BGP] Rekhter and Rosen, "Carrying Label Information in BGP4", January 2000, work in progress [MPLS-LDP] Andersson, Doolan, Feldman, Fredette, Thomas, "LDP Specification", October 1999, work in progress [MPLS-ENCAPS] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and Conta, "MPLS Label Stack Encoding", September 1999, work in progress [MPLS-RSVP] Awduche, Gan, Li, Swallow, and Srinavasan, "Extensions to RSVP for LSP Tunnels", September, 1999, work in progress [PASTE] Li and Rekhter, "A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)", RFC 2430, October 1998. 16. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are Rosen, et al. [Page 29] Internet Draft draft-rosen-rfc2547bis-00.txt March 2000 included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Rosen, et al. [Page 30]