doc: Add RFC documents

1 files changed, 2635 insertions, 0 deletions

diff --git a/doc/rfc/rfc4364.txt b/doc/rfc/rfc4364.txt
new file mode 100644
index 0000000..a7ecd5b
--- /dev/null
+++ b/doc/rfc/rfc4364.txt
@@ -0,0 +1,2635 @@
+
+
+
+
+
+
+Network Working Group                                           E. Rosen
+Request for Comments: 4364                           Cisco Systems, Inc.
+Obsoletes: 2547                                               Y. Rekhter
+Category: Standards Track                         Juniper Networks, Inc.
+                                                           February 2006
+
+
+              BGP/MPLS IP Virtual Private Networks (VPNs)
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes a method by which a Service Provider may use
+   an IP backbone to provide IP Virtual Private Networks (VPNs) for its
+   customers.  This method uses a "peer model", in which the customers'
+   edge routers (CE routers) send their routes to the Service Provider's
+   edge routers (PE routers); there is no "overlay" visible to the
+   customer's routing algorithm, and CE routers at different sites do
+   not peer with each other.  Data packets are tunneled through the
+   backbone, so that the core routers do not need to know the VPN
+   routes.
+
+   This document obsoletes RFC 2547.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosen & Rekhter             Standards Track                     [Page 1]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Virtual Private Networks ...................................4
+      1.2. Customer Edge and Provider Edge ............................5
+      1.3. VPNs with Overlapping Address Spaces .......................6
+      1.4. VPNs with Different Routes to the Same System ..............7
+      1.5. SP Backbone Routers ........................................7
+      1.6. Security ...................................................8
+   2. Sites and CEs ...................................................8
+   3. VRFs: Multiple Forwarding Tables in PEs .........................9
+      3.1. VRFs and Attachment Circuits ...............................9
+      3.2. Associating IP Packets with VRFs ..........................10
+      3.3. Populating the VRFs .......................................11
+   4. VPN Route Distribution via BGP .................................12
+      4.1. The VPN-IPv4 Address Family ...............................13
+      4.2. Encoding of Route Distinguishers ..........................14
+      4.3. Controlling Route Distribution ............................15
+           4.3.1. The Route Target Attribute .........................15
+           4.3.2. Route Distribution Among PEs by BGP ................17
+           4.3.3. Use of Route Reflectors ............................20
+           4.3.4. How VPN-IPv4 NLRI Is Carried in BGP ................22
+           4.3.5. Building VPNs Using Route Targets ..................23
+           4.3.6. Route Distribution Among VRFs in a Single PE .......23
+   5. Forwarding .....................................................23
+   6. Maintaining Proper Isolation of VPNs ...........................26
+   7. How PEs Learn Routes from CEs ..................................27
+   8. How CEs Learn Routes from PEs ..................................30
+   9. Carriers' Carriers .............................................30
+   10. Multi-AS Backbones ............................................32
+   11. Accessing the Internet from a VPN .............................34
+   12. Management VPNs ...............................................36
+   13. Security Considerations .......................................37
+      13.1. Data Plane ...............................................37
+      13.2. Control Plane ............................................39
+      13.3. Security of P and PE Devices .............................39
+   14. Quality of Service ............................................39
+   15. Scalability ...................................................40
+   16. IANA Considerations ...........................................40
+   17. Acknowledgements ..............................................41
+   18. Contributors ..................................................41
+   19. Normative References ..........................................44
+   20. Informative References ........................................45
+
+
+
+
+
+
+
+
+Rosen & Rekhter             Standards Track                     [Page 2]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+1.  Introduction
+
+   This document describes a method by which a Service Provider may use
+   an IP backbone to provide IP Virtual Private Networks (VPNs) for its
+   customers.  This method uses a "peer model", in which the customers'
+   edge routers (CE routers) send their routes to the Service Provider's
+   edge routers (PE routers).  Border Gateway Protocol (BGP)
+   [BGP, BGP-MP] is then used by the Service Provider to exchange the
+   routes of a particular VPN among the PE routers that are attached to
+   that VPN.  This is done in a way that ensures that routes from
+   different VPNs remain distinct and separate, even if two VPNs have an
+   overlapping address space.  The PE routers distribute, to the CE
+   routers in a particular VPN, the routes from other the CE routers in
+   that VPN.  The CE routers do not peer with each other, hence there is
+   no "overlay" visible to the VPN's routing algorithm.  The term "IP"
+   in "IP VPN" is used to indicate that the PE receives IP datagrams
+   from the CE, examines their IP headers, and routes them accordingly.
+
+   Each route within a VPN is assigned a Multiprotocol Label Switching
+   (MPLS) [MPLS-ARCH, MPLS-BGP, MPLS-ENCAPS] label; when BGP distributes
+   a VPN route, it also distributes an MPLS label for that route.
+   Before a customer data packet travels across the Service Provider's
+   backbone, it is encapsulated with the MPLS label that corresponds, in
+   the customer's VPN, to the route that is the best match to the
+   packet's destination address.  This MPLS packet is further
+   encapsulated (e.g., with another MPLS label or with an IP or Generic
+   Routing Encapsulation (GRE) tunnel header [MPLS-in-IP-GRE]) so that
+   it gets tunneled across the backbone to the proper PE router.  Thus,
+   the backbone core routers do not need to know the VPN routes.
+
+   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 that need an
+   extranet, an Internet Service Provider, an application service
+   provider, another VPN Service Provider that uses this same method to
+   offer VPNs to clients of its own, 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.
+
+
+
+
+
+
+
+
+
+
+
+Rosen & Rekhter             Standards Track                     [Page 3]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+1.1.  Virtual Private Networks
+
+   Consider a set of "sites" that are attached to a common network that
+   we call "the backbone".  Now apply some policy to create a number of
+   subsets of that set, and impose the following rule: two sites may
+   have IP interconnectivity over that backbone only if at least one of
+   these subsets contains them both.
+
+   These subsets are Virtual Private Networks (VPNs).  Two sites have IP
+   connectivity over the common backbone only if there is some VPN that
+   contains them both.  Two sites that 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
+   may be thought of as a corporate "intranet".  If the various sites in
+   a VPN are owned by different enterprises, the VPN may be thought of
+   as an "extranet".  A site can be in more than one VPN; e.g., in an
+   intranet and in several extranets.  In general, when we use the term
+   "VPN" we will not be distinguishing between intranets and extranets.
+
+   We refer to the owners of the sites as the "customers".  We refer to
+   the owners/operators of the backbone as the "Service Providers"
+   (SPs).  The customers obtain "VPN service" from the SPs.
+
+   A customer may be a single enterprise, a set of enterprises, an
+   Internet Service Provider, an Application Service Provider, another
+   SP that offers the same kind of VPN service to its own customers,
+   etc.
+
+   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 share with the
+   SP the responsibility for implementing these policies.  This document
+   specifies mechanisms that can 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, one can
+   allow every site to have a direct route to every other site ("full
+   mesh").  Alternatively, one can force traffic between certain pairs
+   of sites to be routed via a third site.  This can be useful, e.g., if
+   it is desired that traffic between a pair of sites be passed through
+   a firewall, and the firewall is located at the third site.
+
+
+
+
+Rosen & Rekhter             Standards Track                     [Page 4]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+   In this document, we restrict our discussion to the case in which the
+   customer is explicitly purchasing VPN service from an SP, or from a
+   set of SPs that have agreed to cooperate to provide the VPN service.
+   That is, the customer is not merely purchasing internet access from
+   an SP, and the VPN traffic does not pass through a random collection
+   of interconnected SP networks.
+
+   We also restrict our discussion to the case in which the backbone
+   provides an IP service to the customer, rather than, e.g., a layer 2
+   service such as Frame Relay, Asynchronous Transfer Mode (ATM),
+   ethernet, High Level Data Link Control (HDLC), or Point-to-Point
+   Protocol (PPP).  The customer may attach to the backbone via one of
+   these (or other) layer 2 services, but the layer 2 service is
+   terminated at the "edge" of the backbone, where the customer's IP
+   datagrams are removed from any layer 2 encapsulation.
+
+   In the rest of this introduction, we specify some properties that
+   VPNs should have.  The remainder of this document specifies a set of
+   mechanisms that can be deployed to provide a VPN model that has all
+   these properties.  This section also introduces some of the technical
+   terminology used in the remainder of the document.
+
+1.2.  Customer Edge and Provider Edge
+
+   Routers can be attached to each other, or to end systems, in a
+   variety of different ways: PPP connections, ATM Virtual Circuits
+   (VCs), Frame Relay VCs, ethernet interfaces, Virtual Local Area
+   Networks (VLANs) on ethernet interfaces, GRE tunnels, Layer 2
+   Tunneling Protocol (L2TP) tunnels, IPsec tunnels, etc.  We will use
+   the term "attachment circuit" to refer generally to some such means
+   of attaching to a router.  An attachment circuit may be the sort of
+   connection that is usually thought of as a "data link", or it may be
+   a tunnel of some sort; what matters is that it be possible for two
+   devices to be network layer peers over the attachment circuit.
+
+   Each VPN site must contain one or more Customer Edge (CE) devices.
+   Each CE device is attached, via some sort of attachment circuit, to
+   one or more Provider Edge (PE) routers.
+
+   Routers in the SP's network that do not attach to CE devices are
+   known as "P routers".
+
+   CE devices can be hosts or routers.  In a typical case, a site
+   contains one or more routers, some of which are attached to PE
+   routers.  The site routers that attach to the PE routers would then
+   be the CE devices, or "CE routers".  However, there is nothing to
+   prevent a non-routing host from attaching directly to a PE router, in
+   which case the host would be a CE device.
+
+
+
+Rosen & Rekhter             Standards Track                     [Page 5]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+   Sometimes, what is physically attached to a PE router is a layer 2
+   switch.  In this case, we do NOT say that the layer 2 switch is a CE
+   device.  Rather, the CE devices are the hosts and routers that
+   communicate with the PE router through the layer 2 switch; the layer
+   2 infrastructure is transparent.  If the layer 2 infrastructure
+   provides a multipoint service, then multiple CE devices can be
+   attached to the PE router over the same attachment circuit.
+
+   CE devices are logically part of a customer's VPN.  PE and P routers
+   are logically part of the SP's network.
+
+   The attachment circuit over which a packet travels when going from CE
+   to PE is known as that packet's "ingress attachment circuit", and the
+   PE as the packet's "ingress PE".  The attachment circuit over which a
+   packet travels when going from PE to CE is known as that packet's
+   "egress attachment circuit", and the PE as the packet's "egress PE".
+
+   We will say that a PE router is attached to a particular VPN if it is
+   attached to a CE device that is in a site of that VPN.  Similarly, we
+   will say that a PE router is attached to a particular site if it is
+   attached to a CE device that 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 it 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, the customer has no
+   backbone or "virtual backbone" to manage, and does not have to deal
+   with any inter-site routing issues.  In other words, in the scheme
+   described in this document, a VPN is NOT an "overlay" on top of the
+   SP's network.
+
+   With respect to the management of the edge devices, clear
+   administrative boundaries are maintained between the SP and its
+   customers.  Customers are not required to access the PE or P routers
+   for management purposes, nor is the SP required to access the CE
+   devices for management purposes.
+
+1.3.  VPNs with Overlapping Address Spaces
+
+   If two VPNs have no sites in common, then they may have overlapping
+   address spaces.  That is, a given address might be used in VPN V1 as
+   the address of system S1, but in VPN V2 as the address of a
+   completely different system S2.  This is a common situation when the
+   VPNs each use an RFC 1918 private address space.  Of course, within
+   each VPN, each address must be unambiguous.
+
+
+
+
+
+Rosen & Rekhter             Standards Track                     [Page 6]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+   Even two VPNs that do have sites in common may have overlapping
+   address spaces, as long as there is no need for any communication
+   between systems with such addresses and systems in the common sites.
+
+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.
+
+   It is 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.
+
+1.5.  SP Backbone Routers
+
+   The SP's backbone consists of the PE routers, as well as other
+   routers ("P routers") that 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, there would be
+   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 only needs to be present
+   in the PE routers that attach to that VPN.  In particular, the P
+   routers do 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 not considered further in
+   this paper, but is examined in [VPN-MCAST].)
+
+   So just as the VPN owners do not have a backbone or "virtual
+   backbone" to administer, the SPs themselves do not have a separate
+   backbone or "virtual backbone" to administer 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.
+
+
+
+
+Rosen & Rekhter             Standards Track                     [Page 7]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+   Section 10 discusses some of the special issues that arise when the
+   backbone spans several Service Providers.
+
+1.6.  Security
+
+   VPNs of the sort being discussed here, even without making use of
+   cryptographic security measures, are intended to provide a level of
+   security equivalent to that obtainable when a layer 2 backbone (e.g.,
+   Frame Relay) is used.  That is, in the absence of misconfiguration or
+   deliberate interconnection of different VPNs, it is not possible for
+   systems in one VPN to gain access to systems in another VPN.  Of
+   course, the methods described herein do not by themselves encrypt the
+   data for privacy, nor do they provide a way to determine whether data
+   has been tampered with en route.  If this is desired, cryptographic
+   measures must be applied in addition. (See, e.g., [MPLS/BGP-IPsec].)
+   Security is discussed in more detail in Section 13.
+
+2.  Sites and CEs
+
+   From the perspective of a particular backbone network, a set of IP
+   systems may be regarded as a "site" if those systems have mutual IP
+   interconnectivity that doesn't require use of the backbone.  In
+   general, a site will consist of a set of systems that are in
+   geographic proximity.  However, this is not universally true.  If two
+   geographic locations are connected via a leased line, over which Open
+   Shortest Path First (OSPF) protocol [OSPFv2] 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.  (This notion of "site" is
+   topological, rather than geographical.  If the leased line goes down,
+   or otherwise ceases to be the preferred route, but the two geographic
+   locations can continue to communicate by using the VPN backbone, then
+   one site has become two.)
+
+   A CE device is always regarded as being in a single site (though as
+   we shall see in Section 3.2, a site may consist of multiple "virtual
+   sites").  A site, however, may belong to multiple VPNs.
+
+   A PE router may attach to CE devices from 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 we speak mostly of "sites" as being the basic unit of
+   interconnection, nothing here prevents a finer degree of granularity
+   in the control of interconnectivity.  For example, certain systems at
+
+
+
+Rosen & Rekhter             Standards Track                     [Page 8]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+   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.  However, this
+   might require that the site have two attachment circuits to the
+   backbone, one for the intranet and one for the extranet; it might
+   further require that firewall functionality be applied on the
+   extranet attachment circuit.
+
+3.  VRFs: Multiple Forwarding Tables in PEs
+
+   Each PE router maintains a number of separate forwarding tables.  One
+   of the forwarding tables is the "default forwarding table".  The
+   others are "VPN Routing and Forwarding tables", or "VRFs".
+
+3.1.  VRFs and Attachment Circuits
+
+   Every PE/CE attachment circuit is associated, by configuration, with
+   one or more VRFs.  An attachment circuit that is associated with a
+   VRF is known as a "VRF attachment circuit".
+
+   In the simplest case and most typical case, a PE/CE attachment
+   circuit is associated with exactly one VRF.  When an IP packet is
+   received over a particular attachment circuit, its destination IP
+   address is looked up in the associated VRF.  The result of that
+   lookup determines how to route the packet.  The VRF used by a
+   packet's ingress PE for routing a particular packet is known as the
+   packet's "ingress VRF".  (There is also the notion of a packet's
+   "egress VRF", located at the packet's egress PE; this is discussed in
+   Section 5.)
+
+   If an IP packet arrives over an attachment circuit that is not
+   associated with any VRF, the packet's destination address is looked
+   up in the default forwarding table, and the packet is routed
+   accordingly.  Packets forwarded according to the default forwarding
+   table include packets from neighboring P or PE routers, as well as
+   packets from customer-facing attachment circuits that have not been
+   associated with VRFs.
+
+   Intuitively, one can think of the default forwarding table as
+   containing "public routes", and of the VRFs as containing "private
+   routes".  One can similarly think of VRF attachment circuits as being
+   "private", and of non-VRF attachment circuits as being "public".
+
+   If a particular VRF attachment circuit connects site S to a PE
+   router, then connectivity from S (via that attachment circuit) can be
+   restricted by controlling the set of routes that gets entered in the
+   corresponding VRF.  The set of routes in that VRF should be limited
+   to the set of routes leading to sites that have at least one VPN in
+
+
+
+Rosen & Rekhter             Standards Track                     [Page 9]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+   common with S.  Then a packet sent from S over a VRF attachment
+   circuit can only be routed by the PE to another site S' if S' is in
+   one of the same VPNs as S.  That is, communication (via PE routers)
+   is prevented between any pair of VPN sites that have no VPN in
+   common.  Communication between VPN sites and non-VPN sites is
+   prevented by keeping the routes to the VPN sites out of the default
+   forwarding table.
+
+   If there are multiple attachment circuits leading from S to one or
+   more PE routers, then there might be multiple VRFs that could be used
+   to route traffic from S.  To properly restrict S's connectivity, the
+   same set of routes would have to exist in all the VRFs.
+   Alternatively, one could impose different connectivity restrictions
+   over different attachment circuit from S.  In that case, some of the
+   VRFs associated with attachment circuits from S would contain
+   different sets of routes than some of the others.
+
+   We allow the case in which a single attachment circuit is associated
+   with a set of VRFs, rather than with a single VRF.  This can be
+   useful if it is desired to divide a single VPN into several
+   "sub-VPNs", each with different connectivity restrictions, where some
+   characteristic of the customer packets is used to select from among
+   the sub-VPNs.  For simplicity though, we will usually speak of an
+   attachment circuit as being associated with a single VRF.
+
+3.2.  Associating IP Packets with VRFs
+
+   When a PE router receives a packet from a CE device, it must
+   determine the attachment circuit over which the packet arrived, as
+   this determines in turn the VRF (or set of VRFs) that can be used for
+   forwarding that packet.  In general, to determine the attachment
+   circuit over which a packet arrived, a PE router takes note of the
+   physical interface over which the packet arrived, and possibly also
+   takes note of some aspect of the packet's layer 2 header.  For
+   example, if a packet's ingress attachment circuit is a Frame Relay
+   VC, the identity of the attachment circuit can be determined from the
+   physical Frame Relay interface over which the packet arrived,
+   together with the Data Link Connection Identifier (DLCI) field in the
+   packet's Frame Relay header.
+
+   Although the PE's conclusion that a particular packet arrived on a
+   particular attachment circuit may be partially determined by the
+   packet's layer 2 header, it must be impossible for a customer, by
+   writing the header fields, to fool the SP into thinking that a packet
+   that was received over one attachment circuit really arrived over a
+   different one.  In the example above, although the attachment circuit
+   is determined partially by inspection of the DLCI field in the Frame
+   Relay header, this field cannot be set freely by the customer.
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 10]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+   Rather, it must be set to a value specified by the SP, or else the
+   packet cannot arrive at the PE router.
+
+   In some cases, a particular site may be divided by the customer into
+   several "virtual sites".  The SP may designate a particular set of
+   VRFs to be used for routing packets from that site and may allow the
+   customer to set some characteristic of the packet, which is then used
+   for choosing a particular VRF from the set.
+
+   For example, each virtual site might be realized as a VLAN.  The SP
+   and the customer could agree that on packets arriving from a
+   particular CE, certain VLAN values would be used to identify certain
+   VRFs.  Of course, packets from that CE would be discarded by the PE
+   if they carry VLAN tag values that are not in the agreed-upon set.
+   Another way to accomplish this is to use IP source addresses.  In
+   this case, the PE uses the IP source address in a packet received
+   from the CE, along with the interface over which the packet is
+   received, to assign the packet to a particular VRF.  Again, the
+   customer would only be able to select from among the particular set
+   of VRFs that that customer is allowed to use.
+
+   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, or out
+   different network interfaces.
+
+3.3. Populating the VRFs
+
+   With what set of routes 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 that 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 that it has learned from CE1.  PE2 and PE3 use
+   these routes to populate the VRFs that they associate, respectively,
+   with the sites of CE2 and CE3.  Routes from sites that are not in VPN
+   V do not appear in these VRFs, which means that packets from CE2 or
+   CE3 cannot be sent to sites that are not in VPN V.
+
+   When we speak of a PE "learning" routes from a CE, we are not
+   presupposing any particular learning technique.  The PE may learn
+   routes by means of a dynamic routing algorithm, but it may also
+   "learn" routes by having those routes configured (i.e., static
+   routing).  (In this case, to say that the PE "learned" the routes
+   from the CE is perhaps to exercise a bit of poetic license.)
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 11]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+   PEs also need to learn, from other PEs, the routes that belong to a
+   given VPN.  The procedures to be used for populating the VRFs with
+   the proper sets of routes are specified in Section 4.
+
+   If there are multiple attachment circuits leading from a particular
+   PE router to a particular site, they might all be mapped to the same
+   forwarding table.  But if policy dictates, they could be mapped to
+   different forwarding tables.  For instance, the policy might be that
+   a particular attachment circuit from a site is used only for intranet
+   traffic, while another attachment circuit from that site is used only
+   for extranet traffic.  (Perhaps, e.g., the CE attached to the
+   extranet attachment circuit is a firewall, while the CE attached to
+   the intranet attachment circuit is not.)  In this case, the two
+   attachment circuits would be associated with different VRFs.
+
+   Note that if two attachment circuits are associated with the same
+   VRF, then packets that the PE receives over one of them will be able
+   to reach exactly the same set of destinations as packets that the PE
+   receives over the other.  So two attachment circuits cannot be
+   associated with the same VRF unless each CE is in the exact same set
+   of VPNs as is the other.
+
+   If an attachment circuit leads to a site which is in multiple VPNs,
+   the attachment circuit may still associated with a single VRF, in
+   which case the VRF will contain routes from the full set of VPNs of
+   which the site is a member.
+
+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.
+
+
+
+
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 12]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+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 several 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 several
+   different VPNs, it is possible for BGP to carry several completely
+   different routes to that address, one for each VPN.
+
+   Since VPN-IPv4 addresses and IPv4 addresses are different address
+   families, BGP never treats them as comparable addresses.
+
+   An RD is simply a number, and it does not contain any inherent
+   information; it does not identify the origin of the route or 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.3).
+
+   The RD can also be used to create multiple different routes to the
+   very same system.  We have already discussed a situation in which the
+   route to a particular server should 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.3.5) to
+   decide which packets use which route.
+
+   The RDs are structured so that every Service Provider can administer
+   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 three fields: a 2-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 that 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 that ASN belongs (having been
+   assigned to that SP by the appropriate authority).
+
+   RDs are given this structure in order to ensure that an SP that
+   provides VPN backbone service can always create a unique RD when it
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 13]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+   needs to do so.  However, the structure is not meaningful to BGP;
+   when BGP compares two such address prefixes, it ignores the structure
+   entirely.
+
+   A PE needs to be configured such that routes that lead to a
+   particular CE become associated with a particular RD.  The
+   configuration may cause all routes leading to the same CE to be
+   associated with the same RD, or it may cause different routes to be
+   associated 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, three values of the type field are
+   defined: 0, 1, and 2.
+
+     - 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 the appropriate authority (use of ASN values
+       from the private ASN space is strongly discouraged).  The
+       Assigned Number subfield contains a number from a numbering space
+       that is administered by the enterprise to which the ASN has been
+       assigned by an appropriate authority.
+
+     - 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 is from the public IP address space, it must have been
+       assigned by an appropriate authority (use of addresses from the
+       private IP address space is strongly discouraged).  The Assigned
+       Number subfield contains a number from a numbering space which is
+       administered by the enterprise to which the IP address has been
+       assigned.
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 14]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+     - Type 2: The Value field consists of two subfields:
+
+         * Administrator subfield: 4 bytes
+         * Assigned Number subfield: 2 bytes
+
+       The Administrator subfield must contain a 4-byte Autonomous
+       System number [BGP-AS4].  If this ASN is from the public ASN
+       space, it must have been assigned by the appropriate authority
+       (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 an appropriate authority.
+
+4.3.  Controlling Route Distribution
+
+   In this section, we discuss the way in which the distribution of the
+   VPN-IPv4 routes is controlled.
+
+   If a PE router is attached to a particular VPN (by being attached to
+   a particular CE in that VPN), it learns some of that VPN's IP routes
+   from the attached CE router.  Routes learned from a CE routing peer
+   over a particular attachment circuit may be installed in the VRF
+   associated with that attachment circuit.  Exactly which routes are
+   installed in this manner is determined by the way in which the PE
+   learns routes from the CE.  In particular, when the PE and CE are
+   routing protocol peers, this is determined by the decision process of
+   the routing protocol; this is discussed in Section 7.
+
+   These routes are then converted to VPN-IP4 routes, and "exported" to
+   BGP.  If there is more than one route to a particular VPN-IP4 address
+   prefix, BGP chooses the "best" one, using the BGP decision process.
+   That route is then distributed by BGP to the set of other PEs that
+   need to know about it.  At these other PEs, BGP will again choose the
+   best route for a particular VPN-IP4 address prefix.  Then the chosen
+   VPN-IP4 routes are converted back into IP routes, and "imported" into
+   one or more VRFs.  Whether they are actually installed in the VRFs
+   depends on the decision process of the routing method used between
+   the PE and those CEs that are associated with the VRF in question.
+   Finally, any route installed in a VRF may be distributed to the
+   associated CE routers.
+
+4.3.1.  The Route Target Attribute
+
+   Every VRF is associated with one or more Route Target (RT)
+   attributes.
+
+   When a VPN-IPv4 route is created (from an IPv4 route that the PE has
+   learned from a CE) by a PE router, it is associated with one or more
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 15]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+   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
+   those of the PE's VRFs that are associated with Route Target T.
+   (Whether it actually gets installed depends upon the outcome of the
+   BGP decision process, and upon the outcome of the decision process of
+   the IGP (i.e., the intra-domain routing protocol) running on the
+   PE/CE interface.)
+
+   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
+   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 that 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 that 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 for present purposes, since it allows
+   only a 2-byte numbering space.  It is desirable to structure the
+   format, similar to what we have described for RDs (see Section 4.2),
+   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].  They are structured
+   similarly to the RDs.
+
+   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 VPN-IPv4 route is installed by BGP.
+
+   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
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 16]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+   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
+   specified site with a specified Route Target.  Or the PE might be
+   configured to associate certain routes leading to a specified site
+   with one Route Target, and certain with another.
+
+   If the PE and the CE are themselves BGP peers (see Section 7), then
+   the SP may allow the customer, within limits, to specify how its
+   routes are to be distributed.  The SP and the customer would need to
+   agree in advance on the set of RTs that are allowed to be attached to
+   the customer's VPN routes.  The CE could then attach one or more of
+   those RTs to each IP route that it distributes to the PE.  This gives
+   the customer the freedom to specify in real time, within agreed-upon
+   limits, its route distribution policies.  If the CE is allowed to
+   attach RTs to its routes, the PE MUST filter out all routes that
+   contain RTs that the customer is not allowed to use.  If the CE is
+   not allowed to attach RTs to its routes, but does so anyway, the PE
+   MUST remove the RT before converting the customer's route to a VPN-
+   IPv4 route.
+
+4.3.2.  Route Distribution Among PEs by BGP
+
+   If two sites of a VPN attach to PEs that are in the same Autonomous
+   System, the PEs can distribute VPN-IPv4 routes to each other by means
+   of an IBGP connection between them.  (The term "IBGP" refers to the
+   set of protocols and procedures used when there is a BGP connection
+   between two BGP speakers in the same Autonomous System.  This is
+   distinguished from "EBGP", the set of procedures used between two BGP
+   speakers in different Autonomous Systems.)  Alternatively, each can
+   have an IBGP connection to a route reflector [BGP-RR].
+
+   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 Network Layer
+   Reachability Information (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 process the packet appropriately.
+
+
+
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 17]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+   The PE may distribute the exact set of routes that appears in the
+   VRF, or it may perform summarization and distribute aggregates of
+   those routes, or it may do some of one and some of the other.
+
+   Suppose that a PE has assigned label L to route R, and has
+   distributed this label mapping via BGP.  If R is an aggregate of a
+   set of routes in the VRF, the PE will know that packets from the
+   backbone that arrive with this label must have their destination
+   addresses looked up in a VRF.  When the PE looks up the label in its
+   Label Information Base, it learns which VRF must be used.  On the
+   other hand, if R is not an aggregate, then when the PE looks up the
+   label, it learns the egress attachment circuit, as well as the
+   encapsulation header for the packet.  In this case, no lookup in the
+   VRF is done.
+
+   We would expect that the most common case would be the case where the
+   route is NOT an aggregate.  The case where it is an aggregate can be
+   very useful though if the VRF contains a large number of host routes
+   (e.g., as in dial-in), or if the VRF has an associated Local Area
+   Network (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).
+
+   Whether or not each route has a distinct label is an implementation
+   matter.  There are a number of possible algorithms one could use to
+   determine whether two routes get assigned the same label:
+
+     - One may choose to have a single label for an entire VRF, so that
+       a single label is shared by all the routes from that VRF.  Then
+       when the egress PE receives a packet with that label, it must
+       look up the packet's IP destination address in that VRF (the
+       packet's "egress VRF"), in order to determine the packet's egress
+       attachment circuit and the corresponding data link encapsulation.
+
+     - One may choose to have a single label for each attachment
+       circuit, so that a single label is shared by all the routes with
+       the same "outgoing attachment circuit".  This enables one to
+       avoid doing a lookup in the egress VRF, though some sort of
+       lookup may need to be done in order to determine the data link
+       encapsulation, e.g., an Address Resolution Protocol (ARP) lookup.
+
+     - One may choose to have a distinct label for each route.  Then if
+       a route is potentially reachable over more than one attachment
+       circuit, the PE/CE routing can switch the preferred path for a
+       route from one attachment circuit to another, without there being
+       any need to distribute new a label for that route.
+
+
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 18]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+   There may be other possible algorithms as well.  The choice of
+   algorithm is entirely at the discretion of the egress PE, and is
+   otherwise transparent.
+
+   In using BGP-distributed MPLS labels in this manner, we presuppose
+   that an MPLS packet carrying such a label can be tunneled from the
+   router that installs the corresponding BGP-distributed route to the
+   router that is the BGP next hop of that route.  This requires either
+   that a label switched path exist between those two routers or else
+   that some other tunneling technology (e.g., [MPLS-in-IP-GRE]) can be
+   used between them.
+
+   This tunnel may follow a "best effort" route, or it may follow a
+   traffic-engineered route.  Between a given pair of routers, there may
+   be one such tunnel, or there may be several, perhaps with different
+   Quality of Service (QoS) characteristics.  All that matters for the
+   VPN architecture is that some such tunnel exists.  To ensure
+   interoperability among systems that implement this VPN architecture
+   using MPLS label switched paths as the tunneling technology, all such
+   systems MUST support Label Distribution Protocol (LDP) [MPLS-LDP].
+   In particular, Downstream Unsolicited mode MUST be supported on
+   interfaces that are neither Label Controlled ATM (LC-ATM) [MPLS-ATM]
+   nor Label Controlled Frame Relay (LC-FR) [MPLS-FR] interfaces, and
+   Downstream on Demand mode MUST be supported on LC-ATM interfaces and
+   LC-FR interfaces.
+
+   If the tunnel follows a best-effort route, then the PE finds the
+   route to the remote endpoint by looking up its IP address in the
+   default forwarding table.
+
+   A PE router, UNLESS it is a route reflector (see Section 4.3.3) or an
+   Autonomous System Border Router (ASBR) for an inter-provider VPN (see
+   Section 10), 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 new Import Target is later added
+   to one of the PE's VRFs (a "VPN Join" operation), 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.
+
+   Similarly, if a particular Import Target is no longer present in any
+   of a PE's VRFs (as a result of one or more "VPN Prune" operations),
+   the PE may discard all routes that, as a result, no longer have any
+   of the PE's VRF's Import Targets as one of their Route Target
+   attributes.
+
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 19]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+   A router that is not attached to any VPN and that is not a Route
+   Reflector (i.e., a P router) never installs any VPN-IPv4 routes at
+   all.
+
+   Note that VPN Join and Prune operations are non-disruptive and do not
+   require any BGP connections to be brought down, as long as the
+   refresh mechanism of [BGP-RFSH] is used.
+
+   As a result of these distribution rules, no one PE ever needs to
+   maintain all routes for all VPNs; this is an important scalability
+   consideration.
+
+4.3.3.  Use of Route Reflectors
+
+   Rather than having a complete IBGP mesh among the PEs, it is
+   advantageous to make use of BGP Route Reflectors [BGP-RR] to improve
+   scalability.  All the usual techniques for using route reflectors to
+   improve scalability (e.g., route reflector hierarchies) are
+   available.
+
+   Route reflectors are the only systems that need to have routing
+   information for VPNs to which they are not directly attached.
+   However, there is no need to have any one route reflector know all
+   the VPN-IPv4 routes for all the VPNs supported by the backbone.
+
+   We outline below two different ways to partition the set of VPN-IPv4
+   routes among a set of route reflectors.
+
+      1. 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.  The route reflector may use the techniques of
+         [BGP-ORF] to install on each of its peers (regardless of
+         whether the peer is another route reflector or a PE) the set of
+         Outbound Route Filters (ORFs) that contains 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.
+
+         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
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 20]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+         route reflectors that are (pre)configured with this Route
+         Target.
+
+         Unless a given PE is a client of all route reflectors, when a
+         new VPN is added to the PE ("VPN Join"), it will need to become
+         a client of the route reflector(s) that maintain routes for
+         that VPN.  Likewise, deleting an existing VPN from the PE ("VPN
+         Prune") may result in a situation where the PE no longer needs
+         to be a client of some route reflector(s).  In either case, the
+         Join or Prune operation is non-disruptive (as long as
+         [BGP-RFSH] is used, and never requires a BGP connection to be
+         brought down, only to be brought right back up.
+
+         (By "adding a new VPN to a PE", we really mean adding a new
+         import Route Target to one of its VRFs, or adding a new VRF
+         with an import Route Target not had by any of the PE's other
+         VRFs.)
+
+      2. Another method is to have each PE be a client of some subset of
+         the 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
+
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 21]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+         the set, the route reflector, after changing its inbound route
+         filtering, must issue BGP Refresh to other route reflectors.
+
+         The delay of "a few hours" mentioned above allows a route
+         reflector to hold onto routes with a given RT, even after it
+         loses the last of its clients that are interested in such
+         routes.  This protects against the need to reacquire all such
+         routes if the clients' "disappearance" is only temporary.
+
+         With this procedure, VPN Join and Prune operations are also
+         non-disruptive.
+
+         Note that this technique will not work properly if some client
+         PE has a VRF with an import Route Target that is not one of its
+         export Route Targets.
+
+   In these procedures, a PE router which attaches to a particular VPN
+   "auto-discovers" the other PEs that attach to the same VPN.  When a
+   new PE router is added, or when an existing PE router attaches to a
+   new VPN, no reconfiguration of other PE routers is needed.
+
+   Just as there is no one PE router that needs to know all the VPN-IPv4
+   routes supported over the backbone, these distribution rules ensure
+   that there is no one Route Reflector (RR) that needs to know all the
+   VPN-IPv4 routes 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.4.  How VPN-IPv4 NLRI Is Carried in BGP
+
+   The BGP Multiprotocol Extensions [BGP-MP] are used to encode the
+   NLRI.  If the Address Family Identifier (AFI) field is set to 1, and
+   the Subsequent Address Family Identifier (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 does not require the capability to
+   distribute unlabeled VPN-IPv4 addresses.
+
+   In order for two BGP speakers to exchange labeled VPN-IPv4 NLRI, they
+   must use BGP Capabilities Advertisement 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.
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 22]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+4.3.5.  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 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
+   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.
+
+4.3.6.  Route Distribution Among VRFs in a Single PE
+
+   It is possible to distribute routes from one VRF to another, even if
+   both VRFs are in the same PE, even though in this case one cannot say
+   that the route has been distributed by BGP.  Nevertheless, the
+   decision to distribute a particular route from one VRF to another
+   within a single PE is the same decision that would be made if the
+   VRFs were on different PEs.  That is, it depends on the Route Target
+   attribute that is assigned to the route (or would be assigned if the
+   route were distributed by BGP), and the import target of the second
+   VRF.
+
+5.  Forwarding
+
+   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?
+
+   When a PE receives an IP packet from a CE device, it chooses a
+   particular VRF in which to look up the packet's destination address.
+   This choice is based on the packet's ingress attachment circuit.
+
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 23]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+   Assume that a match is found.  As a result we learn the packet's
+   "next hop".
+
+   If the packet's next hop is reached directly over a VRF attachment
+   circuit from this PE (i.e., the packet's egress attachment circuit is
+   on the same PE as its ingress attachment circuit), then the packet is
+   sent on the egress attachment circuit, and no MPLS labels are pushed
+   onto the packet's label stack.
+
+   If the ingress and egress attachment circuits are on the same PE, but
+   are associated with different VRFs, and if the route that best
+   matches the destination address in the ingress attachment circuit's
+   VRF is an aggregate of several routes in the egress attachment
+   circuit's VRF, it may be necessary to look up the packet's
+   destination address in the egress VRF as well.
+
+   If the packet's next hop is NOT reached through a VRF attachment
+   circuit, then the packet must travel at least one hop through the
+   backbone.  The packet thus has a "BGP Next Hop", and the BGP Next Hop
+   will have assigned an MPLS label for the route that best matches the
+   packet's destination address.  Call this label the "VPN route label".
+   The IP packet is turned into an MPLS packet with the VPN route label
+   as the sole label on the label stack.
+
+   The packet must then be tunneled to the BGP Next Hop.
+
+   If the backbone supports MPLS, this is done as follows:
+
+     - The PE routers (and any Autonomous System border routers) that
+       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.)
+
+     - If there are any traffic engineering tunnels to the BGP next hop,
+       and if one or more of those is available for use by the packet in
+       question, one of these tunnels is chosen.  This tunnel will be
+       associated with an MPLS label, the "tunnel label".  The tunnel
+       label gets pushed on the MPLS label stack, and the packet is
+       forwarded to the tunnel's next hop.
+
+
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 24]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+     - Otherwise,
+
+         * The packet will have an "IGP Next Hop", which is the next hop
+           along the IGP route to the BGP Next Hop.
+
+         * If the BGP Next Hop and the IGP Next Hop are the same, and if
+           penultimate hop popping is used, the packet is then sent to
+           the IGP Next Hop, carrying only the VPN route label.
+
+         * Otherwise, the IGP Next Hop will have assigned a label for
+           the route that best matches the address of the BGP Next Hop.
+           Call this the "tunnel label".  The tunnel label gets pushed
+           on as the packet's top label.  The packet is then forwarded
+           to the IGP Next Hop.
+
+     - MPLS will then carry the packet across the backbone to the BGP
+       Next Hop, where the VPN label will be examined.
+
+   If the backbone does not support MPLS, the MPLS packet carrying only
+   the VPN route label may be tunneled to the BGP Next Hop using the
+   techniques of [MPLS-in-IP-GRE].  When the packet emerges from the
+   tunnel, it will be at the BGP Next Hop, where the VPN route label
+   will be examined.
+
+   At the BGP Next Hop, the treatment of the packet depends on the VPN
+   route label (see Section 4.3.2).  In many cases, the PE will be able
+   to determine, from this label, the attachment circuit 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.  There are also intermediate cases in which the VPN route
+   label may determine the packet's egress attachment circuit, but a
+   lookup (e.g., ARP) still needs to be done in order to determine the
+   packet's data link header on that attachment circuit.
+
+   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, if the packet was an unlabeled IP packet when it
+   arrived at its ingress PE, it will again be an unlabeled packet when
+   it leaves its egress PE.
+
+   The fact that packets with VPN route labels are tunneled through the
+   backbone is what makes it possible to keep all the VPN routes out of
+   the P routers.  This is crucial to ensuring the scalability of the
+
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 25]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+   scheme.  The backbone does not even need to have routes to the CEs,
+   only to the PEs.
+
+   With respect to the tunnels, it is worth noting that this
+   specification:
+
+     - DOES NOT require that the tunnels be point-to-point; multipoint-
+       to-point can be used;
+
+     - DOES NOT require that there be any explicit setup of the tunnels,
+       either via signaling or via manual configuration;
+
+     - DOES NOT require that there be any tunnel-specific signaling;
+
+     - DOES NOT require that there be any tunnel-specific state in the P
+       or PE routers, beyond what is necessary to maintain the routing
+       information and (if used) the MPLS label information.
+
+   Of course, this specification is compatible with the use of point-
+   to-point tunnels that must be explicitly configured and/or signaled,
+   and in some situations there may be reasons for using such tunnels.
+
+   The considerations that are relevant to choosing a particular
+   tunneling technology are outside the scope of this specification.
+
+6.  Maintaining Proper Isolation of VPNs
+
+   To maintain proper isolation of one VPN from another, it is important
+   that no router in the backbone accept a tunneled packet from outside
+   the backbone, unless it is sure that both endpoints of that tunnel
+   are outside the backbone.
+
+   If MPLS is being used as the tunneling technology, this means that a
+   router in the backbone MUST NOT accept a labeled packet from any
+   adjacent non-backbone device unless the following two conditions
+   hold:
+
+      1. the label at the top of the label stack was actually
+         distributed by that backbone router to that non-backbone
+         device, and
+
+      2. 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.
+
+   The first condition ensure that any labeled packets received from
+   non-backbone routers have a legitimate and properly assigned label at
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 26]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+   the top of the label stack.  The second condition ensures that the
+   backbone routers will never look below that top label.  Of course,
+   the simplest way to meet these two conditions is just to have the
+   backbone devices refuse to accept labeled packets from non-backbone
+   devices.
+
+   If MPLS is not being used as the tunneling technology, then filtering
+   must be done to ensure that an MPLS-in-IP or MPLS-in-GRE packet can
+   be accepted into the backbone only if the packet's IP destination
+   address will cause it to be sent outside the backbone.
+
+7.  How PEs Learn Routes from CEs
+
+   The PE routers that attach to a particular VPN need to know, for each
+   attachment circuit leading to that VPN, which of the VPN's addresses
+   should be reached over that attachment circuit.
+
+   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.  Routes from a VPN site are NOT leaked into the backbone's IGP.
+
+   Exactly which PE/CE route distribution techniques are possible
+   depends on whether or not a particular CE is in a "transit VPN".  A
+   "transit VPN" is one that contains a router that receives routes from
+   a "third party" (i.e., from a router that is not in the VPN, but is
+   not a PE router) and that redistributes those routes to a PE router.
+   A VPN that 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 Routing Information Protocol (RIP)
+         [RIP] peers, and the CE may use RIP to tell the PE router the
+         set of address prefixes that 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 that is different than (i.e.,
+         contains a different RD than) R1.
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 27]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+      3. The PE and CE routers may be OSPF peers.  A PE router that 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
+         that are in distinct VPNs, the PE must of course be running
+         multiple instances of OSPF.
+
+         IPv4 routes that 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 Link
+         State Advertisement (LSA).  OSPF route tagging is used to
+         ensure that routes received from the MPLS/BGP backbone are not
+         sent back into the backbone.
+
+         Specification of the complete set of procedures for the use of
+         OSPF between PE and CE can be found in [VPN-OSPF] and
+         [OSPF-2547-DNBIT].
+
+      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 that are at the CE router's site. (This
+         technique can be used in stub VPNs or transit VPNs.)
+
+         This technique has a number of advantages over the others:
+
+            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.  A complete specification of the
+               set of attributes and their use is outside the scope of
+               this document.  However, some examples of the way this
+               may be used are the following:
+
+
+
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 28]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+                 - The CE may suggest a particular Route Target for each
+                   route, from among the Route Targets that the PE is
+                   authorized to attach to the route.  The PE would then
+                   attach only the suggested Route Target, rather than
+                   the full set.  This gives the CE administrator some
+                   dynamic control of the distribution of routes from
+                   the CE.
+
+                 - Additional types of Extended Community attributes may
+                   be defined, where the intention is to have those
+                   attributes passed transparently (i.e., without being
+                   changed by the PE routers) from CE to CE.  This would
+                   allow CE administrators to implement additional route
+                   filtering, beyond that which is done by the PEs.
+                   This additional filtering would not require
+                   coordination with the SP.
+
+         On the other hand, using BGP may be something new for the CE
+         administrators.
+
+         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 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 constitutes a transit VPN?  This will
+         generally be the case only if the VPN is itself an Internet
+         Service Provider's (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 9.
+
+   When we do not need to distinguish among the different ways in which
+   a PE can be informed of the address prefixes that exist at a given
+   site, we will simply say that the PE has "learned" the routes from
+   that site.  This includes the case where the PE has been manually
+   configured with the routes.
+
+   Before a PE can redistribute a VPN-IPv4 route learned from a site, it
+   must assign a Route Target attribute (see Section 4.3.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
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 29]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+   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.
+
+8.  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 it 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 that 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.
+
+9.  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 that 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.  However, it is necessary in these cases that the CE
+   routers support MPLS.  In particular:
+
+     - The CE routers should distribute to the PE routers ONLY those
+       routes that are internal to the VPN.  This allows the VPN to be
+       handled as a stub VPN.
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 30]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+     - The CE routers should support MPLS, in that they should be able
+       to receive labels from the PE routers, and send labeled packets
+       to the PE routers.  They do not need to distribute labels of
+       their own, though.
+
+     - The PE routers should distribute, to the CE routers, labels for
+       the routes they distribute to the CE routers.
+
+       The PE must not distribute the same label to two different CEs
+       unless one of the following conditions holds:
+
+         * The two CEs are associated with exactly the same set of VRFs;
+
+         * The PE maintains a different Incoming Label Map ([MPLS-ARCH])
+           for each CE.
+
+       Further, when the PE receives a labeled packet from a CE, it must
+       verify that the top label is one that was distributed to that CE.
+
+     - Routers at the different sites should establish BGP connections
+       among themselves for the purpose of exchanging external routes
+       (i.e., routes that lead outside of the VPN).
+
+     - 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.  The PE, rather than
+   looking up the packet's IP destination address in a VRF, uses the
+   packet's top MPLS label to select the BGP next hop.  As a result, if
+   the BGP next hop is more than one hop away, the top label will be
+   replaced by two labels, a tunnel label and a VPN route label.  If the
+   BGP next hop is one hop away, the top label may be replaced by just
+   the VPN route label.  If the ingress PE is also the egress PE, the
+   top label will just be popped.  When the packet is sent from its
+   egress PE to a CE, the packet will have one fewer MPLS labels than it
+   had when it was first received by its ingress PE.
+
+   In the above procedure, the CE routers are the only routers in the
+   VPN that need to support MPLS.  If, on the other hand, all the
+   routers at a particular VPN site support MPLS, then it is no longer
+   required that the CE routers know all the external routes.  All that
+   is required is that the external routes be known to whatever routers
+   are responsible for putting the label stack on a hitherto unlabeled
+   packet and that there be label switched path that leads from those
+   routers to their BGP peers at other sites.  In this case, for each
+
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 31]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+   internal route that a CE router distributes to a PE router, it must
+   also distribute a label.
+
+10.  Multi-AS Backbones
+
+   What if two sites of a VPN are connected to different Autonomous
+   Systems (e.g., because the sites are connected to different SPs)?
+   The PE routers attached to that VPN will then not be able to maintain
+   IBGP connections with each other, or with a common route reflector.
+   Rather, there needs to be some way to use EBGP to distribute VPN-IPv4
+   addresses.
+
+   There are a number of different ways of handling this case, which we
+   present in order of increasing scalability.
+
+      a) VRF-to-VRF connections at the AS (Autonomous System) border
+         routers.
+
+         In this procedure, a PE router in one AS attaches directly to a
+         PE router in another.  The two PE routers will be attached by
+         multiple sub-interfaces, at least one for each of the VPNs
+         whose routes need to be passed from AS to AS.  Each PE will
+         treat the other as if it were a CE router.  That is, the PEs
+         associate each such sub-interface with a VRF, and use EBGP to
+         distribute unlabeled IPv4 addresses to each other.
+
+         This is a procedure that "just works", and that does not
+         require MPLS at the border between ASes.  However, it does not
+         scale as well as the other procedures discussed below.
+
+      b) EBGP redistribution of labeled VPN-IPv4 routes from AS to
+         neighboring AS.
+
+         In this procedure, the PE routers use IBGP to redistribute
+         labeled 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 uses EBGP to redistribute those labeled
+         VPN-IPv4 routes to an ASBR in another AS, which in turn
+         distributes them to the PE routers in that AS, or perhaps to
+         another ASBR which in turn distributes them, and so on.
+
+         When using this procedure, 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, or from any BGP peers that are not trusted.  An ASBR
+         should never accept a labeled packet from an EBGP peer unless
+         it has actually distributed the top label to that peer.
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 32]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+         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 that 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.
+
+         This procedure requires that there be a label switched path
+         leading from a packet's ingress PE to its egress PE.  Hence the
+         appropriate trust relationships must exist between and among
+         the set of ASes along the path.  Also, there must be agreement
+         among the set of SPs as to which border routers need to receive
+         routes with which Route Targets.
+
+      c) Multi-hop EBGP redistribution of labeled VPN-IPv4 routes
+         between source and destination ASes, with EBGP redistribution
+         of labeled IPv4 routes from AS to neighboring AS.
+
+         In this procedure, VPN-IPv4 routes are neither maintained nor
+         distributed by the ASBRs.  An ASBR must maintain labeled IPv4
+         /32 routes to the PE routers within its AS.  It uses EBGP to
+         distribute these routes to other ASes.  ASBRs in any transit
+         ASes will also have to use EBGP to pass along the labeled /32
+         routes.  This results in the creation of a label switched path
+         from the ingress PE router to the egress PE router.  Now PE
+         routers in different ASes can establish multi-hop EBGP
+         connections to each other, and can exchange VPN-IPv4 routes
+         over those connections.
+
+         If the /32 routes for the PE routers are made known to the P
+         routers of each AS, everything works normally.  If the /32
+         routes for the PE routers are NOT made known to the P routers
+         (other than the ASBRs), then this procedure requires a packet's
+         ingress PE to put a three-label stack on it.  The bottom label
+         is assigned by the egress PE, corresponding to the packet's
+         destination address in a particular VRF.  The middle label is
+         assigned by the ASBR, corresponding to the /32 route to the
+         egress PE.  The top label is assigned by the ingress PE's IGP
+         Next Hop, corresponding to the /32 route to the ASBR.
+
+         To improve scalability, one can have the multi-hop EBGP
+         connections exist only between a route reflector in one AS and
+         a route reflector in another.  (However, when the route
+         reflectors distribute routes over this connection, they do not
+         modify the BGP next hop attribute of the routes.)  The actual
+         PE routers would then only have IBGP connections to the route
+         reflectors in their own AS.
+
+
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 33]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+         This procedure is very similar to the "carrier's carrier"
+         procedures described in Section 9.  Like the previous
+         procedure, it requires that there be a label switched path
+         leading from a packet's ingress PE to its egress PE.
+
+11.  Accessing the Internet from a VPN
+
+   Many VPN sites will need to be able to access the public Internet, as
+   well as to access other VPN sites.  The following describes some of
+   the alternative ways of doing this.
+
+      1. In some VPNs, one or more of the sites will obtain Internet
+         access by means of an "Internet gateway" (perhaps a firewall)
+         attached to a non-VRF interface to an ISP.  The ISP may or may
+         not be the same organization as the SP that is providing the
+         VPN service.  Traffic to/from the Internet gateway would then
+         be routed according to the PE router's default forwarding
+         table.
+
+         In this case, the sites that have Internet access may be
+         distributing a default route to their PEs, which in turn
+         redistribute it to other PEs and hence into other sites of the
+         VPN.  This provides Internet access for all of the VPN's sites.
+
+         In order to properly handle traffic from the Internet, the ISP
+         must distribute, to the Internet, routes leading to addresses
+         that are within the VPN.  This is completely independent of any
+         of the route distribution procedures described in this
+         document.  The internal structure of the VPN will in general
+         not be visible from the Internet; such routes would simply lead
+         to the non-VRF interface that attaches to the VPN's Internet
+         gateway.
+
+         In this model, there is no exchange of routes between a PE
+         router's default forwarding table and any of its VRFs.  VPN
+         route distribution procedures and Internet route distribution
+         procedures are completely independent.
+
+         Note that although some sites of the VPN use a VRF interface to
+         communicate with the Internet, ultimately all packets to/from
+         the Internet traverse a non-VRF interface before
+         leaving/entering the VPN, so we refer to this as "non-VRF
+         Internet access".
+
+         Note that the PE router to which the non-VRF interface attaches
+         does not necessarily need to maintain all the Internet routes
+         in its default forwarding table.  The default forwarding table
+         could have as few as one route, "default", which leads to
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 34]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+         another router (probably an adjacent one) that has the Internet
+         routes.  A variation of this scheme is to tunnel packets
+         received over the non-VRF interface from the PE router to
+         another router, where this other router maintains the full set
+         of Internet routes.
+
+      2. Some VPNs may obtain Internet access via a VRF interface ("VRF
+         Internet access").  If a packet is received by a PE over a VRF
+         interface, and if the packet's destination address does not
+         match any route in the VRF, then it may be matched against the
+         PE's default forwarding table.  If a match is made there, the
+         packet can be forwarded natively through the backbone to the
+         Internet, instead of being forwarded by MPLS.
+
+         In order for traffic to flow natively in the opposite direction
+         (from Internet to VRF interface), some of the routes from the
+         VRF must be exported to the Internet forwarding table.
+         Needless to say, any such routes must correspond to globally
+         unique addresses.
+
+         In this scheme, the default forwarding table might have the
+         full set of Internet routes, or it might have as little as a
+         single default route leading to another router that does have
+         the full set of Internet routes in its default forwarding
+         table.
+
+      3. Suppose the PE has the capability to store "non-VPN routes" in
+         a VRF.  If a packet's destination address matches a "non-VPN
+         route", then the packet is transmitted natively, rather than
+         being transmitted via MPLS.  If the VRF contains a non-VPN
+         default route, all packets for the public Internet will match
+         it, and be forwarded natively to the default route's next hop.
+         At that next hop, the packets' destination addresses will be
+         looked up in the default forwarding table, and may match more
+         specific routes.
+
+         This technique would only be available if none of the CE
+         routers is distributing a default route.
+
+      4. It is also possible to obtain Internet access via a VRF
+         interface by having the VRF contain the Internet routes.
+         Compared with model 2, this eliminates the second lookup, but
+         it has the disadvantage of requiring the Internet routes to be
+         replicated in each such VRF.
+
+         If this technique is used, the SP may want to make its
+         interface to the Internet be a VRF interface, and to use the
+
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 35]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+         techniques of Section 4 to distribute Internet routes, as VPN-
+         IPv4 routes, to other VRFs.
+
+   It should be clearly understood that by default, there is no exchange
+   of routes between a VRF and the default forwarding table.  This is
+   done ONLY upon agreement between a customer and an SP, and only if it
+   suits the customer's policies.
+
+12.  Management VPNs
+
+   This specification does not require that the sub-interface connecting
+   a PE router and a CE router be a "numbered" interface.  If it is a
+   numbered interface, this specification allows the addresses assigned
+   to the interface to come from either the address space of the VPN or
+   the address space of the SP.
+
+   If a CE router is being managed by the Service Provider, then the
+   Service Provider will likely have a network management system that
+   needs to be able to communicate with the CE router.  In this case,
+   the addresses assigned to the sub-interface connecting the CE and PE
+   routers should come from the SP's address space, and should be unique
+   within that space.  The network management system should itself
+   connect to a PE router (more precisely, be at a site that connects to
+   a PE router) via a VRF interface.  The address of the network
+   management system will be exported to all VRFs that are associated
+   with interfaces to CE routers that are managed by the SP.  The
+   addresses of the CE routers will be exported to the VRF associated
+   with the network management system, but not to any other VRFs.
+
+   This allows communication between the CE and network management
+   system, but does not allow any undesired communication to or among
+   the CE routers.
+
+   One way to ensure that the proper route import/exports are done is to
+   use two Route Targets; call them T1 and T2.  If a particular VRF
+   interface attaches to a CE router that is managed by the SP, then
+   that VRF is configured to:
+
+     - import routes that have T1 attached to them, and
+
+     - attach T2 to addresses assigned to each end of its VRF
+       interfaces.
+
+   If a particular VRF interface attaches to the SP's network management
+   system, then that VRF is configured to attach T1 to the address of
+   that system, and to import routes that have T2 attached to them.
+
+
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 36]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+13.  Security Considerations
+
+13.1.  Data Plane
+
+   By security in the "data plane", we mean protection against the
+   following possibilities:
+
+     - Packets from within a VPN travel to a site outside the VPN, other
+       than in a manner consistent with the policies of the VPN.
+
+     - Packets from outside a VPN enter one of the VPN's sites, other
+       than in a manner consistent with the policies of the VPN.
+
+   Under the following conditions:
+
+      1. a backbone router does not accept labeled packets over a
+         particular data link, unless it is known that that data link
+         attaches only to trusted systems, or 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
+
+      2. labeled VPN-IPv4 routes are not accepted from untrusted or
+         unreliable routing peers,
+
+      3. no successful attacks have been mounted on the control plane,
+
+   the data plane security provided by this architecture is virtually
+   identical to that provided to VPNs by Frame Relay or ATM backbones.
+   If the devices under the control of the SP are properly configured,
+   data will not enter or leave a VPN unless authorized to do so.
+
+   Condition 1 above can be stated more precisely.  One should discard a
+   labeled packet received from a particular neighbor unless one of the
+   following two conditions holds:
+
+     - the packet's top label has a label value that the receiving
+       system has distributed to that neighbor, or
+
+     - the packet's top label has a label value that the receiving
+       system has distributed to a system beyond that neighbor (i.e.,
+       when it is known that the path from the system to which the label
+       was distributed to the receiving system may be via that
+       neighbor).
+
+
+
+
+
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 37]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+   Condition 2 above is of most interest in the case of inter-provider
+   VPNs (see Section 10).  For inter-provider VPNs constructed according
+   to scheme b) of Section 10, condition 2 is easily checked.  (The
+   issue of security when scheme (c) of Section 10 is used is for
+   further study.)
+
+   It is worth noting that the use of MPLS makes it much simpler to
+   provide data plane security than might be possible if one attempted
+   to use some form of IP tunneling in place of the MPLS outer label.
+   It is a simple matter to have one's border routers 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 tunneled packet whose
+   destination address is that of a PE router; certainly, this is not
+   impossible to do, but it has both management and performance
+   implications.
+
+   MPLS-in-IP and MPLS-in-GRE tunneling are specified in
+   [MPLS-in-IP-GRE].  If it is desired to use such tunnels to carry VPN
+   packets, then the security considerations described in Section 8 of
+   that document must be fully understood.  Any implementation of
+   BGP/MPLS IP VPNs that allows VPN packets to be tunneled as described
+   in that document MUST contain an implementation of IPsec that can be
+   used as therein described.  If the tunnel is not secured by IPsec,
+   then the technique of IP address filtering at the border routers,
+   described in Section 8.2 of that document, is the only means of
+   ensuring that a packet that exits the tunnel at a particular egress
+   PE was actually placed in the tunnel by the proper tunnel head node
+   (i.e., that the packet does not have a spoofed source address).
+   Since border routers frequently filter only source addresses, packet
+   filtering may not be effective unless the egress PE can check the IP
+   source address of any tunneled packet it receives, and compare it to
+   a list of IP addresses that are valid tunnel head addresses.  Any
+   implementation that allows MPLS-in-IP and/or MPLS-in-GRE tunneling to
+   be used without IPsec MUST allow the egress PE to validate in this
+   manner the IP source address of any tunneled packet that it receives.
+
+   In the case where a number of CE routers attach to a PE router via a
+   LAN interface, to ensure proper security, one of the following
+   conditions must hold:
+
+      1. All the CE routers on the LAN belong to the same VPN, or
+
+      2. A trusted and secured LAN switch divides the LAN into multiple
+         VLANs, with each VLAN containing only systems of a single VPN;
+         in this case, the switch will attach the appropriate VLAN tag
+         to any packet before forwarding it to the PE router.
+
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 38]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+   Cryptographic privacy is not provided by this architecture, nor by
+   Frame Relay or ATM VPNs.  These architectures are all compatible with
+   the use of cryptography on a CE-CE basis, if that is desired.
+
+   The use of cryptography on a PE-PE basis is for further study.
+
+13.2.  Control Plane
+
+   The data plane security of the previous section depends on the
+   security of the control plane.  To ensure security, neither BGP nor
+   LDP connections should be made with untrusted peers.  The TCP/IP MD5
+   authentication option [TCP-MD5] should be used with both these
+   protocols.  The routing protocol within the SP's network should also
+   be secured in a similar manner.
+
+13.3.  Security of P and PE Devices
+
+   If the physical security of these devices is compromised, data plane
+   security may also be compromised.
+
+   The usual steps should be taken to ensure that IP traffic from the
+   public Internet cannot be used to modify the configuration of these
+   devices, or to mount Denial of Service attacks on them.
+
+14.  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 (Integrated Services) or diffserv (Differentiated
+   Services) capabilities to a particular VPN, as appropriate.
+
+
+
+
+
+
+
+
+
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 39]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+15.  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 (that are neither PE routers nor
+   Route Reflectors), and, in the case of multi-provider VPNs, (d)
+   ASBRs.
+
+   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 can be partitioned among VPNs so that each partition
+   carries routes for only a subset of the VPNs supported by the Service
+   Provider.  Thus, no single route reflector is required to maintain
+   routes for all VPNs.
+
+   For inter-provider VPNs, if the ASBRs maintain and distribute VPN-
+   IPv4 routes, then the ASBRs can be partitioned among VPNs in a
+   similar manner, with the result that no single ASBR is required to
+   maintain routes for all the inter-provider VPNs.  If multi-hop EBGP
+   is used, then the ASBRs need not maintain and distribute VPN-IPv4
+   routes at all.
+
+   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.
+
+16.  IANA Considerations
+
+   The Internet Assigned Numbers Authority (IANA) has created a new
+   registry for the "Route Distinguisher Type Field" (see Section 4.2).
+   This is a two-byte field.  Types 0, 1, and 2 are defined by this
+   document.  Additional Route Distinguisher Type Field values with a
+   high-order bit of 0 may be allocated by IANA on a "First Come, First
+   Served" basis [IANA].  Values with a high-order bit of 1 may be
+   allocated by IANA based on "IETF consensus" [IANA].
+
+
+
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 40]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+   This document specifies (see Section 4.3.4) the use of the BGP
+   Address Family Identifier (AFI) value 1, along with the BGP
+   Subsequent Address Family Identifier (SAFI) value 128, to represent
+   the address family "VPN-IPv4 Labeled Addresses", which is defined in
+   this document.
+
+   The use of AFI value 1 for IP is as currently specified in the IANA
+   registry "Address Family Identifier", so IANA need take no action
+   with respect to it.
+
+   The SAFI value 128 was originally specified as "Private Use" in the
+   IANA "Subsequent Address Family Identifier" registry.  IANA has
+   changed the SAFI value 128 from "private use" to "MPLS-labeled VPN
+   address".
+
+17. Acknowledgements
+
+   The full list of contributors can be found in Section 18.
+
+   Significant contributions to this work have also been made by Ravi
+   Chandra, Dan Tappan, and Bob Thomas.
+
+   We also wish to thank Shantam Biswas for his review and
+   contributions.
+
+18.  Contributors
+
+   Tony Bogovic
+   Telcordia Technologies
+   445 South Street, Room 1A264B
+   Morristown, NJ 07960
+
+   EMail: tjb@research.telcordia.com
+
+
+   Stephen John Brannon
+   Swisscom AG
+   Postfach 1570
+   CH-8301
+   Glattzentrum (Zuerich), Switzerland
+
+   EMail: stephen.brannon@swisscom.com
+
+
+
+
+
+
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 41]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+   Marco Carugi
+   Nortel Networks S.A.
+   Parc d'activites de Magny-Les Jeunes Bois  CHATEAUFORT
+   78928 YVELINES Cedex 9 - FRANCE
+
+   EMail: marco.carugi@nortelnetworks.com
+
+
+   Christopher J. Chase
+   AT&T
+   200 Laurel Ave
+   Middletown, NJ 07748
+   USA
+
+   EMail: chase@att.com
+
+
+   Ting Wo Chung
+   Bell Nexxia
+   181 Bay Street
+   Suite 350
+   Toronto, Ontario
+   M5J2T3
+
+   EMail: ting_wo.chung@bellnexxia.com
+
+
+   Eric Dean
+
+
+   Jeremy De Clercq
+   Alcatel Network Strategy Group
+   Francis Wellesplein 1
+   2018 Antwerp, Belgium
+
+   EMail: jeremy.de_clercq@alcatel.be
+
+
+   Luyuan Fang
+   AT&T
+   IP Backbone Architecture
+   200 Laurel Ave.
+   Middletown, NJ 07748
+
+   EMail: luyuanfang@att.com
+
+
+
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 42]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+   Paul Hitchen
+   BT
+   BT Adastral Park
+   Martlesham Heath,
+   Ipswich IP5 3RE
+   UK
+
+   EMail: paul.hitchen@bt.com
+
+
+   Manoj Leelanivas
+   Juniper Networks, Inc.
+   385 Ravendale Drive
+   Mountain View, CA 94043 USA
+
+   EMail: manoj@juniper.net
+
+
+   Dave Marshall
+   Worldcom
+   901 International Parkway
+   Richardson, Texas 75081
+
+   EMail: dave.marshall@wcom.com
+
+
+   Luca Martini
+   Cisco Systems, Inc.
+   9155 East Nichols Avenue, Suite 400
+   Englewood, CO, 80112
+
+   EMail: lmartini@cisco.com
+
+
+   Monique Jeanne Morrow
+   Cisco Systems, Inc.
+   Glatt-com, 2nd floor
+   CH-8301
+   Glattzentrum, Switzerland
+
+   EMail: mmorrow@cisco.com
+
+
+
+
+
+
+
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 43]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+   Ravichander Vaidyanathan
+   Telcordia Technologies
+   445 South Street, Room 1C258B
+   Morristown, NJ 07960
+
+   EMail: vravi@research.telcordia.com
+
+
+   Adrian Smith
+   BT
+   BT Adastral Park
+   Martlesham Heath,
+   Ipswich IP5 3RE
+   UK
+
+   EMail: adrian.ca.smith@bt.com
+
+
+   Vijay Srinivasan
+   1200 Bridge Parkway
+   Redwood City, CA 94065
+
+   EMail: vsriniva@cosinecom.com
+
+
+   Alain Vedrenne
+   Equant
+   Heraklion, 1041 route des Dolines, BP347
+   06906 Sophia Antipolis, Cedex, France
+
+   EMail: Alain.Vedrenne@equant.com
+
+19.  Normative References
+
+   [BGP]             Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
+                     (BGP-4)", RFC 4271, January 2006.
+
+   [BGP-MP]          Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
+                     "Multiprotocol Extensions for BGP-4", RFC 2858,
+                     June 2000.
+
+   [BGP-EXTCOMM]     Sangli, S., Tappan, D., and Y. Rekhter, "BGP
+                     Extended Communities Attribute", RFC 4360, February
+                     2006.
+
+   [MPLS-ARCH]       Rosen, E., Viswanathan, A., and R. Callon,
+                     "Multiprotocol Label Switching Architecture", RFC
+                     3031, January 2001.
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 44]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+   [MPLS-BGP]        Rekhter, Y. and E. Rosen, "Carrying Label
+                     Information in BGP-4", RFC 3107, May 2001.
+
+   [MPLS-ENCAPS]     Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
+                     Farinacci, D., Li, T., and A. Conta, "MPLS Label
+                     Stack Encoding", RFC 3032, January 2001.
+
+20.  Informative References
+
+   [BGP-AS4]         Vohra, Q. and E. Chen, "BGP Support for Four-Octet
+                     AS Number Space", Work in Progress, March 2004.
+
+   [BGP-ORF]         Chen, E. and Y. Rekhter, "Cooperative Route
+                     Filtering Capability for BGP-4", Work in Progress,
+                     March 2004.
+
+   [BGP-RFSH]        Chen, E., "Route Refresh Capability for BGP-4", RFC
+                     2918, September 2000.
+
+   [BGP-RR]          Bates, T., Chandra, R., and E. Chen, "BGP Route
+                     Reflection - An Alternative to Full Mesh IBGP", RFC
+                     2796, April 2000.
+
+   [IANA]            Narten, T. and H. Alvestrand, "Guidelines for
+                     Writing an IANA Considerations Section in RFCs",
+                     BCP 26, RFC 2434, October 1998.
+
+   [MPLS-ATM]        Davie, B., Lawrence, J., McCloghrie, K., Rosen, E.,
+                     Swallow, G., Rekhter, Y., and P. Doolan, "MPLS
+                     using LDP and ATM VC Switching", RFC 3035, January
+                     2001.
+
+   [MPLS/BGP-IPsec]  Rosen, E., De Clercq, J., Paridaens, O., T'Joens,
+                     Y., and C. Sargor, "Architecture for the Use of
+                     PE-PE IPsec Tunnels in BGP/MPLS IP VPNs", Work in
+                     Progress, March 2004.
+
+   [MPLS-FR]         Conta, A., Doolan, P., and A. Malis, "Use of Label
+                     Switching on Frame Relay Networks Specification",
+                     RFC 3034, January 2001.
+
+   [MPLS-in-IP-GRE]  Worster, T., Rekhter, Y., and E. Rosen,
+                     "Encapsulating MPLS in IP or Generic Routing
+                     Encapsulation (GRE)", RFC 4023, March 2005.
+
+   [MPLS-LDP]        Andersson, L., Doolan, P., Feldman, N., Fredette,
+                     A., and B. Thomas, "LDP Specification", RFC 3036,
+                     January 2001.
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 45]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+   [MPLS-RSVP]       Awduche, D., Berger, L., Gan, D., Li, T.,
+                     Srinivasan, V., and G. Swallow, "RSVP-TE:
+                     Extensions to RSVP for LSP Tunnels", RFC 3209,
+                     December 2001.
+
+   [OSPFv2]          Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
+                     1998.
+
+   [PASTE]           Li, T. and Y. Rekhter, "A Provider Architecture for
+                     Differentiated Services and Traffic Engineering
+                     (PASTE)", RFC 2430, October 1998.
+
+   [RIP]             Malkin, G., "RIP Version 2", STD 56, RFC 2453,
+                     November 1998.
+
+   [OSPF-2547-DNBIT] Rosen, E., Psenak, P., and P. Pillay-Esnault,
+                     "Using an LSA Options Bit to Prevent Looping in
+                     BGP/MPLS IP VPNs", Work in Progress, March 2004.
+
+   [TCP-MD5]         Heffernan, A., "Protection of BGP Sessions via the
+                     TCP MD5 Signature Option", RFC 2385, August 1998.
+
+   [VPN-MCAST]       Rosen, E., Cai, Y., and J. Wijsnands, "Multicast in
+                     MPLS/BGP VPNs", Work in Progress, May 2004.
+
+   [VPN-OSPF]        Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF
+                     as the PE/CE Protocol in BGP/MPLS VPNs", Work in
+                     Progress, February 2004.
+
+Authors' Addresses
+
+   Eric C. Rosen
+   Cisco Systems, Inc.
+   1414 Massachusetts Avenue
+   Boxborough, MA 01719
+
+   EMail: erosen@cisco.com
+
+
+   Yakov Rekhter
+   Juniper Networks
+   1194 N. Mathilda Avenue
+   Sunnyvale, CA 94089
+
+   EMail: yakov@juniper.net
+
+
+
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 46]
+
+RFC 4364                    BGP/MPLS IP VPNs               February 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Rosen & Rekhter             Standards Track                    [Page 47]
+