As per Relevance of the word tunneling, we have this rfc below:
Network Working Group B.
Request for Comments: 2764 A.
Category: Informational Nortel
J.
Telia
G.
A.
Lucent
February 2000
A Framework for IP Based Virtual Private
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
IESG
This document is not the product of an IETF Working Group. The
currently has no effort underway to standardize a specific
framework
This document describes a framework for Virtual Private
(VPNs) running across IP backbones. It discusses the
different types of VPNs, their respective requirements, and
specific mechanisms that could be used to implement each type of
using existing or proposed specifications. The objective of
document is to serve as a framework for related protocol
in order to develop the full set of specifications required
widespread deployment of interoperable VPN solutions
Gleeson, et al. Informational [Page 1]
RFC 2764 IP Based Virtual Private Networks February 2000
Table of
1.0 Introduction ................................................ 4
2.0 VPN Application and Implementation Requirements ............. 5
2.1 General VPN Requirements .................................... 5
2.1.1 Opaque Packet Transport: ................................. 6
2.1.2 Data Security ............................................. 7
2.1.3 Quality of Service Guarantees ............................. 7
2.1.4 Tunneling Mechanism ....................................... 8
2.2 CPE and Network Based VPNs .................................. 8
2.3 VPNs and Extranets .......................................... 9
3.0 VPN Tunneling ............................................... 10
3.1 Tunneling Protocol Requirements for VPNs .................... 11
3.1.1 Multiplexing .............................................. 11
3.1.2 Signalling Protocol ....................................... 12
3.1.3 Data Security ............................................. 13
3.1.4 Multiprotocol Transport ................................... 14
3.1.5 Frame Sequencing .......................................... 14
3.1.6 Tunnel Maintenance ........................................ 15
3.1.7 Large MTUs ................................................ 16
3.1.8 Minimization of Tunnel Overhead ........................... 16
3.1.9 Flow and congestion control ............................... 17
3.1.10 QoS / Traffic Management ................................. 17
3.2 Recommendations ............................................. 18
4.0 VPN Types: Virtual Leased Lines ............................ 18
5.0 VPN Types: Virtual Private Routed Networks ................. 20
5.1 VPRN Characteristics ........................................ 20
5.1.1 Topology .................................................. 23
5.1.2 Addressing ................................................ 24
5.1.3 Forwarding ................................................ 24
5.1.4 Multiple concurrent VPRN connectivity ..................... 24
5.2 VPRN Related Work ........................................... 24
5.3 VPRN Generic Requirements ................................... 25
5.3.1 VPN Identifier ............................................ 26
5.3.2 VPN Membership Information Configuration .................. 27
5.3.2.1 Directory Lookup ........................................ 27
5.3.2.2 Explicit Management Configuration ....................... 28
5.3.2.3 Piggybacking in Routing Protocols ....................... 28
5.3.3 Stub Link Reachability Information ........................ 30
5.3.3.1 Stub Link Connectivity Scenarios ........................ 30
5.3.3.1.1 Dual VPRN and Internet Connectivity ................... 30
5.3.3.1.2 VPRN Connectivity Only ................................ 30
5.3.3.1.3 Multihomed Connectivity ............................... 31
5.3.3.1.4 Backdoor Links ........................................ 31
5.3.3.1 Routing Protocol Instance ............................... 31
5.3.3.2 Configuration ........................................... 33
5.3.3.3 ISP Administered Addresses .............................. 33
5.3.3.4 MPLS Label Distribution Protocol ........................ 33
Gleeson, et al. Informational [Page 2]
RFC 2764 IP Based Virtual Private Networks February 2000
5.3.4 Intra-VPN Reachability Information ........................ 34
5.3.4.1 Directory Lookup ........................................ 34
5.3.4.2 Explicit Configuration .................................. 34
5.3.4.3 Local Intra-VPRN Routing Instantiations ................. 34
5.3.4.4 Link Reachability Protocol .............................. 35
5.3.4.5 Piggybacking in IP Backbone Routing Protocols ........... 36
5.3.5 Tunneling Mechanisms ...................................... 36
5.4 Multihomed Stub Routers ..................................... 37
5.5 Multicast Support ........................................... 38
5.5.1 Edge Replication .......................................... 38
5.5.2 Native Multicast Support .................................. 39
5.6 Recommendations ............................................. 40
6.0 VPN Types: Virtual Private Dial Networks ................... 41
6.1 L2TP protocol characteristics ............................... 41
6.1.1 Multiplexing .............................................. 41
6.1.2 Signalling ................................................ 42
6.1.3 Data Security ............................................. 42
6.1.4 Multiprotocol Transport ................................... 42
6.1.5 Sequencing ................................................ 42
6.1.6 Tunnel Maintenance ........................................ 43
6.1.7 Large MTUs ................................................ 43
6.1.8 Tunnel Overhead ........................................... 43
6.1.9 Flow and Congestion Control ............................... 43
6.1.10 QoS / Traffic Management ................................. 43
6.1.11 Miscellaneous ............................................ 44
6.2 Compulsory Tunneling ........................................ 44
6.3 Voluntary Tunnels ........................................... 46
6.3.1 Issues with Use of L2TP for Voluntary Tunnels ............. 46
6.3.2 Issues with Use of IPSec for Voluntary Tunnels ............ 48
6.4 Networked Host Support ...................................... 49
6.4.1 Extension of PPP to Hosts Through L2TP .................... 49
6.4.2 Extension of PPP Directly to Hosts: ...................... 49
6.4.3 Use of IPSec .............................................. 50
6.5 Recommendations ............................................. 50
7.0 VPN Types: Virtual Private LAN Segment ..................... 50
7.1 VPLS Requirements ........................................... 51
7.1.1 Tunneling Protocols ....................................... 51
7.1.2 Multicast and Broadcast Support ........................... 52
7.1.3 VPLS Membership Configuration and Topology ................ 52
7.1.4 CPE Stub Node Types ....................................... 52
7.1.5 Stub Link Packet Encapsulation ............................ 53
7.1.5.1 Bridge CPE .............................................. 53
7.1.5.2 Router CPE .............................................. 53
7.1.6 CPE Addressing and Address Resolution ..................... 53
7.1.6.1 Bridge CPE .............................................. 53
7.1.6.2 Router CPE .............................................. 54
7.1.7 VPLS Edge Node Forwarding and Reachability Mechanisms ..... 54
7.1.7.1 Bridge CPE .............................................. 54
Gleeson, et al. Informational [Page 3]
RFC 2764 IP Based Virtual Private Networks February 2000
7.1.7.2 Router CPE .............................................. 54
7.2 Recommendations ............................................. 55
8.0 Summary of Recommendations .................................. 55
9.0 Security Considerations ..................................... 56
10.0 Acknowledgements ........................................... 56
11.0 References ................................................. 56
12.0 Author Information ......................................... 61
13.0 Full Copyright Statement ................................... 62
1.0
This document describes a framework for Virtual Private
(VPNs) running across IP backbones. It discusses the
different types of VPNs, their respective requirements, and
specific mechanisms that could be used to implement each type of
using existing or proposed specifications. The objective of
document is to serve as a framework for related protocol
in order to develop the full set of specifications required
widespread deployment of interoperable VPN solutions
There is currently significant interest in the deployment of
private networks across IP backbone facilities. The
deployment of VPNs has been hampered, however, by the lack
interoperable implementations, which, in turn, derives from the
of general agreement on the definition and scope of VPNs
confusion over the wide variety of solutions that are all
by the term VPN. In the context of this document, a VPN is
defined as the 'emulation of a private Wide Area Network (WAN
facility using IP facilities' (including the public Internet,
private IP backbones). As such, there are as many types of VPNs
there are types of WANs, hence the confusion over what
constitutes a VPN
In this document a VPN is modeled as a connectivity object.
may be attached to a VPN, and VPNs may be interconnected together,
the same manner as hosts today attach to physical networks,
physical networks are interconnected together (e.g., via bridges
routers). Many aspects of networking, such as addressing,
mechanism, learning and advertising reachability, quality of
(QoS), security, and firewalling, have common solutions across
physical and virtual networks, and many issues that arise in
discussion of VPNs have direct analogues with those issues
implemented in physical networks. The introduction of VPNs does
create the need to reinvent networking, or to introduce entirely
paradigms that have no direct analogue with existing
networks. Instead it is often useful to first examine how
particular issue is handled in a physical network environment,
then apply the same principle to an environment which
Gleeson, et al. Informational [Page 4]
RFC 2764 IP Based Virtual Private Networks February 2000
virtual as well as physical networks, and to develop
extensions and enhancements when necessary. Clearly
mechanisms that are common across both physical and virtual
facilitates the introduction of VPNs into existing networks, and
reduces the effort needed for both standards and product development
since existing solutions can be leveraged
This framework document proposes a taxonomy of a specific set of
types, showing the specific applications of each, their
requirements, and the specific types of mechanisms that may be
appropriate for their implementation. The intent of this document
to serve as a framework to guide a coherent discussion of
specific modifications that may be needed to existing IP
in order to develop a full range of interoperable VPN solutions
The document first discusses the likely expectations customers
of any type of VPN, and the implications of these for the ways
which VPNs can be implemented. It also discusses the
between Customer Premises Equipment (CPE) based solutions,
network based solutions. Thereafter it presents a taxonomy of
various VPN types and their respective requirements. It
outlines suggested approaches to their implementation, hence
pointing to areas for future standardization
Note also that this document only discusses implementations of
across IP backbones, be they private IP networks, or the
Internet. The models and mechanisms described here are intended
apply to both IPV4 and IPV6 backbones. This document
does not discuss means of constructing VPNs using native
onto switched backbones - e.g., VPNs constructed using the
Emulation over ATM (LANE) [1] or Multiprotocol over ATM (MPOA) [2]
protocols operating over ATM backbones. Where IP backbones
constructed using such protocols, by interconnecting routers over
switched backbone, the VPNs discussed operate on top of this
network, and hence do not directly utilize the native mechanisms
the underlying backbone. Native VPNs are restricted to the scope
the underlying backbone, whereas IP based VPNs can extend to
extent of IP reachability. Native VPN protocols are clearly
the scope of the IETF, and may be tackled by such bodies as the
Forum
2.0 VPN Application and Implementation
2.1 General VPN
There is growing interest in the use of IP VPNs as a more
effective means of building and deploying private
networks for multi-site communication than with existing approaches
Gleeson, et al. Informational [Page 5]
RFC 2764 IP Based Virtual Private Networks February 2000
Existing private networks can be generally categorized into two
- dedicated WANs that permanently connect together multiple sites
and dial networks, that allow on-demand connections through
Public Switched Telephone Network (PSTN) to one or more sites in
private network
WANs are typically implemented using leased lines or
circuits - for instance, Frame Relay or ATM connections - between
multiple sites. CPE routers or switches at the various sites
these dedicated facilities together and allow for connectivity
the network. Given the cost and complexity of such
facilities and the complexity of CPE device configuration,
networks are generally not fully meshed, but instead have some
of hierarchical topology. For example remote offices could
connected directly to the nearest regional office, with the
offices connected together in some form of full or partial mesh
Private dial networks are used to allow remote users to connect
an enterprise network using PSTN or Integrated Services
Network (ISDN) links. Typically, this is done through the
of Network Access Servers (NASs) at one or more central sites.
dial into such NASs, which interact with Authentication
Authorization, and Accounting (AAA) servers to verify the identity
the user, and the set of services that the user is authorized
receive
In recent times, as more businesses have found the need for
speed Internet connections to their private corporate networks,
has been significant interest in the deployment of CPE based
running across the Internet. This has been driven typically by
ubiquity and distance insensitive pricing of current
services, that can result in significantly lower costs than
dedicated or leased line services
The notion of using the Internet for private communications is
new, and many techniques, such as controlled route leaking, have
used for this purpose [3]. Only in recent times, however, have
appropriate IP mechanisms needed to meet customer requirements
VPNs all come together. These requirements include the following
2.1.1 Opaque Packet Transport
The traffic carried within a VPN may have no relation to the
on the IP backbone, either because the traffic is multiprotocol,
because the customer's IP network may use IP addressing unrelated
that of the IP backbone on which the traffic is transported.
particular, the customer's IP network may use non-unique, private
addressing [4].
Gleeson, et al. Informational [Page 6]
RFC 2764 IP Based Virtual Private Networks February 2000
2.1.2 Data
In general customers using VPNs require some form of data security
There are different trust models applicable to the use of VPNs.
such model is where the customer does not trust the service
to provide any form of security, and instead implements a VPN
CPE devices that implement firewall functionality and that
connected together using secure tunnels. In this case the
provider is used solely for IP packet transport
An alternative model is where the customer trusts the
provider to provide a secure managed VPN service. This is similar
the trust involved when a customer utilizes a public switched
Relay or ATM service, in that the customer trusts that packets
not be misdirected, injected into the network in an
manner, snooped on, modified in transit, or subjected to
analysis by unauthorized parties
With this model providing firewall functionality and secure
transport services is the responsibility of the service provider
Different levels of security may be needed within the
backbone, depending on the deployment scenario used. If the
traffic is contained within a single provider's IP backbone
strong security mechanisms, such as those provided by the IP
protocol suite (IPSec) [5], may not be necessary for tunnels
backbone nodes. If the VPN traffic traverses networks or
owned by multiple administrations then strong security mechanisms
be appropriate. Also a strong level of security may be applied by
provider to customer traffic to address a customer perception that
networks, and particularly the Internet, are insecure. Whether
not this perception is correct it is one that must be addressed
the VPN implementation
2.1.3 Quality of Service
In addition to ensuring communication privacy, existing
networking techniques, building upon physical or link
mechanisms, also offer various types of quality of
guarantees. In particular, leased and dial up lines offer
bandwidth and latency guarantees, while dedicated
technologies like ATM and Frame Relay have extensive mechanisms
similar guarantees. As IP based VPNs become more widely deployed
there will be market demand for similar guarantees, in order
ensure end to end application transparency. While the ability of
based VPNs to offer such guarantees will depend greatly upon
commensurate capabilities of the underlying IP backbones, a
framework must also address the means by which VPN systems
utilize such capabilities, as they evolve
Gleeson, et al. Informational [Page 7]
RFC 2764 IP Based Virtual Private Networks February 2000
2.1.4 Tunneling
Together, the first two of the requirements listed above imply
VPNs must be implemented through some form of IP tunneling mechanism
where the packet formats and/or the addressing used within the
can be unrelated to that used to route the tunneled packets
the IP backbone. Such tunnels, depending upon their form,
provide some level of intrinsic data security, or this can also
enhanced using other mechanisms (e.g., IPSec).
Furthermore, as discussed later, such tunneling mechanisms can
be mapped into evolving IP traffic management mechanisms. There
already defined a large number of IP tunneling mechanisms. Some
these are well suited to VPN applications, as discussed in
3.0.
2.2 CPE and Network Based
Most current VPN implementations are based on CPE equipment.
capabilities are being integrated into a wide variety of CPE devices
ranging from firewalls to WAN edge routers and specialized
termination devices. Such equipment may be bought and deployed
customers, or may be deployed (and often remotely managed) by
providers in an outsourcing service
There is also significant interest in 'network based VPNs', where
operation of the VPN is outsourced to an Internet Service
(ISP), and is implemented on network as opposed to CPE equipment
There is significant interest in such solutions both by
seeking to reduce support costs and by ISPs seeking new
sources. Supporting VPNs in the network allows the use of
mechanisms which may lead to highly efficient and cost effective
solutions, with common equipment and operations support
across large numbers of customers
Most of the mechanisms discussed below can apply to either CPE
or network based VPNs. However particular mechanisms are likely
prove applicable only to the latter, since they leverage tools (e.g.,
piggybacking on routing protocols) which are accessible only to
and which are unlikely to be made available to any customer, or
hosted on ISP owned and operated CPE, due to the problems
coordinating joint management of the CPE gear by both the ISP and
customer. This document will indicate which techniques are likely
apply only to network based VPNs
Gleeson, et al. Informational [Page 8]
RFC 2764 IP Based Virtual Private Networks February 2000
2.3 VPNs and
The term 'extranet' is commonly used to refer to a scenario
two or more companies have networked access to a limited amount
each other's corporate data. For example a manufacturing
might use an extranet for its suppliers to allow it to
databases for the pricing and availability of components, and then
order and track the status of outstanding orders. Another example
joint software development, for instance, company A allows
development group within company B to access its operating
source code, and company B allows one development group in company
to access its security software. Note that the access policies
get arbitrarily complex. For example company B may
restrict access to its security software to groups in
geographic locations to comply with export control laws, for example
A key feature of an extranet is thus the control of who can
what data, and this is essentially a policy decision.
decisions are typically enforced today at the interconnection
between different domains, for example between a private network
the Internet, or between a software test lab and the rest of
company network. The enforcement may be done via a firewall,
with access list functionality, application gateway, or any
device capable of applying policy to transit traffic.
controls may be implemented within a corporate network, in
to between corporate networks. Also the interconnections
networks could be a set of bilateral links, or could be a
network, perhaps maintained by an industry consortium. This
network could itself be a VPN or a physical network
Introducing VPNs into a network does not require any change to
model. Policy can be enforced between two VPNs, or between a VPN
the Internet, in exactly the same manner as is done today
VPNs. For example two VPNs could be interconnected, which
administration locally imposing its own policy controls, via
firewall, on all traffic that enters its VPN from the outside
whether from another VPN or from the Internet
This model of a VPN provides for a separation of policy from
underlying mode of packet transport used. For example, a router
direct voice traffic to ATM Virtual Channel Connections (VCCs)
guaranteed QoS, non-local internal company traffic to secure tunnels
and other traffic to a link to the Internet. In the past the
tunnels may have been frame relay circuits, now they may also
secure IP tunnels or MPLS Label Switched Paths (LSPs
Gleeson, et al. Informational [Page 9]
RFC 2764 IP Based Virtual Private Networks February 2000
Other models of a VPN are also possible. For example there is
model whereby a set of application flows is mapped into a VPN.
the policy rules imposed by a network administrator can get
complex, the number of distinct sets of application flows that
used in the policy rulebase, and hence the number of VPNs, can
grow quite large, and there can be multiple overlapping VPNs
However there is little to be gained by introducing such
complexity into a network. Instead a VPN should be viewed as
direct analogue to a physical network, as this allows the
of existing protocols and procedures, and the current expertise
skill sets of network administrators and customers
3.0 VPN
As noted above in section 2.1, VPNs must be implemented using
form of tunneling mechanism. This section looks at the
requirements for such VPN tunneling mechanisms. A number
characteristics and aspects common to any link layer protocol
taken and compared with the features offered by existing
protocols. This provides a basis for comparing different
and is also useful to highlight areas where existing
protocols could benefit from extensions to better support
operation in a VPN environment
An IP tunnel connecting two VPN endpoints is a basic building
from which a variety of different VPN services can be constructed
An IP tunnel operates as an overlay across the IP backbone, and
traffic sent through the tunnel is opaque to the underlying
backbone. In effect the IP backbone is being used as a link
technology, and the tunnel forms a point-to-point link
A VPN device may terminate multiple IP tunnels and forward
between these tunnels and other network interfaces in different ways
In the discussion of different types of VPNs, in later sections
this document, the primary distinguishing characteristic of
different types is the manner in which packets are forwarded
interfaces (e.g., bridged or routed). There is a direct analogy
how existing networking devices are characterized today. A two-
repeater just forwards packets between its ports, and does
examine the contents of the packet. A bridge forwards packets
Media Access Control (MAC) layer information contained in the packet
while a router forwards packets using layer 3 addressing
contained in the packet. Each of these three scenarios has a
VPN analogue, as discussed later. Note that an IP tunnel is
as just another sort of link, which can be concatenated with
link, bound to a bridge forwarding table, or bound to an
forwarding table, depending on the type of VPN
Gleeson, et al. Informational [Page 10]
RFC 2764 IP Based Virtual Private Networks February 2000
The following sections look at the requirements for a generic
tunneling protocol that can be used as a basic building block
construct different types of VPNs
3.1 Tunneling Protocol Requirements for
There are numerous IP tunneling mechanisms, including IP/IP [6],
Generic Routing Encapsulation (GRE) tunnels [7], Layer 2
Protocol (L2TP) [8], IPSec [5], and Multiprotocol Label
(MPLS) [9]. Note that while some of these protocols are not
thought of as tunneling protocols, they do each allow for
transport of frames as packet payload across an IP network,
forwarding disjoint from the address fields of the
packets
Note, however, that there is one significant distinction between
of the IP tunneling protocols mentioned above, and MPLS. MPLS can
viewed as a specific link layer for IP, insofar as MPLS
mechanisms apply only within the scope of an MPLS network, whereas
based mechanisms extend to the extent of IP reachability. As such
VPN mechanisms built directly upon MPLS tunneling mechanisms cannot
by definition, extend outside the scope of MPLS networks, any more
than, for instance, ATM based mechanisms such as LANE can
outside of ATM networks. Note however, that an MPLS network can
many different link layer technologies, and so, like an IP network
its scope is not limited by the specific link layers used. A
of proposals for defining a set of mechanisms to allow
interoperable VPNs specifically over MPLS networks have also
produced ([10] [11] [12] [13], [14] and [15]).
There are a number of desirable requirements for a VPN
mechanism, however, that are not all met by the existing
mechanisms. These requirements include
3.1.1
There are cases where multiple VPN tunnels may be needed between
same two IP endpoints. This may be needed, for instance, in
where the VPNs are network based, and each end point
multiple customers. Traffic for different customers travels
separate tunnels between the same two physical devices.
multiplexing field is needed to distinguish which packets belong
which tunnel. Sharing a tunnel in this manner may also reduce
latency and processing burden of tunnel set up. Of the existing
tunneling mechanisms, L2TP (via the tunnel-id and session-id fields),
MPLS (via the label) and IPSec (via the Security Parameter
(SPI) field) have a multiplexing mechanism. Strictly speaking
does not have a multiplexing field. However the key field, which
Gleeson, et al. Informational [Page 11]
RFC 2764 IP Based Virtual Private Networks February 2000
intended to be used for authenticating the source of a packet,
sometimes been used as a multiplexing field. IP/IP does not have
multiplexing field
The IETF [16] and the ATM Forum [17] have standardized on a
format for a globally unique identifier used to identify a VPN (
VPN-ID). A VPN-ID can be used in the control plane, to bind a
to a VPN at tunnel establishment time, or in the data plane,
identify the VPN associated with a packet, on a per-packet basis.
the data plane a VPN encapsulation header can be used by MPLS,
and other tunneling mechanisms to aggregate packets for
VPNs over a single tunnel. In this case an explicit indication
VPN-ID is included with every packet, and no use is made of
tunnel specific multiplexing field. In the control plane a VPN-
field can be included in any tunnel establishment signalling
to allow for the association of a tunnel (e.g., as identified by
SPI field) with a VPN. In this case there is no need for a VPN-ID
be included with every data packet. This is discussed further
section 5.3.1.
3.1.2 Signalling
There is some configuration information that must be known by an
point in advance of tunnel establishment, such as the IP address
the remote end point, and any relevant tunnel attributes required
such as the level of security needed. Once this information
available, the actual tunnel establishment can be completed in one
two ways - via a management operation, or via a signalling
that allows tunnels to be established dynamically
An example of a management operation would be to use an
Management Information Base (MIB) to configure various
parameters, e.g., MPLS labels, source addresses to use for IP/IP
GRE tunnels, L2TP tunnel-ids and session-ids, or security
parameters for IPSec
Using a signalling protocol can significantly reduce the
burden however, and as such, is essential in many
scenarios. It reduces the amount of configuration needed, and
reduces the management co-ordination needed if a VPN spans
administrative domains. For example, the value of the
field, described above, is local to the node assigning the value,
can be kept local if distributed via a signalling protocol,
than being first configured into a management station and
distributed to the relevant nodes. A signalling protocol also
nodes that are mobile or are only intermittently connected
establish tunnels on demand
Gleeson, et al. Informational [Page 12]
RFC 2764 IP Based Virtual Private Networks February 2000
When used in a VPN environment a signalling protocol should allow
the transport of a VPN-ID to allow the resulting tunnel to
associated with a particular VPN. It should also allow
attributes to be exchanged or negotiated, for example the use
frame sequencing or the use of multiprotocol transport. Note
the role of the signalling protocol need only be to negotiate
attributes, not to carry information about how the tunnel is used
for example whether the frames carried in the tunnel are to
forwarded at layer 2 or layer 3. (This is similar to Q.2931
signalling - the same signalling protocol is used to set up
IP logical subnetworks as well as for LANE emulated LANs
Of the various IP tunneling protocols, the following ones support
signalling protocol that could be adapted for this purpose: L2TP (
L2TP control protocol), IPSec (the Internet Key Exchange (IKE
protocol [18]), and GRE (as used with mobile-ip tunneling [19]).
there are two MPLS signalling protocols that can be used to
LSP tunnels. One uses extensions to the MPLS Label
Protocol (LDP) protocol [20], called Constraint-Based Routing
(CR-LDP) [21], and the other uses extensions to the
Reservation Protocol (RSVP) for LSP tunnels [22].
3.1.3 Data
A VPN tunneling protocol must support mechanisms to allow
whatever level of security may be desired by customers,
authentication and/or encryption of various strengths. None of
tunneling mechanisms discussed, other than IPSec, have
security mechanisms, but rely upon the security characteristics
the underlying IP backbone. In particular, MPLS relies upon
explicit labeling of label switched paths to ensure that
cannot be misdirected, while the other tunneling mechanisms can
be secured through the use of IPSec. For VPNs implemented over non
IP backbones (e.g., MPOA, Frame Relay or ATM virtual circuits),
security is implicitly provided by the layer two
infrastructure
Overall VPN security is not just a capability of the tunnels alone
but has to be viewed in the broader context of how packets
forwarded onto those tunnels. For example with VPRNs
with virtual routers, the use of separate routing and
table instances ensures the isolation of traffic between VPNs
Packets on one VPN cannot be misrouted to a tunnel on a second
since those tunnels are not visible to the forwarding table of
first VPN
Gleeson, et al. Informational [Page 13]
RFC 2764 IP Based Virtual Private Networks February 2000
If some form of signalling mechanism is used by one VPN end point
dynamically establish a tunnel with another endpoint, then there is
requirement to be able to authenticate the party attempting
tunnel establishment. IPSec has an array of schemes for
purpose, allowing, for example, authentication to be based on pre
shared keys, or to use digital signatures and certificates.
tunneling schemes have weaker forms of authentication. In some
no authentication may be needed, for example if the tunnels
provisioned, rather than dynamically established, or if the
model in use does not require it
Currently the IPSec Encapsulating Security Payload (ESP)
[23] can be used to establish SAs that support either encryption
authentication or both. However the protocol specification
the use of an SA where neither encryption or authentication is used
In a VPN environment this "null/null" option is useful, since
aspects of the protocol (e.g., that it supports tunneling
multiplexing) may be all that is required. In effect the "null/null
option can be viewed as just another level of data security
3.1.4 Multiprotocol
In many applications of VPNs, the VPN may carry opaque,
traffic. As such, the tunneling protocol used must also
multiprotocol transport. L2TP is designed to transport Point-to
Point Protocol (PPP) [24] packets, and thus can be used to
multiprotocol traffic since PPP itself is multiprotocol. GRE
provides for the identification of the protocol being tunneled
IP/IP and IPSec tunnels have no such protocol identification field
since the traffic being tunneled is assumed to be IP
It is possible to extend the IPSec protocol suite to allow for
transport of multiprotocol packets. This can be achieved,
example, by extending the signalling component of IPSec - IKE,
indicate the protocol type of the traffic being tunneled, or to
a packet multiplexing header (e.g., an LLC/SNAP header or GRE header
with each tunneled packet. This approach is similar to that used
the same purpose in ATM networks, where signalling is used
indicate the encapsulation used on the VCC, and where packets sent
the VCC can use either an LLC/SNAP header or be placed directly
the AAL5 payload, the latter being known as VC-multiplexing (
[25]).
3.1.5 Frame
One quality of service attribute required by customers of a VPN
be frame sequencing, matching the equivalent characteristic
physical leased lines or dedicated connections. Sequencing may
Gleeson, et al. Informational [Page 14]
RFC 2764 IP Based Virtual Private Networks February 2000
required for the efficient operation of particular end to
protocols or applications. In order to implement frame sequencing
the tunneling mechanism must support a sequencing field. Both L2
and GRE have such a field. IPSec has a sequence number field, but
is used by a receiver to perform an anti-replay check, not
guarantee in-order delivery of packets
It is possible to extend IPSec to allow the use of the
sequence field to guarantee in-order delivery of packets. This
be achieved, for example, by using IKE to negotiate whether or
sequencing is to be used, and to define an end point behaviour
preserves packet sequencing
3.1.6 Tunnel
The VPN end points must monitor the operation of the VPN tunnels
ensure that connectivity has not been lost, and to take
action (such as route recalculation) if there has been a failure
There are two approaches possible. One is for the tunneling
itself to periodically check in-band for loss of connectivity, and
provide an explicit indication of failure. For example L2TP has
optional keep-alive mechanism to detect non-operational tunnels
The other approach does not require the tunneling protocol itself
perform this function, but relies on the operation of some out-of
band mechanism to determine loss of connectivity. For example if
routing protocol such as Routing Information Protocol (RIP) [26]
Open Shortest Path First (OSPF) [27] is run over a tunnel mesh,
failure to hear from a neighbor within a certain period of time
result in the routing protocol declaring the tunnel to be down
Another out-of-band approach is to perform regular ICMP pings with
peer. This is generally sufficient assurance that the tunnel
operational, due to the fact the tunnel also runs across the same
backbone
When tunnels are established dynamically a distinction needs to
drawn between the static and dynamic tunnel information needed
Before a tunnel can be established some static information is
by a node, such as the identify of the remote end point and
attributes of the tunnel to propose and accept. This is
put in place as a result of a configuration operation. As a
of the signalling exchange to establish a tunnel, some dynamic
is established in each end point, such as the value of
multiplexing field or keys to be used. For example with IPSec,
establishment of a Security Association (SA) puts in place the
to be used for the lifetime of that SA
Gleeson, et al. Informational [Page 15]
RFC 2764 IP Based Virtual Private Networks February 2000
Different policies may be used as to when to trigger
establishment of a dynamic tunnel. One approach is to use a data
driven approach and to trigger tunnel establishment whenever there
data to be transferred, and to timeout the tunnel due to inactivity
This approach is particularly useful if resources for the tunnel
being allocated in the network for QoS purposes. Another approach
to trigger tunnel establishment whenever the static
configuration information is installed, and to attempt to keep
tunnel up all the time
3.1.7 Large
An IP tunnel has an associated Maximum Transmission Unit (MTU),
like a regular link. It is conceivable that this MTU may be
than the MTU of one or more individual hops along the path
tunnel endpoints. If so, some form of frame fragmentation will
required within the tunnel
If the frame to be transferred is mapped into one IP datagram,
IP fragmentation will occur when the IP datagram reaches a hop
an MTU smaller than the IP tunnel's MTU. This can have
performance implications at the router performing such mid-
fragmentation
An alternative approach is for the tunneling protocol itself
incorporate a segmentation and reassembly capability that operates
the tunnel level, perhaps using the tunnel sequence number and
end-of-message marker of some sort. (Note that multilink PPP uses
mechanism similar to this to fragment packets). This avoids IP
fragmentation within the tunnel itself. None of the
tunneling protocols support such a mechanism
3.1.8 Minimization of Tunnel
There is clearly benefit in minimizing the overhead of any
mechanisms. This is particularly important for the transport
jitter and latency sensitive traffic such as packetized voice
video. On the other hand, the use of security mechanisms, such
IPSec, do impose their own overhead, hence the objective should be
minimize overhead over and above that needed for security, and to
burden those tunnels in which security is not mandatory
unnecessary overhead
One area where the amount of overhead may be significant is
voluntary tunneling is used for dial-up remote clients connecting
a VPN, due to the typically low bandwidth of dial-up links. This
discussed further in section 6.3.
Gleeson, et al. Informational [Page 16]
RFC 2764 IP Based Virtual Private Networks February 2000
3.1.9 Flow and congestion
During the development of the L2TP protocol procedures were
for flow and congestion control. These were necessitated
because of the need to provide adequate performance over
networks when PPP compression is used, which, unlike IP
Compression Protocol (IPComp) [28], is stateful across packets
Another motivation was to accommodate devices with very
buffering, used for example to terminate low speed dial-up lines
However the flow and congestion control mechanisms defined in
final version of the L2TP specification are used only for the
channels, and not for data traffic
In general the interactions between multiple layers of flow
congestion control schemes can be very complex. Given
predominance of TCP traffic in today's networks and the fact that
has its own end-to-end flow and congestion control mechanisms, it
not clear that there is much benefit to implementing
mechanisms within tunneling protocols. Good flow and
control schemes, that can adapt to a wide variety of
conditions and deployment scenarios are complex to develop and test
both in themselves and in understanding the interaction with
schemes that may be running in parallel. There may be some benefit
however, in having the capability whereby a sender can shape
to the capacity of a receiver in some manner, and in providing
protocol mechanisms to allow a receiver to signal its capabilities
a sender. This is an area that may benefit from further study
Note also the work of the Performance Implications of
Characteristics (PILC) working group of the IETF, which is
how the properties of different network links can have an impact
the performance of Internet protocols operating over those links
3.1.10 QoS / Traffic
As noted above, customers may require that VPNs yield
behaviour to physical leased lines or dedicated connections
respect to such QoS parameters as loss rates, jitter, latency
bandwidth guarantees. How such guarantees could be delivered will
in general, be a function of the traffic management
of the VPN nodes themselves, and the access and backbone
across which they are connected
A full discussion of QoS and VPNs is outside the scope of
document, however by modeling a VPN tunnel as just another type
link layer, many of the existing mechanisms developed for
QoS over physical links can also be applied. For example at a
node, the mechanisms of policing, marking, queuing, shaping
Gleeson, et al. Informational [Page 17]
RFC 2764 IP Based Virtual Private Networks February 2000
scheduling can all be applied to VPN traffic with VPN-
parameters, queues and interfaces, just as for non-VPN traffic.
techniques developed for Diffserv, Intserv and for
engineering in MPLS are also applicable. See also [29] for
discussion of QoS and VPNs
It should be noted, however, that this model of tunnel operation
not necessarily consistent with the way in which specific
protocols are currently modeled. While a model is an aid
comprehension, and not part of a protocol specification,
differing models can complicate discussions, particularly if a
is misinterpreted as being part of a protocol specification or
constraining choice of implementation method. For example,
tunnel processing can be modeled both as an interface and as
attribute of a particular packet flow
3.2
IPSec is needed whenever there is a requirement for strong
or strong authentication. It also supports multiplexing and
signalling protocol - IKE. However extending the IPSec
suite to also cover the following areas would be beneficial, in
to better support the tunneling requirements of a VPN environment
- the transport of a VPN-ID when establishing an SA (3.1.2)
- a null encryption and null authentication option (3.1.3)
- multiprotocol operation (3.1.4)
- frame sequencing (3.1.5)
L2TP provides no data security by itself, and any PPP
mechanisms used do not apply to the L2TP protocol itself, so that
order for strong security to be provided L2TP must run over IPSec
Defining specific modes of operation for IPSec when it is used
support L2TP traffic will aid interoperability. This is currently
work item for the proposed L2TP working group
4.0 VPN Types: Virtual Leased
The simplest form of a VPN is a 'Virtual Leased Line' (VLL) service
In this case a point-to-point link is provided to a customer
connecting two CPE devices, as illustrated below. The link
type used to connect the CPE devices to the ISP nodes can be any
layer type, for example an ATM VCC or a Frame Relay circuit. The
devices can be either routers bridges or hosts
Gleeson, et al. Informational [Page 18]
RFC 2764 IP Based Virtual Private Networks February 2000
The two ISP nodes are both connected to an IP network, and an
tunnel is set up between them. Each ISP node is configured to
the stub link and the IP tunnel together at layer 2 (e.g., an ATM
and the IP tunnel). Frames are relayed between the two links.
example the ATM Adaptation Layer 5 (AAL5) payload is taken
encapsulated in an IPSec tunnel, and vice versa. The contents of
AAL5 payload are opaque to the ISP node, and are not examined there
+--------+ ----------- +--------+
+---+ | ISP | ( IP ) | ISP | +---+
|CPE|-------| edge |-----( backbone ) -----| edge |------|CPE
+---+ ATM | node | ( ) | node | ATM +---+
VCC +--------+ ----------- +--------+
<--------- IP Tunnel -------->
10.1.1.5 subnet = 10.1.1.4/30 10.1.1.6
Addressing used by customer (transparent to provider
Figure 4.1: VLL
To a customer it looks the same as if a single ATM VCC or Frame
circuit were used to interconnect the CPE devices, and the
could be unaware that part of the circuit was in fact
over an IP backbone. This may be useful, for example, if a
wishes to provide a LAN interconnect service using ATM as the
interface, but does not have an ATM network that
interconnects all possible customer sites
It is not necessary that the two links used to connect the
devices to the ISP nodes be of the same media type, but in this
the ISP nodes cannot treat the traffic in an opaque manner,
described above. Instead the ISP nodes must perform the functions
an interworking device between the two media types (e.g., ATM
Frame Relay), and perform functions such as LLC/SNAP to
conversion, mapping between ARP protocol variants and performing
media specific processing that may be expected by the CPE
(e.g., ATM OAM cell handling or Frame Relay XID exchanges).
The IP tunneling protocol used must support multiprotocol
and may need to support sequencing, if that characteristic
important to the customer traffic. If the tunnels are
using a signalling protocol, they may be set up in a data
manner, when a frame is received from a customer link and no
exists, or the tunnels may be established at provisioning time
kept up permanently
Gleeson, et al. Informational [Page 19]
RFC 2764 IP Based Virtual Private Networks February 2000
Note that the use of the term 'VLL' in this document is different
that used in the definition of the Diffserv Expedited Forwarding
Hop Behaviour (EF-PHB) [30]. In that document a VLL is used to
a low latency, low jitter, assured bandwidth path, which can
provided using the described PHB. Thus the focus there is
on link characteristics that are temporal in nature. In this
the term VLL does not imply the use of any specific QoS mechanism
Diffserv or otherwise. Instead the focus is primarily on
characteristics that are more topological in nature, (e.g., such
constructing a link which includes an IP tunnel as one segment of
link). For a truly complete emulation of a link layer both
temporal and topological aspects need to be taken into account
5.0 VPN Types: Virtual Private Routed
5.1 VPRN
A Virtual Private Routed Network (VPRN) is defined to be
emulation of a multi-site wide area routed network using
facilities. This section looks at how a network-based VPRN
can be provided. CPE-based VPRNs are also possible, but are
specifically discussed here. With network-based VPRNs many of
issues that need to be addressed are concerned with configuration
operational issues, which must take into account the split
administrative responsibility between the service provider and
service user
The distinguishing characteristic of a VPRN, in comparison to
types of VPNs, is that packet forwarding is carried out at
network layer. A VPRN consists of a mesh of IP tunnels between
routers, together with the routing capabilities needed to
traffic received at each VPRN node to the appropriate
site. Attached to the ISP routers are CPE routers connected via
or more links, termed 'stub' links. There is a VPRN
forwarding table at each ISP router to which members of the VPRN
connected. Traffic is forwarded between ISP routers, and between
routers and customer sites, using these forwarding tables,
contain network layer reachability information (in contrast to
Virtual Private LAN Segment type of VPN (VPLS) where the
tables contain MAC layer reachability information - see section 7.0).
An example VPRN is illustrated in the following diagram, which
3 ISP edge routers connected via a full mesh of IP tunnels, used
interconnect 4 CPE routers. One of the CPE routers is multihomed
the ISP network. In the multihomed case, all stub links may
active, or, as shown, there may be one primary and one or more
links to be used in case of failure of the primary. The term '
backdoor' link is used to refer to a link between two customer
Gleeson, et al. Informational [Page 20]
RFC 2764 IP Based Virtual Private Networks February 2000
that does not traverse the ISP network
10.1.1.0/30 +--------+ +--------+ 10.2.2.0/30
+---+ | ISP | IP tunnel | ISP | +---+
|CPE|-------| edge |<--------------------->| edge |-------|CPE
+---+ stub | router | 10.9.9.4/30 | router | stub +---+
link +--------+ +--------+ link :
| ^ | | ^ :
| | | --------------- | | :
| | +----( )----+ | :
| | ( IP BACKBONE ) | :
| | ( ) | :
| | --------------- | :
| | | | :
| |IP tunnel +--------+ IP tunnel| :
| | | ISP | | :
| +---------->| edge |<----------+ :
| 10.9.9.8/30 | router | 10.9.9.12/30 :
backup| +--------+ backdoor
link | | | link :
| stub link | | stub link :
| | | :
| +---+ +---+ :
+-------------|CPE| |CPE|.......................:
10.3.3.0/30 +---+ +---+ 10.4.4.0/30
Figure 5.1: VPRN
The principal benefit of a VPRN is that the complexity and
configuration of the CPE routers is minimized. To a CPE router,
ISP edge router appears as a neighbor router in the customer'
network, to which it sends all traffic, using a default route.
tunnel mesh that is set up to transfer traffic extends between
ISP edge routers, not the CPE routers. In effect the burden
tunnel establishment and maintenance and routing configuration
outsourced to the ISP. In addition other services needed for
operation of a VPN such as the provision of a firewall and
processing can be handled by a small number of ISP edge routers
rather than a large number of potentially heterogeneous CPE devices
The introduction and management of new services can also be
easily handled, as this can be achieved without the need to
any CPE equipment. This latter benefit is particularly
when there may be large numbers of residential subscribers using
services to access private corporate networks. In this respect
model is somewhat akin to that used for telephony services,
new services (e.g., call waiting) can be introduced with no change
subscriber equipment
Gleeson, et al. Informational [Page 21]
RFC 2764 IP Based Virtual Private Networks February 2000
The VPRN type of VPN is in contrast to one where the tunnel
extends to the CPE routers, and where the ISP network provides
2 connectivity alone. The latter case can be implemented either as
set of VLLs between CPE routers (see section 4.0), in which case
ISP network provides a set of layer 2 point-to-point links, or as
VPLS (see section 7.0), in which case the ISP network is used
emulate a multiaccess LAN segment. With these scenarios a
may have more flexibility (e.g., any IGP or any protocol can be
across all customer sites) but this usually comes at the expense of
more complex configuration for the customer. Thus, depending
customer requirements, a VPRN or a VPLS may be the more
solution
Because a VPRN carries out forwarding at the network layer, a
VPRN only directly supports a single network layer protocol.
multiprotocol support, a separate VPRN for each network
protocol could be used, or one protocol could be tunneled
another (e.g., non-IP protocols tunneled over an IP VPRN)
alternatively the ISP network could be used to provide layer 2
connectivity only, such as with a VPLS as mentioned above
The issues to be addressed for VPRNs include initial configuration
determination by an ISP edge router of the set of links that are
each VPRN, the set of other routers that have members in the VPRN
and the set of IP address prefixes reachable via each stub link
determination by a CPE router of the set of IP address prefixes to
forwarded to an ISP edge router, the mechanism used to
stub reachability information to the correct set of ISP routers,
the establishment and use of the tunnels used to carry the
traffic. Note also that, although discussed first for VPRNs, many
these issues also apply to the VPLS scenario described later,
the network layer addresses being replaced by link layer addresses
Note that VPRN operation is decoupled from the mechanisms used by
customer sites to access the Internet. A typical scenario would
for the ISP edge router to be used to provide both VPRN and
connectivity to a customer site. In this case the CPE router
has a default route pointing to the ISP edge router, with the
being responsible for steering private traffic to the VPRN and
traffic to the Internet, and providing firewall functionality
the two domains. Alternatively a customer site could have
connectivity via an ISP router not involved in the VPRN, or even
a different ISP. In this case the CPE device is responsible
splitting the traffic into the two domains and providing
functionality
Gleeson, et al. Informational [Page 22]
RFC 2764 IP Based Virtual Private Networks February 2000
5.1.1
The topology of a VPRN may consist of a full mesh of tunnels
each VPRN node, or may be an arbitrary topology, such as a set
remote offices connected to the nearest regional site, with
regional sites connected together via a full or partial mesh.
VPRNs using IP tunnels there is much less cost assumed with
meshing than in cases where physical resources (e.g., a leased line
must be allocated for each connected pair of sites, or where
tunneling method requires resources to be allocated in the
used to interconnect the edge routers (e.g., Frame Relay DLCIs).
full mesh topology yields optimal routing, since it precludes
need for traffic between two sites to traverse a third.
attraction of a full mesh is that there is no need to
topology information for the VPRN. Instead, given the member
of a VPRN, the topology is implicit. If the number of ISP
routers in a VPRN is very large, however, a full mesh topology
not be appropriate, due to the scaling issues involved, for example
the growth in the number of tunnels needed between sites, (which
n sites is n(n-1)/2), or the number of routing peers per router
Network policy may also lead to non full mesh topologies, for
an administrator may wish to set up the topology so that
between two remote sites passes through a central site, rather
go directly between the remote sites. It is also necessary to
with the scenario where there is only partial connectivity across
IP backbone under certain error conditions (e.g. A can reach B, and
can reach C, but A cannot reach C directly), which can occur
policy routing is being used
For a network-based VPRN, it is assumed that each customer site
router connects to an ISP edge router through one or more point-to
point stub links (e.g. leased lines, ATM or Frame Relay connections).
The ISP routers are responsible for learning and
reachability information amongst themselves. The CPE routers
learn the set of destinations reachable via each stub link,
this may be as simple as a default route
The stub links may either be dedicated links, set up
provisioning, or may be dynamic links set up on demand, for
using PPP, voluntary tunneling (see section 6.3), or ATM signalling
With dynamic links it is necessary to authenticate the 