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.
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
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.
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.
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.
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.
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.
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
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
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,