Request for Comments: 4110 Juniper Networks
Category: Informational M. Suzuki
NTT Corporation
July 2005
A Framework for Layer 3
Provider-Provisioned Virtual Private Networks (PPVPNs)
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document provides a framework for Layer 3 Provider-Provisioned
Virtual Private Networks (PPVPNs). This framework is intended to aid
in the standardization of protocols and mechanisms for support of
layer 3 PPVPNs. It is the intent of this document to produce a
coherent description of the significant technical issues that are
important in the design of layer 3 PPVPN solutions. Selection of
specific approaches, making choices regarding engineering tradeoffs,
and detailed protocol specification, are outside of the scope of this
framework document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Objectives of the Document . . . . . . . . . . . . . . . 3
1.2. Overview of Virtual Private Networks . . . . . . . . . . 4
1.3. Types of VPNs. . . . . . . . . . . . . . . . . . . . . . 7
1.3.1. CE- vs PE-based VPNs . . . . . . . . . . . . . . 8
1.3.2. Types of PE-based VPNs . . . . . . . . . . . . . 9
1.3.3. Layer 3 PE-based VPNs. . . . . . . . . . . . . . 10
1.4. Scope of the Document. . . . . . . . . . . . . . . . . . 10
1.5. Terminology. . . . . . . . . . . . . . . . . . . . . . . 11
1.6. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 13
2. Reference Models . . . . . . . . . . . . . . . . . . . . . . . 14
2.1. Reference Model for Layer 3 PE-based VPN . . . . . . . . 14
2.1.1. Entities in the Reference Model. . . . . . . . . 16
2.1.2. Relationship Between CE and PE . . . . . . . . . 18
2.1.3. Interworking Model . . . . . . . . . . . . . . . 19
2.2. Reference Model for Layer 3 Provider-Provisioned
CE-based VPN . . . . . . . . . . . . . . . . . . . . . . 21
2.2.1. Entities in the Reference Model. . . . . . . . . 22
3. Customer Interface . . . . . . . . . . . . . . . . . . . . . . 23
3.1. VPN Establishment at the Customer Interface. . . . . . . 23
3.1.1. Layer 3 PE-based VPN . . . . . . . . . . . . . . 23
3.1.1.1. Static Binding . . . . . . . . . . . . 24
3.1.1.2. Dynamic Binding. . . . . . . . . . . . 24
3.1.2. Layer 3 Provider-Provisioned CE-based VPN. . . . 25
3.2. Data Exchange at the Customer Interface. . . . . . . . . 25
3.2.1. Layer 3 PE-based VPN . . . . . . . . . . . . . . 25
3.2.2. Layer 3 Provider-Provisioned CE-based VPN. . . . 26
3.3. Customer Visible Routing . . . . . . . . . . . . . . . . 26
3.3.1. Customer View of Routing for Layer 3 PE-based
VPNs . . . . . . . . . . . . . . . . . . . . . . 26
3.3.1.1. Routing for Intranets . . . . . . . . 27
3.3.1.2. Routing for Extranets . . . . . . . . 28
3.3.1.3. CE and PE Devices for Layer 3
PE-based VPNs. . . . . . . . . . . . . 29
3.3.2. Customer View of Routing for Layer 3 Provider-
Provisioned CE-based VPNs. . . . . . . . . . . . 29
3.3.3. Options for Customer Visible Routing . . . . . . 30
4. Network Interface and SP Support of VPNs . . . . . . . . . . . 32
4.1. Functional Components of a VPN . . . . . . . . . . . . . 32
4.2. VPN Establishment and Maintenance. . . . . . . . . . . . 34
4.2.1. VPN Discovery . . . . . . . . . . . . . . . . . 35
4.2.1.1. Network Management for Membership
Information. . . . . . . . . . . . . . 35
4.2.1.2. Directory Servers. . . . . . . . . . . 36
4.2.1.3. Augmented Routing for Membership
Information. . . . . . . . . . . . . . 36
4.2.1.4. VPN Discovery for Inter-SP VPNs. . . . 37
4.2.2. Constraining Distribution of VPN Routing
Information . . . . . . . . . . . . . . . . . . 38
4.2.3. Controlling VPN Topology . . . . . . . . . . . . 38
4.3. VPN Tunneling . . . . . . . . . . . . . . . . . . . . . 40
4.3.1. Tunnel Encapsulations. . . . . . . . . . . . . . 40
4.3.2. Tunnel Multiplexing. . . . . . . . . . . . . . . 41
4.3.3. Tunnel Establishment . . . . . . . . . . . . . . 42
4.3.4. Scaling and Hierarchical Tunnels . . . . . . . . 43
4.3.5. Tunnel Maintenance . . . . . . . . . . . . . . . 45
4.3.6. Survey of Tunneling Techniques . . . . . . . . . 46
4.3.6.1. GRE . . . . . . . . . . . . . . . . . 46
4.3.6.2. IP-in-IP Encapsulation . . . . . . . . 47
4.3.6.3. IPsec. . . . . . . . . . . . . . . . . 48
4.3.6.4. MPLS . . . . . . . . . . . . . . . . . 49
4.4. PE-PE Distribution of VPN Routing Information. . . . . . 51
4.4.1. Options for VPN Routing in the SP. . . . . . . . 52
4.4.2. VPN Forwarding Instances . . . . . . . . . . . . 52
4.4.3. Per-VPN Routing . . . . . . . . . . . . . . . . 53
4.4.4. Aggregated Routing Model . . . . . . . . . . . . 54
4.4.4.1. Aggregated Routing with OSPF or IS-IS. 55
4.4.4.2. Aggregated Routing with BGP. . . . . . 56
4.4.5. Scalability and Stability of Routing with Layer
3 PE-based VPNs. . . . . . . . . . . . . . . . . 59
4.5. Quality of Service, SLAs, and IP Differentiated Services 61
4.5.1. IntServ/RSVP . . . . . . . . . . . . . . . . . . 61
4.5.2. DiffServ . . . . . . . . . . . . . . . . . . . . 62
4.6. Concurrent Access to VPNs and the Internet . . . . . . . 62
4.7. Network and Customer Management of VPNs. . . . . . . . . 63
4.7.1. Network and Customer Management. . . . . . . . . 63
4.7.2. Segregated Access of VPN Information . . . . . . 64
5. Interworking Interface . . . . . . . . . . . . . . . . . . . . 66
5.1. Interworking Function. . . . . . . . . . . . . . . . . . 66
5.2. Interworking Interface . . . . . . . . . . . . . . . . . 66
5.2.1. Tunnels at the Interworking Interface. . . . . . 67
5.3. Support of Additional Services . . . . . . . . . . . . . 68
5.4. Scalability Discussion . . . . . . . . . . . . . . . . . 69
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 69
6.1. System Security. . . . . . . . . . . . . . . . . . . . . 70
6.2. Access Control . . . . . . . . . . . . . . . . . . . . . 70
6.3. Endpoint Authentication . . . . . . . . . . . . . . . . 70
6.4. Data Integrity . . . . . . . . . . . . . . . . . . . . . 71
6.5. Confidentiality. . . . . . . . . . . . . . . . . . . . . 71
6.6. User Data and Control Data . . . . . . . . . . . . . . . 72
6.7. Security Considerations for Inter-SP VPNs . . . . . . . 72
Appendix A: Optimizations for Tunnel Forwarding. . . . . . . . . . 73
A.1. Header Lookups in the VFIs . . . . . . . . . . . . . . . 73
A.2. Penultimate Hop Popping for MPLS . . . . . . . . . . . . 73
A.3. Demultiplexing to Eliminate the Tunnel Egress VFI Lookup 74
Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 75
Normative References . . . . . . . . . . . . . . . . . . . . . . . 76
Informative References . . . . . . . . . . . . . . . . . . . . . . 76
Contributors’ Addresses. . . . . . . . . . . . . . . . . . . . . . 80
1. Introduction
1.1. Objectives of the Document
This document provides a framework for Layer 3 Provider-Provisioned
Virtual Private Networks (PPVPNs). This framework is intended to aid
in standardizing protocols and mechanisms to support interoperable
layer 3 PPVPNs.
The term "provider-provisioned VPNs" refers to Virtual Private
Networks (VPNs) for which the Service Provider (SP) participates in
management and provisioning of the VPN, as defined in section 1.3.
There are multiple ways in which a provider can participate in
managing and provisioning a VPN; therefore, there are multiple
different types of PPVPNs. The framework document discusses layer 3
VPNs (as defined in section 1.3).
First, this document provides a reference model for layer 3 PPVPNs.
Then technical aspects of layer 3 PPVPN operation are discussed,
first from the customer’s point of view, then from the providers
point of view. Specifically, this includes discussion of the
technical issues which are important in the design of standards and
mechanisms for the operation and support of layer 3 PPVPNs.
Furthermore, technical aspects of layer 3 PPVPN interworking are
clarified. Finally, security issues as they apply to layer 3 PPVPNs
are addressed.
This document takes a "horizontal description" approach. For each
technical issue, it describes multiple approaches. To specify a
particular PPVPN strategy, one must choose a particular way of
solving each problem, but this document does not make choices, and
does not select any particular approach to support VPNs.
The "vertical description" approach is taken in other documents,
viz., in the documents that describe particular PPVPN solutions.
Note that any specific solution will need to make choices based on SP
requirements, customer needs, implementation cost, and engineering
tradeoffs. Solutions will need to chose between flexibility
(supporting multiple options) and conciseness (selection of specific
options in order to simplify implementation and deployment). While a
framework document can discuss issues and criteria which are used as
input to these choices, the specific selection of a solution is
outside of the scope of a framework document.
1.2. Overview of Virtual Private Networks
The term "Virtual Private Network" (VPN) refers to a set of
communicating sites, where (a) communication between sites outside
the set and sites inside the set is restricted, but (b) communication
between sites in the VPN takes place over a network infrastructure
that is also used by sites which are not in the VPN. The fact that
the network infrastructure is shared by multiple VPNs (and possibly
also by non-VPN traffic) is what distinguishes a VPN from a private
network. We will refer to this shared network infrastructure as the
"VPN Backbone".
The logical structure of the VPN, such as addressing, topology,
connectivity, reachability, and access control, is equivalent to part
of or all of a conventional private network using private facilities
[RFC2764] [VPN-2547BIS].
In this document, we are concerned only with the case where the
shared network infrastructure (VPN backbone) is an IP and/or MPLS
network. Further, we are concerned only with the case where the
Service Provider’s edge devices, whether at the provider edge (PE) or
at the Customer Edge (CE), determine how to route VPN traffic by
looking at the IP and/or MPLS headers of the packets they receive
from the customer’s edge devices; this is the distinguishing feature
of Layer 3 VPNs.
In some cases, one SP may offer VPN services to another SP. The
former SP is known as a carrier of carriers, and the service it
offers is known as "carrier of carriers" service. In this document,
in cases where the customer could be either an enterprise or SP
network, we will make use of the term "customer" to refer to the user
of the VPN services. Similarly we will use the term "customer
network" to refer to the user’s network.
VPNs may be intranets, in which the multiple sites are under the
control of a single customer administration, such as multiple sites
of a single company. Alternatively, VPNs may be extranets, in which
the multiple sites are controlled by administrations of different
customers, such as sites corresponding to a company, its suppliers,
and its customers.
Figure 1.1. illustrates an example network, which will be used in
the discussions below. PE1 and PE2 are Provider Edge devices within
an SP network. CE1, CE2, and CE3 are Customer Edge devices within a
customer network. Routers r3, r4, r5, and r6 are IP routers internal
to the customer sites.
............ ................. ............
. . . . . .
. +---+ +-------+ +-------+ +---+ .
. r3---| | | | | |----|CE2|---r5 .
. | | | | | | +---+ .
. |CE1|----| PE1 | | PE2 | : .
. | | | | | | +---+ .
. r4---| | | | | |----|CE3|---r6 .
. +---+ +-------+ +-------+ +---+ .
. Customer . . Service . . Customer .
. site 1 . . provider(s) . . site 2 .
............ ................. ............
Figure 1.1.: VPN interconnecting two sites.
In many cases, Provider Edge (PE) and Customer Edge (CE) devices may
be either routers or LSRs.
In this document, the Service Providers’ network is an IP or MPLS
network. It is desired to interconnect the customer network sites
via the Service Providers’ network. Some VPN solutions require that
the VPN service be provided either over a single SP network, or over
a small set of closely cooperating SP networks. Other VPN solutions
are intended to allow VPN service to be provided over an arbitrary
set of minimally cooperating SP networks (i.e., over the public
Internet).
In many cases, customer networks will make use of private IP
addresses [RFC1918] or other non-unique IP address (i.e.,
unregistered addresses); there is no guarantee that the IP addresses
used in the customer network are globally unique. The addresses used
in one customer’s network may overlap the addresses used in others.
However, a single PE device can be used to provide VPN service to
multiple customer networks, even if those customer networks have
overlapping addresses. In PE-based layer 3 VPNs, the PE devices may
route the VPN traffic based on the customer addresses found in the IP
headers; this implies that the PE devices need to maintain a level of
isolation between the packets from different customer networks. In
CE-based layer 3 VPNs, the PEs do not make routing decisions based on
the customer’s private addresses, so this issue does not arise. For
either PE or CE-based VPNs, the fact that the VPNs do not necessarily
use globally unique address spaces also implies that IP packets from
a customer network cannot be transmitted over the SP network in their
native form. Instead, some form of encapsulation/tunneling must be
used.
Tunneling is also important for other reasons, such as providing
isolation between different customer networks, allowing a wide range
of protocols to be carried over an SP network, etc. Different QoS
and security characteristics may be associated with different
tunnels.
1.3. Types of VPNs
This section describes multiple types of VPNs, and some of the
engineering tradeoffs between different types. It is not up to this
document to decide between different types of VPNs. Different types
of VPNs may be appropriate in different situations.
There is a wide spectrum of types of possible VPNs, and it is
difficult to split the types of VPNs into clearly distinguished
categories.
As an example, consider a company making use of a private network,
with several sites interconnected via leased lines. All routing is
done via routers which are internal to the private network.
At some point, the administrator of the private network might decide
to replace the leased lines by ATM links (using an ATM service from
an SP). Here again all IP-level routing is done between customer
premises routers, and managed by the private network administrator.
In order to reduce the network management burden on the private
network, the company may decide to make use of a provider-provisioned
CE devices [VPN-CE]. Here the operation of the network might be
unchanged, except that the CE devices would be provided by and
managed by an SP.
The SP might decide that it is too difficult to manually configure
each CE-CE link. This might lead the SP to replace the ATM links
with a layer 2 VPN service between CE devices [VPN-L2]. Auto-
discovery might be used to simplify configuration of links between CE
devices, and an MPLS service might be used between CE devices instead
of an ATM service (for example, to take advantage of the provider’s
high speed IP or MPLS backbone).
After a while the SP might decide that it is too much trouble to be
managing a large number of devices at the customers’ premises, and
might instead physically move these routers to be on the provider
premises. Each edge router at the provider premises might
nonetheless be dedicated to a single VPN. The operation might remain
unchanged (except that links from the edge routers to other routers
in the private network become MAN links instead of LAN links, and the
link from the edge routers to provider core routers become LAN links
instead of MAN links). The routers in question can now be considered
to be provider edge routers, and the service provided by the SP has
now become essentially a layer 3 VPN service.
In order to minimize the cost of equipment, the provider might decide
to replace several dedicated PE devices with a single physical router
with the capability of running virtual routers (VR) [VPN-VR].
Protocol operation may remain unchanged. In this case the provider
is offering a layer 3 VPN service making use of a VR capability.
Note that autodiscovery might be used in a manner which is very
similar to how it had been done in the layer 2 VPN case described
above (for example, BGP might be used between VRs for discovery of
other VRs supporting the same VPN).
Finally, in order to simplify operation of routing protocols for the
private network over the SP network, the provider might decide to
aggregate multiple instances of routing into a single instance of BGP
[VPN-2547BIS].
In practice it is highly unlikely that any one network would actually
evolve through all of these approaches at different points in time.
However, this example illustrates that there is a continuum of
possible approaches, and each approach is relatively similar to at
least some of the other possible approaches for supporting VPN
services. Some techniques (such as auto-discovery of VPN sites) may