< draft-gleeson-vpn-framework-02.txt   draft-gleeson-vpn-framework-03.txt >
Internet Engineering Task Force B. Gleeson, A. Lin Internet Engineering Task Force B. Gleeson, A. Lin
INTERNET DRAFT Nortel Networks INTERNET DRAFT Nortel Networks
Expires April 2000 J. Heinanen Expires May 2000 J. Heinanen
Telia Finland Telia Finland
G. Armitage G. Armitage
Bell Labs, Lucent Technologies Bell Labs, Lucent Technologies
A. Malis A. Malis
Lucent Technologies Lucent Technologies
A Framework for IP Based Virtual Private Networks A Framework for IP Based Virtual Private Networks
<draft-gleeson-vpn-framework-02.txt> <draft-gleeson-vpn-framework-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract Abstract
This document describes a framework for virtual private networks This document describes a framework for Virtual Private Networks
(VPN) running across IP backbones. It discusses the various (VPNs) running across IP backbones. It discusses the various
different types of VPNs, their respective requirements, and proposes different types of VPNs, their respective requirements, and proposes
specific mechanisms that could be used to implement each type of VPN specific mechanisms that could be used to implement each type of VPN
using existing or proposed specifications. The objective of this using existing or proposed specifications. The objective of this
document is to serve as a framework for related protocol development document is to serve as a framework for related protocol development
in order to develop the full set of specifications required for in order to develop the full set of specifications required for
widespread deployment of interoperable VPN solutions. widespread deployment of interoperable VPN solutions.
Table of Contents Table of Contents
1.0 Introduction ................................................ 3 1.0 Introduction ................................................ 4
2.0 VPN Application and Implementation Requirements ............. 4 2.0 VPN Application and Implementation Requirements ............. 6
2.1 CPE and Network Based VPNs .................................. 7 2.1 General VPN Requirements .................................... 6
2.2 VPNs and Extranets .......................................... 7 2.1.1 Opaque Packet Transport: ................................. 7
3.0 VPN Tunneling ............................................... 9 2.1.2 Data Security ............................................. 7
3.1 Tunneling Protocol Requirements for VPNs .................... 10 2.1.3 Quality of Service Guarantees ............................. 7
3.1.1 Multiplexing .............................................. 10 2.1.4 Tunneling Mechanism ....................................... 8
3.1.2 Signalling Protocol ....................................... 11 2.2 CPE and Network Based VPNs .................................. 8
3.1.3 Data Security ............................................. 12 2.3 VPNs and Extranets .......................................... 9
3.1.4 Multiprotocol Transport ................................... 13 3.0 VPN Tunneling ............................................... 10
3.1.5 Frame Sequencing .......................................... 13 3.1 Tunneling Protocol Requirements for VPNs .................... 11
3.1.6 Tunnel Maintenance ........................................ 14 3.1.1 Multiplexing .............................................. 11
3.1.7 Large MTUs ................................................ 15 3.1.2 Signalling Protocol ....................................... 12
3.1.8 Minimization of Tunnel Overhead ........................... 15 3.1.3 Data Security ............................................. 13
3.1.9 Flow and congestion control ............................... 15 3.1.4 Multiprotocol Transport ................................... 14
3.1.10 QoS / Traffic Management ................................. 16 3.1.5 Frame Sequencing .......................................... 15
3.2 Recommendations ............................................. 17 3.1.6 Tunnel Maintenance ........................................ 15
4.0 VPN Types: Virtual Leased Lines ............................ 17 3.1.7 Large MTUs ................................................ 16
5.0 VPN Types: Virtual Private Routed Networks ................. 18 3.1.8 Minimization of Tunnel Overhead ........................... 16
5.1 VPRN related work ........................................... 23 3.1.9 Flow and congestion control ............................... 17
5.2 VPRN Generic Requirements ................................... 24 3.1.10 QoS / Traffic Management ................................. 17
5.2.1 VPN Identifier ............................................ 24 3.2 Recommendations ............................................. 18
5.2.2 VPN Membership Information Configuration .................. 25 4.0 VPN Types: Virtual Leased Lines ............................ 18
5.2.3 Stub Link Reachability Information ........................ 28 5.0 VPN Types: Virtual Private Routed Networks ................. 20
5.2.4 Intra-VPN Reachability Information ........................ 32 5.1 VPRN Characteristics ........................................ 20
5.2.5 Tunneling Mechanisms ...................................... 34 5.1.1 Topology .................................................. 23
5.3 Multihomed Stub Routers ..................................... 35 5.1.2 Addressing ................................................ 24
5.4 Multicast Support ........................................... 36 5.1.3 Forwarding ................................................ 24
5.4.1 Edge Replication .......................................... 36 5.1.4 Multiple concurrent VPRN connectivity ..................... 24
5.4.2 Native Multicast Support .................................. 37 5.2 VPRN Related Work ........................................... 25
5.5 Recommendations ............................................. 38 5.3 VPRN Generic Requirements ................................... 25
6.0 VPN Types: Virtual Private Dial Networks ................... 38 5.3.1 VPN Identifier ............................................ 26
6.1 L2TP protocol characteristics ............................... 39 5.3.2 VPN Membership Information Configuration .................. 27
6.2 Compulsory Tunneling ........................................ 42 5.3.2.1 Directory Lookup ........................................ 27
6.3 Voluntary Tunnels ........................................... 43 5.3.2.2 Explicit Management Configuration ....................... 28
6.3 Networked Host Support ...................................... 46 5.3.2.3 Piggybacking in Routing Protocols ....................... 29
6.4 Recommendations ............................................. 47 5.3.3 Stub Link Reachability Information ........................ 30
7.0 VPN Types: Virtual Private LAN Segment ..................... 47 5.3.3.1 Stub Link Connectivity Scenarios ........................ 30
7.1 VPLS Requirements ........................................... 48 5.3.3.1.1 Dual VPRN and Internet Connectivity ................... 30
7.1.1 Tunneling Protocols ....................................... 48 5.3.3.1.2 VPRN Connectivity Only ................................ 30
7.1.2 Multicast and Broadcast Support ........................... 49 5.3.3.1.3 Multihomed Connectivity ............................... 31
7.1.3 VPLS Membership Configuration and Topology ................ 49 5.3.3.1.4 Backdoor Links ........................................ 31
7.1.4 CPE Stub Node Types ....................................... 49 5.3.3.1 Routing Protocol Instance ............................... 31
7.1.5 Stub Link Packet Encapsulation ............................ 50 5.3.3.2 Configuration ........................................... 33
7.1.6 CPE Addressing and Address Resolution ..................... 50 5.3.3.3 ISP Administered Addresses .............................. 33
7.1.7 VPLS Edge Node Forwarding and Reachability Mechanisms ..... 51 5.3.3.4 MPLS Label Distribution Protocol ........................ 33
7.2 Recommendations ............................................. 52 5.3.4 Intra-VPN Reachability Information ........................ 34
8.0 Summary of Recommendations .................................. 52 5.3.4.1 Directory Lookup ........................................ 34
9.0 Security considerations ..................................... 53 5.3.4.2 Explicit Configuration .................................. 34
10.0 Acknowledgements ........................................... 53 5.3.4.3 Local Intra-VPRN Routing Instantiations ................. 34
11.0 References ................................................. 53 5.3.4.4 Link Reachability Protocol .............................. 35
12.0 Author Information ......................................... 58 5.3.4.5 Piggybacking in IP Backbone Routing Protocols ........... 36
13.0 Full Copyright Statement ................................... 59 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 ................... 40
6.1 L2TP protocol characteristics ............................... 41
6.1.1 Multiplexing .............................................. 41
6.1.2 Signalling ................................................ 41
6.1.3 Data Security ............................................. 41
6.1.4 Multiprotocol Transport ................................... 42
6.1.5 Sequencing ................................................ 42
6.1.6 Tunnel Maintenance ........................................ 42
6.1.7 Large MTUs ................................................ 42
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 ............................................ 43
6.2 Compulsory Tunneling ........................................ 43
6.3 Voluntary Tunnels ........................................... 45
6.3.1 Issues with Use of L2TP for Voluntary Tunnels ............. 45
6.3.2 Issues with Use of IPSec for Voluntary Tunnels ............ 47
6.4 Networked Host Support ...................................... 48
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 .............................................. 49
6.5 Recommendations ............................................. 49
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 ........................... 51
7.1.3 VPLS Membership Configuration and Topology ................ 51
7.1.4 CPE Stub Node Types ....................................... 52
7.1.5 Stub Link Packet Encapsulation ............................ 52
7.1.5.1 Bridge CPE .............................................. 52
7.1.5.2 Router CPE .............................................. 52
7.1.6 CPE Addressing and Address Resolution ..................... 53
7.1.6.1 Bridge CPE .............................................. 53
7.1.6.2 Router CPE .............................................. 53
7.1.7 VPLS Edge Node Forwarding and Reachability Mechanisms ..... 53
7.1.7.1 Bridge CPE .............................................. 53
7.1.7.2 Router CPE .............................................. 54
7.2 Recommendations ............................................. 54
8.0 Summary of Recommendations .................................. 54
9.0 Security considerations ..................................... 55
10.0 Acknowledgements ........................................... 55
11.0 References ................................................. 56
12.0 Author Information ......................................... 60
13.0 Full Copyright Statement ................................... 61
1.0 Introduction 1.0 Introduction
This document describes a framework for virtual private networks This document describes a framework for Virtual Private Networks
(VPN) running across IP backbones. It discusses the various (VPNs) running across IP backbones. It discusses the various
different types of VPNs, their respective requirements, and proposes different types of VPNs, their respective requirements, and proposes
specific mechanisms that could be used to implement each type of VPN specific mechanisms that could be used to implement each type of VPN
using existing or proposed specifications. The objective of this using existing or proposed specifications. The objective of this
document is to serve as a framework for related protocol development document is to serve as a framework for related protocol development
in order to develop the full set of specifications required for in order to develop the full set of specifications required for
widespread deployment of interoperable VPN solutions. widespread deployment of interoperable VPN solutions.
There is currently significant interest in the deployment of virtual There is currently significant interest in the deployment of virtual
private networks (VPN), across IP backbone facilities. The private networks across IP backbone facilities. The widespread
widespread deployment of VPNs has been hampered, however, by the lack deployment of VPNs has been hampered, however, by the lack of
of interoperable implementations, which, in turn, derives from the interoperable implementations, which, in turn, derives from the lack
lack of general agreement on the definition and scope of VPNs and of general agreement on the definition and scope of VPNs and
confusion over the wide variety of solutions that are all described confusion over the wide variety of solutions that are all described
by the term VPN. In the context of this document, a VPN is simply by the term VPN. In the context of this document, a VPN is simply
defined as the 'emulation of a private wide area network (WAN) defined as the 'emulation of a private Wide Area Network (WAN)
facility using IP facilities' (including the public Internet, or facility using IP facilities' (including the public Internet, or
private IP backbones). As such, there are as many types of VPNs as private IP backbones). As such, there are as many types of VPNs as
there are types of WANs, hence the confusion over what exactly there are types of WANs, hence the confusion over what exactly
constitutes a VPN. constitutes a VPN.
In this document a VPN is modelled as a connectivity object. Hosts In this document a VPN is modelled as a connectivity object. Hosts
may be attached to a VPN, and VPNs may be interconnected together, in may be attached to a VPN, and VPNs may be interconnected together, in
the same manner as hosts today attach to physical networks, and the same manner as hosts today attach to physical networks, and
physical networks are interconnected together (e.g. via bridges or physical networks are interconnected together (e.g. via bridges or
routers). Many aspects of networking, such as addressing, forwarding routers). Many aspects of networking, such as addressing, forwarding
mechanism, learning and advertising reachability, QoS, security, and mechanism, learning and advertising reachability, quality of service
firewalling, have common solutions across both physical and virtual (QoS), security, and firewalling, have common solutions across both
networks, and many issues that arise in the discussion of VPNs have physical and virtual networks, and many issues that arise in the
direct analogues with those issues as implemented in physical discussion of VPNs have direct analogues with those issues as
networks. The introduction of VPNs does not create the need to implemented in physical networks. The introduction of VPNs does not
reinvent networking, or to introduce entirely new paradigms that have create the need to reinvent networking, or to introduce entirely new
no direct analogue with existing physical networks. Instead it is paradigms that have no direct analogue with existing physical
often useful to first examine how a particular issue is handled in a networks. Instead it is often useful to first examine how a
physical network environment, and then apply the same principle to an particular issue is handled in a physical network environment, and
environment which contains virtual as well as physical networks, and then apply the same principle to an environment which contains
to develop appropriate extensions and enhancements when necessary. virtual as well as physical networks, and to develop appropriate
Clearly having mechanisms that are common across both physical and extensions and enhancements when necessary. Clearly having
virtual networks facilitates the introduction of VPNs into existing mechanisms that are common across both physical and virtual networks
networks, and also reduces the effort needed for both standards and facilitates the introduction of VPNs into existing networks, and also
product development, since existing solutions can be leveraged. 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 VPN This framework document proposes a taxonomy of a specific set of VPN
types, showing the specific applications of each, their specific types, showing the specific applications of each, their specific
requirements, and the specific types of mechanisms that may be most requirements, and the specific types of mechanisms that may be most
appropriate for their implementation. The intent of this document is appropriate for their implementation. The intent of this document is
to serve as a framework to guide a coherent discussion of the to serve as a framework to guide a coherent discussion of the
specific modifications that may be needed to existing IP mechanisms specific modifications that may be needed to existing IP mechanisms
in order to develop a full range of interoperable VPN solutions. in order to develop a full range of interoperable VPN solutions.
The document first discusses the likely expectations customers have The document first discusses the likely expectations customers have
skipping to change at page 4, line 35 skipping to change at page 5, line 37
various VPN types and their respective requirements. It also various VPN types and their respective requirements. It also
outlines suggested approaches to their implementation, hence also outlines suggested approaches to their implementation, hence also
pointing to areas for future standardization. pointing to areas for future standardization.
Note also that this document only discusses implementations of VPNs Note also that this document only discusses implementations of VPNs
across IP backbones, be they private IP networks, or the public across IP backbones, be they private IP networks, or the public
Internet. The models and mechanisms described here are intended to Internet. The models and mechanisms described here are intended to
apply to both IPV4 and IPV6 backbones. This document specifically apply to both IPV4 and IPV6 backbones. This document specifically
does not discuss means of constructing VPNs using native mappings does not discuss means of constructing VPNs using native mappings
onto switched backbones - e.g. VPNs constructed using the LAN onto switched backbones - e.g. VPNs constructed using the LAN
Emulation over ATM (LANE) [ATMF1] or Multiprotocol over ATM (MPOA) Emulation over ATM (LANE) [1] or Multiprotocol over ATM (MPOA) [2]
[ATMF2] protocols operating over ATM backbones. Where IP backbones protocols operating over ATM backbones. Where IP backbones are
are constructed using such protocols, by interconnecting routers over constructed using such protocols, by interconnecting routers over the
the switched backbone, the VPNs discussed operate on top of this IP switched backbone, the VPNs discussed operate on top of this IP
network, and hence do not directly utilize the native mechanisms of network, and hence do not directly utilize the native mechanisms of
the underlying backbone. Native VPNs are restricted to the scope of the underlying backbone. Native VPNs are restricted to the scope of
the underlying backbone, whereas IP based VPNs can extend to the the underlying backbone, whereas IP based VPNs can extend to the
extent of IP reachability. Native VPN protocols are clearly outside extent of IP reachability. Native VPN protocols are clearly outside
the scope of the IETF, and may be tackled by such bodies as the ATM the scope of the IETF, and may be tackled by such bodies as the ATM
Forum. Forum.
2.0 VPN Application and Implementation Requirements 2.0 VPN Application and Implementation Requirements
2.1 General VPN Requirements
There is growing interest in the use of IP VPNs as a more cost There is growing interest in the use of IP VPNs as a more cost
effective means of building and deploying private communication effective means of building and deploying private communication
networks for multi-site communication than with existing approaches. networks for multi-site communication than with existing approaches.
Existing private networks can be generally categorized into two types Existing private networks can be generally categorized into two types
- dedicated WANs that permanently connect together multiple sites, - dedicated WANs that permanently connect together multiple sites,
and dial networks, that allow on-demand connections through the PSTN and dial networks, that allow on-demand connections through the
network to one or more sites in the private network. Public Switched Telephone Network (PSTN) to one or more sites in the
private network.
WANs are typically implemented using leased lines or dedicated WANs are typically implemented using leased lines or dedicated
circuits - for instance, Frame Relay or ATM connections - between the circuits - for instance, Frame Relay or ATM connections - between the
multiple sites. CPE routers or switches at the various sites connect multiple sites. CPE routers or switches at the various sites connect
these dedicated facilities together and allow for connectivity across these dedicated facilities together and allow for connectivity across
the network. Given the cost and complexity of such dedicated the network. Given the cost and complexity of such dedicated
facilities and the complexity of CPE device configuration, such facilities and the complexity of CPE device configuration, such
networks are generally not fully meshed, but instead have some form networks are generally not fully meshed, but instead have some form
of hierarchical topology. For example remote offices could be of hierarchical topology. For example remote offices could be
connected directly to the nearest regional office, with the regional connected directly to the nearest regional office, with the regional
offices connected together in some form of full or partial mesh. offices connected together in some form of full or partial mesh.
Private dial networks are used to allow remote users to connect into Private dial networks are used to allow remote users to connect into
an enterprise network using PSTN or ISDN links. Typically, this is an enterprise network using PSTN or Integrated Services Digital
done through the deployment of network access servers (NAS) at one or Network (ISDN) links. Typically, this is done through the deployment
more central sites. Users dial into such NAS, which interact with AAA of Network Access Servers (NASs) at one or more central sites. Users
(Authentication, Authorization, Accounting) servers to verify the dial into such NASs, which interact with Authentication,
identity of the user, and the set of services that the user is Authorization, and Accounting (AAA) servers to verify the identity of
authorized to receive. the user, and the set of services that the user is authorized to
receive.
In recent times, as more businesses have found the need for high In recent times, as more businesses have found the need for high
speed Internet connections to their private corporate networks, there speed Internet connections to their private corporate networks, there
has been significant interest in the deployment of CPE based VPNs has been significant interest in the deployment of CPE based VPNs
running across the Internet. This has been driven typically by the running across the Internet. This has been driven typically by the
ubiquity and distance insensitive pricing of current Internet ubiquity and distance insensitive pricing of current Internet
services, that can result in significantly lower costs than typical services, that can result in significantly lower costs than typical
dedicated or leased line services. dedicated or leased line services.
The notion of using the Internet for private communications is not The notion of using the Internet for private communications is not
new, and many techniques, such as controlled route leaking, have been new, and many techniques, such as controlled route leaking, have been
used for this purpose [Ferguson]. Only in recent times, however, used for this purpose [3]. Only in recent times, however, have the
have the appropriate IP mechanisms needed to meet customer appropriate IP mechanisms needed to meet customer requirements for
requirements for VPNs all come together. These requirements include VPNs all come together. These requirements include the following:
the following:
A. Support for Opaque Packet Transport: 2.1.1 Opaque Packet Transport:
The traffic carried within a VPN may have no relation to the traffic The traffic carried within a VPN may have no relation to the traffic
on the IP backbone, either because the traffic is multiprotocol, or on the IP backbone, either because the traffic is multiprotocol, or
because the customer's IP network may use IP addressing unrelated to because the customer's IP network may use IP addressing unrelated to
that of the IP backbone on which the traffic is transported. In that of the IP backbone on which the traffic is transported. In
particular, the customer's IP network may use non-unique, private IP particular, the customer's IP network may use non-unique, private IP
addressing [Rekhter1]. addressing [4].
B. Support for Data Security: 2.1.2 Data Security
In general customers using VPNs require some form of data security. In general customers using VPNs require some form of data security.
There are different trust models applicable to the use of VPNs. One There are different trust models applicable to the use of VPNs. One
such model is where the customer does not trust the service provider such model is where the customer does not trust the service provider
to provide any form of security, and instead implements a VPN using to provide any form of security, and instead implements a VPN using
CPE devices that implement firewall functionality and that are CPE devices that implement firewall functionality and that are
connected together using secure tunnels. In this case the service connected together using secure tunnels. In this case the service
provider is used solely for IP packet transport. provider is used solely for IP packet transport.
An alternative model is where the customer trusts the service An alternative model is where the customer trusts the service
skipping to change at page 6, line 28 skipping to change at page 7, line 37
Relay or ATM service, in that the customer trusts that packets will Relay or ATM service, in that the customer trusts that packets will
not be misdirected, injected into the network in an unauthorized not be misdirected, injected into the network in an unauthorized
manner, snooped on, modified in transit, or subjected to traffic manner, snooped on, modified in transit, or subjected to traffic
analysis by unauthorized parties. analysis by unauthorized parties.
With this model providing firewall functionality and secure packet With this model providing firewall functionality and secure packet
transport services is the responsibility of the service provider. transport services is the responsibility of the service provider.
Different levels of security may be needed within the provider Different levels of security may be needed within the provider
backbone, depending on the deployment scenario used. If the VPN backbone, depending on the deployment scenario used. If the VPN
traffic is contained within a single provider's IP backbone then traffic is contained within a single provider's IP backbone then
strong security mechanisms, such as those provided by IPSec [Kent], strong security mechanisms, such as those provided by the IP Security
may not be necessary for tunnels between backbone nodes. If the VPN protocol suite (IPSec) [5], may not be necessary for tunnels between
traffic traverses networks or equipment owned by multiple backbone nodes. If the VPN traffic traverses networks or equipment
administrations then strong security mechanisms may be appropriate. owned by multiple administrations then strong security mechanisms may
Also a strong level of security may be applied by a provider to be appropriate. Also a strong level of security may be applied by a
customer traffic to address a customer perception that IP networks, provider to customer traffic to address a customer perception that IP
and particularly the Internet, are insecure. Whether or not this networks, and particularly the Internet, are insecure. Whether or
perception is correct it is one that must be addressed by the VPN not this perception is correct it is one that must be addressed by
implementation. the VPN implementation.
C. Support for Quality of Service Guarantees: 2.1.3 Quality of Service Guarantees
In addition to ensuring communication privacy, existing private In addition to ensuring communication privacy, existing private
networking techniques, building upon physical or link layer networking techniques, building upon physical or link layer
mechanisms, also offer various types of quality of service mechanisms, also offer various types of quality of service
guarantees. In particular, leased and dial up lines offer both guarantees. In particular, leased and dial up lines offer both
bandwidth and latency guarantees, while dedicated connection bandwidth and latency guarantees, while dedicated connection
technologies like ATM and Frame Relay have extensive mechanisms for technologies like ATM and Frame Relay have extensive mechanisms for
similar guarantees. As IP based VPNs become more widely deployed, similar guarantees. As IP based VPNs become more widely deployed,
there will be market demand for similar guarantees, in order to there will be market demand for similar guarantees, in order to
ensure end to end application transparency. While the ability of IP ensure end to end application transparency. While the ability of IP
based VPNs to offer such guarantees will depend greatly upon the based VPNs to offer such guarantees will depend greatly upon the
commensurate capabilities of the underlying IP backbones, a VPN commensurate capabilities of the underlying IP backbones, a VPN
framework must also address the means by which VPN systems can framework must also address the means by which VPN systems can
utilize such capabilities, as they evolve. utilize such capabilities, as they evolve.
Together, the first two of these requirements imply that VPNs must be 2.1.4 Tunneling Mechanism
implemented through some form of IP tunneling mechanism, where the
packet formats and/or the addressing used within the VPN can be Together, the first two of the requirements listed above imply that
unrelated to that used to route the tunneled packets across the IP VPNs must be implemented through some form of IP tunneling mechanism,
backbone. Such tunnels, depending upon their form, can provide some where the packet formats and/or the addressing used within the VPN
level of intrinsic data security, or this can also be enhanced using can be unrelated to that used to route the tunneled packets across
other mechanisms (e.g. IPSec). the IP backbone. Such tunnels, depending upon their form, can
provide some level of intrinsic data security, or this can also be
enhanced using other mechanisms (e.g. IPSec).
Furthermore, as discussed later, such tunneling mechanisms can also Furthermore, as discussed later, such tunneling mechanisms can also
be mapped into evolving IP traffic management mechanisms. There are be mapped into evolving IP traffic management mechanisms. There are
already defined a large number of IP tunneling mechanisms. Some of already defined a large number of IP tunneling mechanisms. Some of
these are well suited to VPN applications, as discussed further these are well suited to VPN applications, as discussed in section
below. 3.0.
2.1 CPE and Network Based VPNs 2.2 CPE and Network Based VPNs
Most current VPN implementations are based on CPE equipment. VPN Most current VPN implementations are based on CPE equipment. VPN
capabilities are being integrated into a wide variety of CPE devices, capabilities are being integrated into a wide variety of CPE devices,
ranging from firewalls to WAN edge routers and specialized VPN ranging from firewalls to WAN edge routers and specialized VPN
termination devices. Such equipment may be bought and deployed by termination devices. Such equipment may be bought and deployed by
customers, or may be deployed (and often remotely managed) by service customers, or may be deployed (and often remotely managed) by service
providers in an outsourcing service. providers in an outsourcing service.
There is also significant interest in 'network based VPNs', where the There is also significant interest in 'network based VPNs', where the
operation of the VPN is outsourced to an Internet service provider operation of the VPN is outsourced to an Internet Service Provider
(ISP), and is implemented on network as opposed to CPE equipment. (ISP), and is implemented on network as opposed to CPE equipment.
There is significant interest in such solutions both by customers There is significant interest in such solutions both by customers
seeking to reduce support costs and by ISPs seeking new revenue seeking to reduce support costs and by ISPs seeking new revenue
sources. Supporting VPNs in the network allows the use of particular sources. Supporting VPNs in the network allows the use of particular
mechanisms which may lead to highly efficient and cost effective VPN mechanisms which may lead to highly efficient and cost effective VPN
solutions, with common equipment and operations support amortized solutions, with common equipment and operations support amortized
across large numbers of customers. across large numbers of customers.
Most of the mechanisms discussed below can apply to either CPE based Most of the mechanisms discussed below can apply to either CPE based
or network based VPNs. However particular mechanisms are likely to or network based VPNs. However particular mechanisms are likely to
skipping to change at page 7, line 41 skipping to change at page 9, line 4
There is significant interest in such solutions both by customers There is significant interest in such solutions both by customers
seeking to reduce support costs and by ISPs seeking new revenue seeking to reduce support costs and by ISPs seeking new revenue
sources. Supporting VPNs in the network allows the use of particular sources. Supporting VPNs in the network allows the use of particular
mechanisms which may lead to highly efficient and cost effective VPN mechanisms which may lead to highly efficient and cost effective VPN
solutions, with common equipment and operations support amortized solutions, with common equipment and operations support amortized
across large numbers of customers. across large numbers of customers.
Most of the mechanisms discussed below can apply to either CPE based Most of the mechanisms discussed below can apply to either CPE based
or network based VPNs. However particular mechanisms are likely to or network based VPNs. However particular mechanisms are likely to
prove applicable only to the latter, since they leverage tools (e.g. prove applicable only to the latter, since they leverage tools (e.g.
piggybacking on routing protocols) which are accessible only to ISPs piggybacking on routing protocols) which are accessible only to ISPs
and which are unlikely to be made available to any customer, or even and which are unlikely to be made available to any customer, or even
hosted on ISP owned and operated CPE, due to the problems of hosted on ISP owned and operated CPE, due to the problems of
coordinating joint management of the CPE gear by both the ISP and the coordinating joint management of the CPE gear by both the ISP and the
customer. The document will indicate which techniques are likely to customer. This document will indicate which techniques are likely to
apply only to network based VPNs. apply only to network based VPNs.
2.2 VPNs and Extranets 2.3 VPNs and Extranets
The term 'extranet' is commonly used to refer to a scenario whereby The term 'extranet' is commonly used to refer to a scenario whereby
two or more companies have networked access to a limited amount of two or more companies have networked access to a limited amount of
each other's corporate data. For example a manufacturing company each other's corporate data. For example a manufacturing company
might use an extranet for its suppliers to allow it to query might use an extranet for its suppliers to allow it to query
databases for the pricing and availability of components, and then to databases for the pricing and availability of components, and then to
order and track the status of outstanding orders. Another example is order and track the status of outstanding orders. Another example is
joint software development, for instance, company A allows one joint software development, for instance, company A allows one
development group within company B to access its operating system development group within company B to access its operating system
source code, and company B allows one development group in company A source code, and company B allows one development group in company A
to access its security software. Note that the access policies can to access its security software. Note that the access policies can
get arbitrarily complex. For example company B may internally get arbitrarily complex. For example company B may internally
restrict access to its security software to groups in certain restrict access to its security software to groups in certain
geographic locations to comply with export control laws, for example. geographic locations to comply with export control laws, for example.
A key feature of an extranet is thus the control of who can access A key feature of an extranet is thus the control of who can access
what data, and this is essentially a policy decision. Policy what data, and this is essentially a policy decision. Policy
decisions are typically enforced today at the interconnection points decisions are typically enforced today at the interconnection points
between different domains, for example between a private network and between different domains, for example between a private network and
the Internet, or between a software test lab and the rest of the the Internet, or between a software test lab and the rest of the
company network. The enforcement may done via a firewall, router company network. The enforcement may be done via a firewall, router
with access list functionality, application gateway, or any similar with access list functionality, application gateway, or any similar
device capable of applying policy to transit traffic. Policy device capable of applying policy to transit traffic. Policy
controls may be implemented within a corporate network, in addition controls may be implemented within a corporate network, in addition
to between corporate networks. Also the interconnections between to between corporate networks. Also the interconnections between
networks could be a set of bilateral links, or could be a separate networks could be a set of bilateral links, or could be a separate
network, perhaps maintained by an industry consortium. This separate network, perhaps maintained by an industry consortium. This separate
network could itself be a VPN or a physical network. network could itself be a VPN or a physical network.
Introducing VPNs into a network does not require any change to this Introducing VPNs into a network does not require any change to this
model. Policy can be enforced between two VPNs, or between a VPN and model. Policy can be enforced between two VPNs, or between a VPN and
the Internet, in exactly the same manner as is done today without the Internet, in exactly the same manner as is done today without
VPNs. For example two VPNs could be interconnected, which each VPNs. For example two VPNs could be interconnected, which each
administration locally imposing its own policy controls, via a administration locally imposing its own policy controls, via a
firewall, on all traffic that enters its VPN from the outside, firewall, on all traffic that enters its VPN from the outside,
whether from another VPN or from the Internet. whether from another VPN or from the Internet.
This model of a VPN provides for a separation of policy from the This model of a VPN provides for a separation of policy from the
underlying mode of packet transport used. For example, a router may underlying mode of packet transport used. For example, a router may
direct voice traffic to ATM VCCs for guaranteed QoS, non-local direct voice traffic to ATM Virtual Channel Connections (VCCs) for
internal company traffic to secure tunnels, and other traffic to a guaranteed QoS, non-local internal company traffic to secure tunnels,
link to the Internet. In the past the secure tunnels may have been and other traffic to a link to the Internet. In the past the secure
frame relay circuits, now they may also be secure IP tunnels or MPLS tunnels may have been frame relay circuits, now they may also be
LSPs. secure IP tunnels or MPLS Label Switched Paths (LSPs)
Other models of a VPN are also possible. For example there is a Other models of a VPN are also possible. For example there is a
model whereby a set of application flows is mapped into a VPN. As model whereby a set of application flows is mapped into a VPN. As
the policy rules imposed by a network administrator can get quite the policy rules imposed by a network administrator can get quite
complex, the number of distinct sets of application flows that are complex, the number of distinct sets of application flows that are
used in the policy rulebase, and hence the number of VPNs, can thus used in the policy rulebase, and hence the number of VPNs, can thus
grow quite large, and there can be multiple overlapping VPNs. grow quite large, and there can be multiple overlapping VPNs.
However there is little to be gained by introducing such new However there is little to be gained by introducing such new
complexity into a network. Instead a VPN should be viewed as a complexity into a network. Instead a VPN should be viewed as a
direct analogue to a physical network, as this allows the leveraging direct analogue to a physical network, as this allows the leveraging
of existing protocols and procedures, and the current expertise and of existing protocols and procedures, and the current expertise and
skillsets of network administrators and customers. skill sets of network administrators and customers.
3.0 VPN Tunneling 3.0 VPN Tunneling
As noted above in section 2.0, VPNs must be implemented using some As noted above in section 2.1, VPNs must be implemented using some
form of tunneling mechanism. This section looks at the generic form of tunneling mechanism. This section looks at the generic
requirements for such VPN tunneling mechanisms. A number of requirements for such VPN tunneling mechanisms. A number of
characteristics and aspects common to any link layer protocol are characteristics and aspects common to any link layer protocol are
taken and compared with the features offered by existing tunneling taken and compared with the features offered by existing tunneling
protocols. This provides a basis for comparing different protocols protocols. This provides a basis for comparing different protocols
and is also useful to highlight areas where existing tunneling and is also useful to highlight areas where existing tunneling
protocols could benefit from extensions to better support their protocols could benefit from extensions to better support their
operation in a VPN environment. operation in a VPN environment.
An IP tunnel connecting two VPN endpoints is a basic building block An IP tunnel connecting two VPN endpoints is a basic building block
skipping to change at page 9, line 37 skipping to change at page 10, line 49
A VPN device may terminate multiple IP tunnels and forward packets A VPN device may terminate multiple IP tunnels and forward packets
between these tunnels and other network interfaces in different ways. between these tunnels and other network interfaces in different ways.
In the discussion of different types of VPNs, in later sections of In the discussion of different types of VPNs, in later sections of
this document, the primary distinguishing characteristic of these this document, the primary distinguishing characteristic of these
different types is the manner in which packets are forwarded between different types is the manner in which packets are forwarded between
interfaces (e.g. bridged or routed). There is a direct analogy with interfaces (e.g. bridged or routed). There is a direct analogy with
how existing networking devices are characterized today. A two-port how existing networking devices are characterized today. A two-port
repeater just forwards packets between its ports, and does not repeater just forwards packets between its ports, and does not
examine the contents of the packet. A bridge forwards packets using examine the contents of the packet. A bridge forwards packets using
MAC layer information contained in the packet, while a router Media Access Control (MAC) layer information contained in the packet,
forwards packets using layer 3 addressing information contained in while a router forwards packets using layer 3 addressing information
the packet. Each of these three scenarios has a direct VPN analogue, contained in the packet. Each of these three scenarios has a direct
as discussed later. Note that an IP tunnel is viewed as just another VPN analogue, as discussed later. Note that an IP tunnel is viewed
sort of link, which can be concatenated with another link, bound to a as just another sort of link, which can be concatenated with another
bridge forwarding table, or bound to an IP forwarding table, link, bound to a bridge forwarding table, or bound to an IP
depending on the type of VPN. forwarding table, depending on the type of VPN.
The following sections look at the requirements for a generic IP The following sections look at the requirements for a generic IP
tunneling protocol that can be used as a basic building block to tunneling protocol that can be used as a basic building block to
construct different types of VPNs. construct different types of VPNs.
3.1 Tunneling Protocol Requirements for VPNs 3.1 Tunneling Protocol Requirements for VPNs
There are numerous IP tunneling mechanisms, including IP/IP There are numerous IP tunneling mechanisms, including IP/IP [6],
[Perkins], GRE tunnels [Hanks], L2TP [Townsley], IPSec [IPSec], and Generic Routing Encapsulation (GRE) tunnels [7], Layer 2 Tunneling
MPLS [Rosen2]. Note that while some of these protocols are not often Protocol (L2TP) [8], IPSec [5], and Multiprotocol Label Switching
(MPLS) [9]. Note that while some of these protocols are not often
thought of as tunneling protocols, they do each allow for opaque thought of as tunneling protocols, they do each allow for opaque
transport of frames as packet payload across an IP network, with transport of frames as packet payload across an IP network, with
forwarding disjoint from the address fields of the encapsulated forwarding disjoint from the address fields of the encapsulated
packets. packets.
Note, however, that there is one significant distinction between each Note, however, that there is one significant distinction between each
of the IP tunneling protocols mentioned above, and MPLS. MPLS can be of the IP tunneling protocols mentioned above, and MPLS. MPLS can be
viewed as a specific link layer for IP, insofar as MPLS specific viewed as a specific link layer for IP, insofar as MPLS specific
mechanisms apply only within the scope of an MPLS network, whereas IP mechanisms apply only within the scope of an MPLS network, whereas IP
based mechanisms extend to the extent of IP reachability. As such, based mechanisms extend to the extent of IP reachability. As such,
VPN mechanisms built directly upon MPLS tunneling mechanisms cannot, VPN mechanisms built directly upon MPLS tunneling mechanisms cannot,
by definition, extend outside the scope of MPLS networks, any more so by definition, extend outside the scope of MPLS networks, any more so
than, for instance, ATM based mechanisms such as LANE can extend than, for instance, ATM based mechanisms such as LANE can extend
outside of ATM networks. Note however, that an MPLS network can span outside of ATM networks. Note however, that an MPLS network can span
many different link layer technologies, and so, like an IP network, many different link layer technologies, and so, like an IP network,
its scope is not limited by the specific link layers used. A number its scope is not limited by the specific link layers used. A number
of proposals for defining a set of mechanisms to allow for of proposals for defining a set of mechanisms to allow for
interoperable VPNs specifically over MPLS networks have also been interoperable VPNs specifically over MPLS networks have also been
produced ([Heinanen2] [Jamieson] [Casey1] [Li2], [Muthukrishnan] and produced ([10] [11] [12] [13], [14] and [15]).
[Rosen1]).
There are a number of desirable requirements for a VPN tunneling There are a number of desirable requirements for a VPN tunneling
mechanism, however, that are not all met by the existing tunneling mechanism, however, that are not all met by the existing tunneling
mechanisms. These requirements include: mechanisms. These requirements include:
3.1.1 Multiplexing 3.1.1 Multiplexing
There are cases where multiple VPN tunnels may be needed between the There are cases where multiple VPN tunnels may be needed between the
same two IP endpoints. This may be needed, for instance, in cases same two IP endpoints. This may be needed, for instance, in cases
where the VPNs are network based, and each end point supports where the VPNs are network based, and each end point supports
multiple customers. Traffic for different customers travels over multiple customers. Traffic for different customers travels over
separate tunnels between the same two physical devices. A separate tunnels between the same two physical devices. A
multiplexing field is needed to distinguish which packets belong to multiplexing field is needed to distinguish which packets belong to
which tunnel. Sharing a tunnel in this manner may also reduce the which tunnel. Sharing a tunnel in this manner may also reduce the
latency and processing burden of tunnel set up. Of the existing IP latency and processing burden of tunnel set up. Of the existing IP
tunneling mechanisms, L2TP (via the tunnel-id and session-id fields), tunneling mechanisms, L2TP (via the tunnel-id and session-id fields),
MPLS (via the label) and IPSec (via the SPI field) have a MPLS (via the label) and IPSec (via the Security Parameter Index
multiplexing mechanism. Strictly speaking GRE does not have a (SPI) field) have a multiplexing mechanism. Strictly speaking GRE
multiplexing field. However the key field, which was intended to be does not have a multiplexing field. However the key field, which was
used for authenticating the source of a packet, has sometimes been intended to be used for authenticating the source of a packet, has
used as a multiplexing field. IP/IP does not have a multiplexing sometimes been used as a multiplexing field. IP/IP does not have a
field. multiplexing field.
The IETF [Fox] and the ATM Forum [Petri] have standardized on a The IETF [16] and the ATM Forum [17] have standardized on a single
single format for a globally unique identifier used to identify a VPN format for a globally unique identifier used to identify a VPN (a
(a VPN-ID). A VPN-ID can be used in the control plane, to bind a VPN-ID). A VPN-ID can be used in the control plane, to bind a tunnel
tunnel to a VPN at tunnel establishment time, or in the data plane, to a VPN at tunnel establishment time, or in the data plane, to
to identify the VPN associated with a packet, on a per-packet basis. identify the VPN associated with a packet, on a per-packet basis. In
In the data plane a VPN encapsulation header can be used by MPLS, the data plane a VPN encapsulation header can be used by MPLS, MPOA
MPOA and other tunneling mechanisms to aggregate packets for and other tunneling mechanisms to aggregate packets for different
different VPNs over a single tunnel. In this case an explicit VPNs over a single tunnel. In this case an explicit indication of
indication of VPN-ID is included with every packet, and no use is VPN-ID is included with every packet, and no use is made of any
made of any tunnel specific multiplexing field. In the control plane tunnel specific multiplexing field. In the control plane a VPN-ID
a VPN-ID field can be included in any tunnel establishment signalling field can be included in any tunnel establishment signalling protocol
protocol to allow for the association of a tunnel (e.g. as identified to allow for the association of a tunnel (e.g. as identified by the
by the SPI field) with a VPN. In this case there is no need for a SPI field) with a VPN. In this case there is no need for a VPN-ID to
VPN-ID to be included with every data packet. This is discussed be included with every data packet. This is discussed further in
further in section 5.2.1. section 5.3.1.
3.1.2 Signalling Protocol 3.1.2 Signalling Protocol
There is some configuration information that must be known by an end There is some configuration information that must be known by an end
point in advance of tunnel establishment, such as the IP address of point in advance of tunnel establishment, such as the IP address of
the remote end point, and any relevant tunnel attributes required, the remote end point, and any relevant tunnel attributes required,
such as the level of security needed. Once this information is such as the level of security needed. Once this information is
available, the actual tunnel establishment can be completed in one of available, the actual tunnel establishment can be completed in one of
two ways - via a management operation, or via a signalling protocol two ways - via a management operation, or via a signalling protocol
that allows tunnels to be established dynamically. that allows tunnels to be established dynamically.
An example of a management operation would be to use an SNMP MIB to An example of a management operation would be to use an SNMP
configure various tunneling parameters, e.g. MPLS labels, source Management Information Base (MIB) to configure various tunneling
addresses to use for IP/IP or GRE tunnels, L2TP tunnel-ids and parameters, e.g. MPLS labels, source addresses to use for IP/IP or
session-ids, or security association parameters for IPSec. GRE tunnels, L2TP tunnel-ids and session-ids, or security association
parameters for IPSec.
Using a signalling protocol can significantly reduce the management Using a signalling protocol can significantly reduce the management
burden however, and as such, is essential in many deployment burden however, and as such, is essential in many deployment
scenarios. It reduces the amount of configuration needed, and also scenarios. It reduces the amount of configuration needed, and also
reduces the management co-ordination needed if a VPN spans multiple reduces the management co-ordination needed if a VPN spans multiple
administrative domains. For example, the value of the multiplexing administrative domains. For example, the value of the multiplexing
field, described above, is local to the node assigning the value, and field, described above, is local to the node assigning the value, and
can be kept local if distributed via a signalling protocol, rather can be kept local if distributed via a signalling protocol, rather
than being first configured into a management station and then than being first configured into a management station and then
distributed to the relevant nodes. A signalling protocol also allows distributed to the relevant nodes. A signalling protocol also allows
nodes that are mobile or are only intermittently connected to nodes that are mobile or are only intermittently connected to
establish tunnels on demand. Signalling is particularly useful for establish tunnels on demand.
the VPRN scenario described later (section 5.0).
When used in a VPN environment a signalling protocol should allow for When used in a VPN environment a signalling protocol should allow for
the transport of a VPN identifier to allow the resulting tunnel to be the transport of a VPN-ID to allow the resulting tunnel to be
associated with a particular VPN. It should also allow tunnel associated with a particular VPN. It should also allow tunnel
attributes to be exchanged or negotiated, for example the use of attributes to be exchanged or negotiated, for example the use of
frame sequencing or the use of multiprotocol transport. Note that frame sequencing or the use of multiprotocol transport. Note that
the role of the signalling protocol need only be to negotiate tunnel the role of the signalling protocol need only be to negotiate tunnel
attributes, not to carry information about how the tunnel is used, attributes, not to carry information about how the tunnel is used,
for example whether the frames carried in the tunnel are to be for example whether the frames carried in the tunnel are to be
forwarded at layer 2 or layer 3. (This is similar to Q.2931 ATM forwarded at layer 2 or layer 3. (This is similar to Q.2931 ATM
signalling - the same signalling protocol is used to set up Classical signalling - the same signalling protocol is used to set up Classical
IP LISs as well as LANE ELANs). IP logical subnetworks as well as for LANE emulated LANs.
Of the various tunneling protocols, the following ones support a Of the various IP tunneling protocols, the following ones support a
signalling protocol that could be adapted for this purpose: MPLS (the signalling protocol that could be adapted for this purpose: L2TP (the
various mechanisms for label distribution, including the label L2TP control protocol), IPSec (the Internet Key Exchange (IKE)
distribution protocol (LDP) [Thomas]), L2TP (the L2TP control protocol [18]), and GRE (as used with mobile-ip tunneling [19]). Also
protocol) and IPSec (the Internet Key Exchange (IKE) protocol there are two MPLS signalling protocols that can be used to establish
[Harkins]), and GRE (as used with mobile-ip tunneling [Calhoun3]). LSP tunnels. One uses extensions to the MPLS Label Distribution
Protocol (LDP) protocol [20], called Constraint-Based Routing LDP
(CR-LDP) [21], and the other uses extensions to the Resource
Reservation Protocol (RSVP) for LSP tunnels [22].
3.1.3 Data Security 3.1.3 Data Security
A VPN tunneling protocol must support mechanisms to allow for A VPN tunneling protocol must support mechanisms to allow for
whatever level of security may be desired by customers, including whatever level of security may be desired by customers, including
authentication and/or encryption of various strengths. None of the authentication and/or encryption of various strengths. None of the
tunneling mechanisms discussed, other than IPSec, have intrinsic tunneling mechanisms discussed, other than IPSec, have intrinsic
security mechanisms, but rely upon the security characteristics of security mechanisms, but rely upon the security characteristics of
the underlying IP backbone. In particular, MPLS relies upon the the underlying IP backbone. In particular, MPLS relies upon the
explicit labeling of label switched paths (LSP) to ensure that explicit labeling of label switched paths to ensure that packets
packets cannot be misdirected, while the other tunneling mechanisms cannot be misdirected, while the other tunneling mechanisms can all
can all be secured through the use of IPSec. For VPNs implemented be secured through the use of IPSec. For VPNs implemented over non-
over non-IP backbones (e.g. MPOA, Frame Relay or ATM virtual IP backbones (e.g. MPOA, Frame Relay or ATM virtual circuits), data
circuits), data security is implicitly provided by the layer two security is implicitly provided by the layer two switch
switch infrastructure. infrastructure.
Overall VPN security is not just a capability of the tunnels alone, Overall VPN security is not just a capability of the tunnels alone,
but has to be viewed in the broader context of how packets are but has to be viewed in the broader context of how packets are
forwarded onto those tunnels. For example with VPRNs implemented forwarded onto those tunnels. For example with VPRNs implemented
with virtual routers, the use of separate routing and forwarding with virtual routers, the use of separate routing and forwarding
table instances ensures the isolation of traffic between VPNs. table instances ensures the isolation of traffic between VPNs.
Packets on one VPN cannot be misrouted to a tunnel on a second VPN Packets on one VPN cannot be misrouted to a tunnel on a second VPN
since those tunnels are not visible to the forwarding table of the since those tunnels are not visible to the forwarding table of the
first VPN. first VPN.
skipping to change at page 13, line 6 skipping to change at page 14, line 18
dynamically establish a tunnel with another endpoint, then there is a dynamically establish a tunnel with another endpoint, then there is a
requirement to be able to authenticate the party attempting the requirement to be able to authenticate the party attempting the
tunnel establishment. IPSec has an array of schemes for this tunnel establishment. IPSec has an array of schemes for this
purpose, allowing, for example, authentication to be based on pre- purpose, allowing, for example, authentication to be based on pre-
shared keys, or to use digital signatures and certificates. Other shared keys, or to use digital signatures and certificates. Other
tunneling schemes have weaker forms of authentication. In some cases tunneling schemes have weaker forms of authentication. In some cases
no authentication may be needed, for example if the tunnels are no authentication may be needed, for example if the tunnels are
provisioned, rather than dynamically established, or if the trust provisioned, rather than dynamically established, or if the trust
model in use does not require it. model in use does not require it.
Currently the IPSec ESP protocol [Kent2] can be used to establish SAs Currently the IPSec Encapsulating Security Payload (ESP) protocol
that support either encryption or authentication or both. However [23] can be used to establish SAs that support either encryption or
the protocol specification precludes the use of an SA where neither authentication or both. However the protocol specification precludes
encryption or authentication is used. In a VPN environment this the use of an SA where neither encryption or authentication is used.
"null/null" option is useful, since other aspects of the protocol In a VPN environment this "null/null" option is useful, since other
(e.g. that it supports tunneling and multiplexing) may be all that is aspects of the protocol (e.g. that it supports tunneling and
required. In effect the "null/null" option can be viewed as just multiplexing) may be all that is required. In effect the "null/null"
another level of data security. Given that this option is of benefit option can be viewed as just another level of data security.
in a VPN environment, it is recommended that the restrictive wording
in the ESP protocol specification be removed.
3.1.4 Multiprotocol Transport 3.1.4 Multiprotocol Transport
In many applications of VPNs, the VPN may carry opaque, multiprotocol In many applications of VPNs, the VPN may carry opaque, multiprotocol
traffic. As such, the tunneling protocol used must also support traffic. As such, the tunneling protocol used must also support
multiprotocol transport. L2TP is designed to transport PPP packets, multiprotocol transport. L2TP is designed to transport Point-to-
and thus can be used to carry multiprotocol traffic since PPP itself Point Protocol (PPP) [24] packets, and thus can be used to carry
is multiprotocol. GRE also provides for the identification of the multiprotocol traffic since PPP itself is multiprotocol. GRE also
protocol being tunneled. IP/IP and IPSec tunnels have no such provides for the identification of the protocol being tunneled.
protocol identification field, since the traffic being tunneled is IP/IP and IPSec tunnels have no such protocol identification field,
assumed to be IP. since the traffic being tunneled is assumed to be IP.
It is possible to extend the IPSec protocol suite to allow for the It is possible to extend the IPSec protocol suite to allow for the
transport of multiprotocol packets. This can be achieved, for transport of multiprotocol packets. This can be achieved, for
example, by extending the signalling component of IPSec (IKE) to example, by extending the signalling component of IPSec - IKE, to
indicate the protocol type of the traffic being tunneled, or to carry indicate the protocol type of the traffic being tunneled, or to carry
a packet multiplexing header (e.g. an LLC/SNAP header or GRE header) a packet multiplexing header (e.g. an LLC/SNAP header or GRE header)
with each tunneled packet. This approach is similar to that used for with each tunneled packet. This approach is similar to that used for
the same purpose in ATM networks, where signalling is used to the same purpose in ATM networks, where signalling is used to
indicate the encapsulation used on the VCC, and where packets sent on indicate the encapsulation used on the VCC, and where packets sent on
the VCC can use either an LLC/SNAP header or be placed directly into the VCC can use either an LLC/SNAP header or be placed directly into
the AAL5 payload, the latter being known as VC-multiplexing (see the AAL5 payload, the latter being known as VC-multiplexing (see
[Perez]). [25]).
3.1.5 Frame Sequencing 3.1.5 Frame Sequencing
One quality of service attribute required by customers of a VPN may One quality of service attribute required by customers of a VPN may
be frame sequencing, matching the equivalent characteristic of be frame sequencing, matching the equivalent characteristic of
physical leased lines or dedicated connections. Sequencing may be physical leased lines or dedicated connections. Sequencing may be
required for the efficient operation of particular end to end required for the efficient operation of particular end to end
protocols or applications. In order to implement frame sequencing, protocols or applications. In order to implement frame sequencing,
the tunneling mechanism must support a sequencing field. Both L2TP the tunneling mechanism must support a sequencing field. Both L2TP
and GRE have such a field. IPSec has a sequence number field, but it and GRE have such a field. IPSec has a sequence number field, but it
skipping to change at page 14, line 25 skipping to change at page 15, line 37
action (such as route recalculation) if there has been a failure. action (such as route recalculation) if there has been a failure.
There are two approaches possible. One is for the tunneling protocol There are two approaches possible. One is for the tunneling protocol
itself to periodically check in-band for loss of connectivity, and to itself to periodically check in-band for loss of connectivity, and to
provide an explicit indication of failure. For example L2TP has an provide an explicit indication of failure. For example L2TP has an
optional keep-alive mechanism to detect non-operational tunnels. optional keep-alive mechanism to detect non-operational tunnels.
The other approach does not require the tunneling protocol itself to The other approach does not require the tunneling protocol itself to
perform this function, but relies on the operation of some out-of- perform this function, but relies on the operation of some out-of-
band mechanism to determine loss of connectivity. For example if a band mechanism to determine loss of connectivity. For example if a
routing protocol such as RIP or OSPF is run over a tunnel mesh, a routing protocol such as Routing Information Protocol (RIP) [26] or
Open Shortest Path First (OSPF) [27] is run over a tunnel mesh, a
failure to hear from a neighbour within a certain period of time will failure to hear from a neighbour within a certain period of time will
result in the routing protocol declaring the tunnel to be down. result in the routing protocol declaring the tunnel to be down.
Another out-of-band approach is to perform regular ICMP pings with a Another out-of-band approach is to perform regular ICMP pings with a
peer. This is generally sufficient assurance that the tunnel is peer. This is generally sufficient assurance that the tunnel is
operational, due to the fact the tunnel also runs across the same IP operational, due to the fact the tunnel also runs across the same IP
backbone. backbone.
When tunnels are established dynamically a distinction needs to be When tunnels are established dynamically a distinction needs to be
drawn between the static and dynamic tunnel information needed. drawn between the static and dynamic tunnel information needed.
Before a tunnel can be established some static information is needed Before a tunnel can be established some static information is needed
skipping to change at page 15, line 8 skipping to change at page 16, line 21
driven approach and to trigger tunnel establishment whenever there is driven approach and to trigger tunnel establishment whenever there is
data to be transferred, and to timeout the tunnel due to inactivity. data to be transferred, and to timeout the tunnel due to inactivity.
This approach is particularly useful if resources for the tunnel are This approach is particularly useful if resources for the tunnel are
being allocated in the network for QoS purposes. Another approach is being allocated in the network for QoS purposes. Another approach is
to trigger tunnel establishment whenever the static tunnel to trigger tunnel establishment whenever the static tunnel
configuration information is installed, and to attempt to keep the configuration information is installed, and to attempt to keep the
tunnel up all the time. tunnel up all the time.
3.1.7 Large MTUs 3.1.7 Large MTUs
Since the traffic sent through a VPN tunnel may often be opaque to An IP tunnel has an associated Maximum Transmission Unit (MTU), just
the underlying IP backbone, it cannot also generally be assumed that like a regular link. It is conceivable that this MTU may be larger
the maximum transfer unit (MTU) of the tunnel itself is less than or than the MTU of one or more individual hops along the path between
equal to the smallest MTU encountered on the path of the tunnel tunnel endpoints. If so, some form of frame fragmentation will be
across the IP backbone. As such, fragmentation at some layer is required within the tunnel.
needed.
If the frame to be transferred is mapped into one IP datagram, normal If the frame to be transferred is mapped into one IP datagram, normal
IP fragmentation will be used. An alternative approach is for the IP fragmentation will occur when the IP datagram reaches a hop with
tunneling protocol itself to incorporate a segmentation and an MTU smaller than the IP tunnel's MTU. This can have undesirable
reassembly capability that operates at the tunnel level, (perhaps performance implications at the router performing such mid-tunnel
using the tunnel sequence number and an end-of-message marker of some fragmentation.
sort) in order to avoid IP level fragmentation. None of the existing
An alternative approach is for the tunneling protocol itself to
incorporate a segmentation and reassembly capability that operates at
the tunnel level, perhaps using the tunnel sequence number and an
end-of-message marker of some sort. (Note that multilink PPP uses a
mechanism similar to this to fragment packets). This avoids IP level
fragmentation within the tunnel itself. None of the existing
tunneling protocols support such a mechanism. tunneling protocols support such a mechanism.
3.1.8 Minimization of Tunnel Overhead 3.1.8 Minimization of Tunnel Overhead
There is clearly benefit in minimizing the overhead of any tunneling There is clearly benefit in minimizing the overhead of any tunneling
mechanisms. This is particularly important for the transport of mechanisms. This is particularly important for the transport of
jitter and latency sensitive traffic such as packetized voice and jitter and latency sensitive traffic such as packetized voice and
video. On the other hand, the use of security mechanisms, such as video. On the other hand, the use of security mechanisms, such as
IPSec, do impose their own overhead, hence the objective should be to IPSec, do impose their own overhead, hence the objective should be to
minimize overhead over and above that needed for security, and to not minimize overhead over and above that needed for security, and to not
burden those tunnels in which security is not mandatory with burden those tunnels in which security is not mandatory with
unnecessary overhead. unnecessary overhead.
One area where the amount of overhead may be significant is when One area where the amount of overhead may be significant is when
voluntary tunneling is used for dial-up remote clients connecting to voluntary tunneling is used for dial-up remote clients connecting to
a VPN, due to the typically low bandwidth of dial-up links. This is a VPN, due to the typically low bandwidth of dial-up links. This is
discussed further in section 8.2. discussed further in section 6.3.
3.1.9 Flow and congestion control 3.1.9 Flow and congestion control
During the development of the L2TP protocol procedures were developed During the development of the L2TP protocol procedures were developed
for flow and congestion control. These were necessitated primarily for flow and congestion control. These were necessitated primarily
because of the need to provide adequate performance over lossy because of the need to provide adequate performance over lossy
networks when PPP compression is used, which, unlike IP Payload networks when PPP compression is used, which, unlike IP Payload
Compression Protocol (IPComp) [Shacham], is stateful across packets. Compression Protocol (IPComp) [28], is stateful across packets.
Another motivation was to accommodate devices with very little Another motivation was to accommodate devices with very little
buffering, used for example to terminate low speed dial-up lines. buffering, used for example to terminate low speed dial-up lines.
However the flow and congestion control mechanisms defined in the However the flow and congestion control mechanisms defined in the
final version of the L2TP specification are used only for the control final version of the L2TP specification are used only for the control
channels, and not for data traffic. channels, and not for data traffic.
In general the interactions between multiple layers of flow and In general the interactions between multiple layers of flow and
congestion control schemes can be very complex. Given the congestion control schemes can be very complex. Given the
predominance of TCP traffic in today's networks and the fact that TCP predominance of TCP traffic in today's networks and the fact that TCP
has its own end-to-end flow and congestion control mechanisms, it is has its own end-to-end flow and congestion control mechanisms, it is
skipping to change at page 16, line 20 skipping to change at page 17, line 38
mechanisms within tunneling protocols. Good flow and congestion mechanisms within tunneling protocols. Good flow and congestion
control schemes, that can adapt to a wide variety of network control schemes, that can adapt to a wide variety of network
conditions and deployment scenarios are complex to develop and test, conditions and deployment scenarios are complex to develop and test,
both in themselves and in understanding the interaction with other both in themselves and in understanding the interaction with other
schemes that may be running in parallel. There may be some benefit, schemes that may be running in parallel. There may be some benefit,
however, in having the capability whereby a sender can shape traffic however, in having the capability whereby a sender can shape traffic
to the capacity of a receiver in some manner, and in providing the to the capacity of a receiver in some manner, and in providing the
protocol mechanisms to allow a receiver to signal its capabilities to protocol mechanisms to allow a receiver to signal its capabilities to
a sender. This is an area that may benefit from further study. a sender. This is an area that may benefit from further study.
Note also the work of the Performance Implications of Link
Characteristics (PILC) working group of the IETF, which is examining
how the properties of different network links can have an impact on
the performance of Internet protocols operating over those links.
3.1.10 QoS / Traffic Management 3.1.10 QoS / Traffic Management
As noted above, customers may require that VPNs yield similar As noted above, customers may require that VPNs yield similar
behaviour to physical leased lines or dedicated connections with behaviour to physical leased lines or dedicated connections with
respect to such QoS parameters as loss rates, jitter, latency and respect to such QoS parameters as loss rates, jitter, latency and
bandwidth guarantees. How such guarantees could be delivered will, in bandwidth guarantees. How such guarantees could be delivered will,
general, be a function of the traffic management characteristics of in general, be a function of the traffic management characteristics
the VPN nodes themselves, and the access and backbone networks across of the VPN nodes themselves, and the access and backbone networks
which they are connected. across which they are connected.
A full discussion of QoS and VPNs is outside the scope of this A full discussion of QoS and VPNs is outside the scope of this
document, however by modelling a VPN tunnel as just another type of document, however by modelling a VPN tunnel as just another type of
link layer, many of the existing mechanisms developed for ensuring link layer, many of the existing mechanisms developed for ensuring
QoS over physical links can also be applied. For example at a VPN QoS over physical links can also be applied. For example at a VPN
node, the mechanisms of policing, marking, queuing, shaping and node, the mechanisms of policing, marking, queuing, shaping and
scheduling can all be applied to VPN traffic with VPN-specific scheduling can all be applied to VPN traffic with VPN-specific
parameters, queues and interfaces, just as for non-VPN traffic. The parameters, queues and interfaces, just as for non-VPN traffic. The
techniques developed for Diffserv, Intserv and for traffic techniques developed for Diffserv, Intserv and for traffic
engineering in MPLS are also applicable. See also [Duffield] for a engineering in MPLS are also applicable. See also [29] for a
discussion of QoS and VPNs. discussion of QoS and VPNs.
It should be noted, however, that this model of tunnel operation is It should be noted, however, that this model of tunnel operation is
not necessarily consistent with the way in which specific tunneling not necessarily consistent with the way in which specific tunneling
protocols are currently modelled. While a model is an aid to protocols are currently modelled. While a model is an aid to
comprehension, and not part of a protocol specification, having comprehension, and not part of a protocol specification, having
differing models can complicate discussions, particularly if a model differing models can complicate discussions, particularly if a model
is misinterpreted as being part of a protocol specification or as is misinterpreted as being part of a protocol specification or as
constraining choice of implementation method. For example, IPSec constraining choice of implementation method. For example, IPSec
tunnel processing can be modelled both as an interface and as an tunnel processing can be modelled both as an interface and as an
attribute of a particular packet flow. attribute of a particular packet flow.
3.2 Recommendations 3.2 Recommendations
IPSec is needed whenever there is a requirement for strong encryption IPSec is needed whenever there is a requirement for strong encryption
or strong authentication. It also supports multiplexing and a or strong authentication. It also supports multiplexing and a
signalling protocol (IKE). However extending the IPSec protocol signalling protocol - IKE. However extending the IPSec protocol
suite to also cover the following areas would be beneficial, in order suite to also cover the following areas would be beneficial, in order
to better support the tunneling requirements of a VPN environment. to better support the tunneling requirements of a VPN environment.
- the transport of a VPN-ID when establishing an SA (3.1.2) - the transport of a VPN-ID when establishing an SA (3.1.2)
- a null encryption and null authentication option (3.1.3) - a null encryption and null authentication option (3.1.3)
- multiprotocol operation (3.1.4) - multiprotocol operation (3.1.4)
- frame sequencing (3.1.5) - frame sequencing (3.1.5)
L2TP provides no data security by itself, and any PPP security L2TP provides no data security by itself, and any PPP security
mechanisms used do not apply to the L2TP protocol itself, so that in mechanisms used do not apply to the L2TP protocol itself, so that in
order for strong security to be provided L2TP must run over IPSec. order for strong security to be provided L2TP must run over IPSec.
Defining specific modes of operation for IPSec when it is used to Defining specific modes of operation for IPSec when it is used to
support L2TP traffic will aid interoperability. This is currently a support L2TP traffic will aid interoperability. This is currently a
work item for the proposed L2TP working group. work item for the proposed L2TP working group.
4.0 VPN Types: Virtual Leased Lines 4.0 VPN Types: Virtual Leased Lines
The simplest form of a VPN is a 'virtual leased line' service. In The simplest form of a VPN is a 'Virtual Leased Line' (VLL) service.
this case a point-to-point link is provided to a customer, connecting In this case a point-to-point link is provided to a customer,
two CPE devices, as illustrated below. The link layer type used to connecting two CPE devices, as illustrated below. The link layer
connect the CPE devices to the ISP nodes can be any link layer type, type used to connect the CPE devices to the ISP nodes can be any link
for example an ATM VCC or a Frame Relay circuit. The CPE devices can layer type, for example an ATM VCC or a Frame Relay circuit. The CPE
be either routers bridges or hosts. devices can be either routers bridges or hosts.
The two ISP nodes are both connected to an IP network, and an IP The two ISP nodes are both connected to an IP network, and an IP
tunnel is set up between them. Each ISP node is configured to bind tunnel is set up between them. Each ISP node is configured to bind
the two links together at layer 2 (e.g. the ATM VCC and the IP the stub link and the IP tunnel together at layer 2 (e.g. an ATM VCC
tunnel). Frames are relayed between the two links. For example the and the IP tunnel). Frames are relayed between the two links. For
AAL5 payload is taken and encapsulated in an IPSec tunnel, and vice example the ATM Adaptation Layer 5 (AAL5) payload is taken and
versa. The contents of the AAL5 payload are opaque to the ISP node, encapsulated in an IPSec tunnel, and vice versa. The contents of the
and are not examined there. AAL5 payload are opaque to the ISP node, and are not examined there.
To a customer it looks the same as if a single ATM VCC or Frame Relay
circuit were used to interconnect the CPE devices, and the customer
could be unaware that part of the circuit was in fact implemented
over an IP backbone. This may be useful, for example, if a provider
wishes to provide a LAN interconnect service using ATM as the network
interface, but does not have an ATM network that directly
interconnects all possible customer sites.
+--------+ ----------- +--------+ +--------+ ----------- +--------+
+---+ | ISP | ( IP ) | ISP | +---+ +---+ | ISP | ( IP ) | ISP | +---+
|CPE|-------| edge |-----( backbone ) -----| edge |------|CPE| |CPE|-------| edge |-----( backbone ) -----| edge |------|CPE|
+---+ ATM | node | ( ) | node | ATM +---+ +---+ ATM | node | ( ) | node | ATM +---+
VCC +--------+ ----------- +--------+ VCC VCC +--------+ ----------- +--------+ VCC
<--------- IP Tunnel --------> <--------- IP Tunnel -------->
10.1.1.5 subnet = 10.1.1.4/30 10.1.1.6 10.1.1.5 subnet = 10.1.1.4/30 10.1.1.6
Addressing used by customer (transparent to provider) Addressing used by customer (transparent to provider)
Figure 4.1: VLL Example Figure 4.1: VLL Example
To a customer it looks the same as if a single ATM VCC or Frame Relay
circuit were used to interconnect the CPE devices, and the customer
could be unaware that part of the circuit was in fact implemented
over an IP backbone. This may be useful, for example, if a provider
wishes to provide a LAN interconnect service using ATM as the network
interface, but does not have an ATM network that directly
interconnects all possible customer sites.
It is not necessary that the two links used to connect the CPE It is not necessary that the two links used to connect the CPE
devices to the ISP nodes be of the same media type, but in this case devices to the ISP nodes be of the same media type, but in this case
the ISP nodes cannot treat the traffic in an opaque manner, as the ISP nodes cannot treat the traffic in an opaque manner, as
described above. Instead the ISP nodes must perform the functions of described above. Instead the ISP nodes must perform the functions of
an interworking device between the two media types (e.g. ATM and an interworking device between the two media types (e.g. ATM and
Frame Relay), and perform functions such as LLC/SNAP to NLPID Frame Relay), and perform functions such as LLC/SNAP to NLPID
conversion, mapping between ARP protocol variants and performing any conversion, mapping between ARP protocol variants and performing any
media specific processing that may be expected by the CPE devices media specific processing that may be expected by the CPE devices
(e.g. ATM OAM cell handling or Frame Relay XID exchanges). (e.g. ATM OAM cell handling or Frame Relay XID exchanges).
The IP tunneling protocol used must support multiprotocol operation The IP tunneling protocol used must support multiprotocol operation
and may need to support sequencing, if that characteristic is and may need to support sequencing, if that characteristic is
important to the customer traffic. If the tunnels are established important to the customer traffic. If the tunnels are established
using a signalling protocol, they may be set up in a data driven using a signalling protocol, they may be set up in a data driven
manner, when a frame is received from a customer link and no tunnel manner, when a frame is received from a customer link and no tunnel
exists, or the tunnels may be established at provisioning time and exists, or the tunnels may be established at provisioning time and
kept up permanently. kept up permanently.
Note that the use of the term 'VLL' in this document is different to Note that the use of the term 'VLL' in this document is different to
that used in the definition of the Diffserv Expedited Forwarding PHB that used in the definition of the Diffserv Expedited Forwarding Per
[Jacobson]. In that document a VLL is used to mean a low latency, Hop Behaviour (EF-PHB) [30]. In that document a VLL is used to mean
low jitter, assured bandwidth path, which can be provided using the a low latency, low jitter, assured bandwidth path, which can be
described PHB. Although the use of the term VLL in this document provided using the described PHB. Thus the focus there is primarily
shares some similarities with that in [Jacobson], in that a VLL can on link characteristics that are temporal in nature. In this document
be viewed as 'a wire', its use here is different, in that it refers the term VLL does not imply the use of any specific QoS mechanism,
to a generic link layer pipe, one segment of which is an IP tunnel, Diffserv or otherwise. Instead the focus is primarily on link
and does not imply any specific QoS mechanism, Diffserv or otherwise. characteristics that are more topological in nature, (e.g. such as
constructing a link which includes an IP tunnel as one segment of the
link). For a truly complete emulation of a link layer both the
temporal and topological aspects need to be taken into account.
5.0 VPN Types: Virtual Private Routed Networks 5.0 VPN Types: Virtual Private Routed Networks
A virtual private routed network (VPRN) is defined to be the 5.1 VPRN Characteristics
A Virtual Private Routed Network (VPRN) is defined to be the
emulation of a multi-site wide area routed network using IP emulation of a multi-site wide area routed network using IP
facilities. This section looks at how a network-based VPRN service facilities. This section looks at how a network-based VPRN service
can be provided. CPE-based VPRNs are also possible, but are not can be provided. CPE-based VPRNs are also possible, but are not
specifically discussed here. With network-based VPRNs many of the specifically discussed here. With network-based VPRNs many of the
issues that need to be addressed are concerned with configuration and issues that need to be addressed are concerned with configuration and
operational issues, which must take into account the split in operational issues, which must take into account the split in
administrative responsibility between the service provider (ISP) and administrative responsibility between the service provider and the
the service user (customer). service user.
A VPRN consists of a mesh of IP tunnels between ISP routers, together The distinguishing characteristic of a VPRN, in comparison to other
with the routing capabilities needed to forward traffic received at types of VPNs, is that packet forwarding is carried out at the
each VPRN node to the appropriate destination site. Attached to the network layer. A VPRN consists of a mesh of IP tunnels between ISP
ISP routers are CPE routers connected via one or more links, termed routers, together with the routing capabilities needed to forward
'stub' links. There is a VPRN specific forwarding table at each ISP traffic received at each VPRN node to the appropriate destination
router that contains members of the VPRN. Traffic is forwarded site. Attached to the ISP routers are CPE routers connected via one
between ISP routers, and between ISP routers and customer sites, or more links, termed 'stub' links. There is a VPRN specific
using these forwarding tables, which contain network layer forwarding table at each ISP router to which members of the VPRN are
reachability information (in contrast to a Virtual Private LAN connected. Traffic is forwarded between ISP routers, and between ISP
Segment type of VPN (VPLS) where the forwarding tables contain MAC routers and customer sites, using these forwarding tables, which
layer reachability information - see section 7.0). contain network layer reachability information (in contrast to a
Virtual Private LAN Segment type of VPN (VPLS) where the forwarding
tables contain MAC layer reachability information - see section 7.0).
An example VPRN is illustrated in the following diagram, which shows An example VPRN is illustrated in the following diagram, which shows
3 ISP edge routers connected via a full mesh of IP tunnels, used to 3 ISP edge routers connected via a full mesh of IP tunnels, used to
interconnect 4 CPE routers. One of the CPE routers is multihomed to interconnect 4 CPE routers. One of the CPE routers is multihomed to
the ISP network. In the multihomed case, all stub links may be the ISP network. In the multihomed case, all stub links may be
active, or, as shown, there may be one primary and one or more backup active, or, as shown, there may be one primary and one or more backup
links to be used in case of failure of the primary. The term 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 sites 'backdoor' link is used to refer to a link between two customer sites
that does not traverse the ISP network. that does not traverse the ISP network.
The principal benefit of a VPRN is that the complexity and the
configuration of the CPE routers is minimized. To a CPE router, the
ISP edge router appears as a neighbour router in the customer's
network, to which it sends all traffic, using a default route. The
tunnel mesh that is set up to transfer traffic extends between the
ISP edge routers, not the CPE routers. In effect the burden of
tunnel establishment and maintenance and routing configuration is
outsourced to the ISP. In addition other services needed for the
operation of a VPN such as the provision of a firewall and QoS
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 more
easily handled, as this can be achieved without the need to upgrade
any CPE equipment. This latter benefit is particularly important
when there may be large numbers of residential subscribers using VPN
services to access private corporate networks. In this respect the
model is somewhat akin to that used for telephony services, whereby
new services (e.g. call waiting) can be introduced with no change in
subscriber equipment.
10.1.1.0/30 +--------+ +--------+ 10.2.2.0/30 10.1.1.0/30 +--------+ +--------+ 10.2.2.0/30
+---+ | ISP | IP tunnel | ISP | +---+ +---+ | ISP | IP tunnel | ISP | +---+
|CPE|-------| edge |<--------------------->| edge |-------|CPE| |CPE|-------| edge |<--------------------->| edge |-------|CPE|
+---+ stub | router | 10.9.9.4/30 | router | stub +---+ +---+ stub | router | 10.9.9.4/30 | router | stub +---+
link +--------+ +--------+ link : link +--------+ +--------+ link :
| ^ | | ^ : | ^ | | ^ :
| | | --------------- | | : | | | --------------- | | :
| | +----( )----+ | : | | +----( )----+ | :
| | ( IP BACKBONE ) | : | | ( IP BACKBONE ) | :
| | ( ) | : | | ( ) | :
skipping to change at page 20, line 29 skipping to change at page 21, line 38
| +---------->| edge |<----------+ : | +---------->| edge |<----------+ :
| 10.9.9.8/30 | router | 10.9.9.12/30 : | 10.9.9.8/30 | router | 10.9.9.12/30 :
backup| +--------+ backdoor: backup| +--------+ backdoor:
link | | | link : link | | | link :
| stub link | | stub link : | stub link | | stub link :
| | | : | | | :
| +---+ +---+ : | +---+ +---+ :
+-------------|CPE| |CPE|.......................: +-------------|CPE| |CPE|.......................:
10.3.3.0/30 +---+ +---+ 10.4.4.0/30 10.3.3.0/30 +---+ +---+ 10.4.4.0/30
Figure 5.1: Example VPRN Figure 5.1: VPRN Example
The principal benefit of a VPRN is that the complexity and the
configuration of the CPE routers is minimized. To a CPE router, the
ISP edge router appears as a neighbour router in the customer's
network, to which it sends all traffic, using a default route. The
tunnel mesh that is set up to transfer traffic extends between the
ISP edge routers, not the CPE routers. In effect the burden of
tunnel establishment and maintenance and routing configuration is
outsourced to the ISP. In addition other services needed for the
operation of a VPN such as the provision of a firewall and QoS
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 more
easily handled, as this can be achieved without the need to upgrade
any CPE equipment. This latter benefit is particularly important
when there may be large numbers of residential subscribers using VPN
services to access private corporate networks. In this respect the
model is somewhat akin to that used for telephony services, whereby
new services (e.g. call waiting) can be introduced with no change in
subscriber equipment.
The VPRN type of VPN is in contrast to one where the tunnel mesh The VPRN type of VPN is in contrast to one where the tunnel mesh
extends to the CPE routers, and where the ISP network provides layer extends to the CPE routers, and where the ISP network provides layer
2 connectivity alone. The latter case can be implemented either as a 2 connectivity alone. The latter case can be implemented either as a
set of VLLs between CPE routers (see section 4.0), in which case the set of VLLs between CPE routers (see section 4.0), in which case the
ISP network provides a set of layer 2 point-to-point links, or as a ISP network provides a set of layer 2 point-to-point links, or as a
VPLS (see section 7.0), in which case the ISP network is used to VPLS (see section 7.0), in which case the ISP network is used to
emulate a multiaccess LAN segment. With these scenarios a customer emulate a multiaccess LAN segment. With these scenarios a customer
may have more flexibility (e.g. any IGP or any protocol can be run may have more flexibility (e.g. any IGP or any protocol can be run
across all customer sites) but this usually comes at the expense of a across all customer sites) but this usually comes at the expense of a
skipping to change at page 21, line 8 skipping to change at page 22, line 38
Because a VPRN carries out forwarding at the network layer, a single Because a VPRN carries out forwarding at the network layer, a single
VPRN only directly supports a single network layer protocol. For VPRN only directly supports a single network layer protocol. For
multiprotocol support, a separate VPRN for each network layer multiprotocol support, a separate VPRN for each network layer
protocol could be used, or one protocol could be tunneled over protocol could be used, or one protocol could be tunneled over
another (e.g. non-IP protocols tunneled over an IP VPRN) or another (e.g. non-IP protocols tunneled over an IP VPRN) or
alternatively the ISP network could be used to provide layer 2 alternatively the ISP network could be used to provide layer 2
connectivity only, such as with a VPLS as mentioned above. connectivity only, such as with a VPLS as mentioned above.
The issues to be addressed for VPRNs include initial configuration, The issues to be addressed for VPRNs include initial configuration,
determination by an ISP edge router of the set of links that are in determination by an ISP edge router of the set of links that are in
each VPRN, and of the set of other routers that have members in the each VPRN, the set of other routers that have members in the VPRN,
VPRN, determination by an ISP edge router of the set of IP address and the set of IP address prefixes reachable via each stub link,
prefixes reachable via each stub link, determination by a CPE router determination by a CPE router of the set of IP address prefixes to be
of the set of IP address prefixes to be forwarded to an ISP edge forwarded to an ISP edge router, the mechanism used to disseminate
router, the mechanism used to disseminate stub reachability stub reachability information to the correct set of ISP routers, and
information to the correct set of ISP routers, and the establishment the establishment and use of the tunnels used to carry the data
and use of the tunnels used to carry the data traffic. Note also traffic. Note also that, although discussed first for VPRNs, many of
that, although discussed first for VPRNs, many of these issues also these issues also apply to the VPLS scenario described later, with
apply to the VPLS scenario described later, with the network layer the network layer addresses being replaced by link layer addresses.
addresses being replaced by link layer addresses.
Note that VPRN operation is decoupled from the mechanisms used by the Note that VPRN operation is decoupled from the mechanisms used by the
customer sites to access the Internet. A typical scenario would be customer sites to access the Internet. A typical scenario would be
for the ISP edge router to be used to provide both VPRN and Internet for the ISP edge router to be used to provide both VPRN and Internet
connectivity to a customer site. In this case the CPE router just connectivity to a customer site. In this case the CPE router just
has a default route pointing to the ISP edge router, with the latter has a default route pointing to the ISP edge router, with the latter
being responsible for steering private traffic to the VPRN, and other being responsible for steering private traffic to the VPRN and other
traffic to the Internet, and providing firewall functionality between traffic to the Internet, and providing firewall functionality between
the two domains. Alternatively a customer site could have Internet the two domains. Alternatively a customer site could have Internet
connectivity via an ISP router not involved in the VPRN, or even via connectivity via an ISP router not involved in the VPRN, or even via
a different ISP. In this case the CPE device is responsible for a different ISP. In this case the CPE device is responsible for
splitting the traffic into the two domains and providing firewall splitting the traffic into the two domains and providing firewall
functionality. functionality.
A. Topology 5.1.1 Topology
The topology of a VPRN may consist of a full mesh of tunnels between The topology of a VPRN may consist of a full mesh of tunnels between
each VPRN node, or may be an arbitrary topology, such as a set of each VPRN node, or may be an arbitrary topology, such as a set of
remote offices connected to the nearest regional site, with these remote offices connected to the nearest regional site, with these
regional sites connected together via a full or partial mesh. With regional sites connected together via a full or partial mesh. With
VPRNs using IP tunnels there is much less cost assumed with full VPRNs using IP tunnels there is much less cost assumed with full
meshing than in cases where physical resources (e.g. a leased line) meshing than in cases where physical resources (e.g. a leased line)
must be allocated for each connected pair of sites, or where the must be allocated for each connected pair of sites, or where the
tunneling method requires resources to be allocated in the devices tunneling method requires resources to be allocated in the devices
used to interconnect the edge routers (e.g Frame Relay DLCIs). A used to interconnect the edge routers (e.g Frame Relay DLCIs). A
full mesh topology yields optimal routing, since it precludes the full mesh topology yields optimal routing, since it precludes the
need for traffic between two sites to traverse through a third. need for traffic between two sites to traverse a third. Another
Another attraction of a full mesh is that there is no need to attraction of a full mesh is that there is no need to configure
configure topology information for the VPRN. Instead, given the topology information for the VPRN. Instead, given the member routers
member routers of a VPRN, the topology is implicit. If the number of of a VPRN, the topology is implicit. If the number of ISP edge
ISP edge routers in a VPRN is very large, however, a full mesh routers in a VPRN is very large, however, a full mesh topology may
topology may not be appropriate, due to the scaling issues involved, not be appropriate, due to the scaling issues involved, for example,
for example, the growth in the number of tunnels needed between the growth in the number of tunnels needed between sites, (which for
sites, (which for n sites is n(n-1)/2), or the number of routing n sites is n(n-1)/2), or the number of routing peers per router.
peers per router. Network policy may also lead to non full mesh Network policy may also lead to non full mesh topologies, for example
topologies, for example an administrator may wish to set up the an administrator may wish to set up the topology so that traffic
topology so that traffic between two remote sites passes through a between two remote sites passes through a central site, rather than
central site, rather than go directly between the remote sites. It go directly between the remote sites. It is also necessary to deal
is also necessary to deal with the scenario where there is only with the scenario where there is only partial connectivity across the
partial connectivity across the IP backbone under certain error IP backbone under certain error conditions (e.g. A can reach B, and B
conditions (e.g. A can reach B, and B can reach C, but A cannot reach can reach C, but A cannot reach C directly), which can occur if
C directly), which can occur if policy routing is being used. policy routing is being used.
For a network-based VPRN, it is assumed that each customer site CPE For a network-based VPRN, it is assumed that each customer site CPE
router connects to an ISP edge router through one or more point-to- 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). point stub links (e.g. leased lines, ATM or Frame Relay connections).
The ISP routers are responsible for learning and disseminating The ISP routers are responsible for learning and disseminating
reachability information amongst themselves. The CPE routers must reachability information amongst themselves. The CPE routers must
learn the set of destinations reachable via each stub link, though learn the set of destinations reachable via each stub link, though
this may be as simple as a default route. this may be as simple as a default route.
The stub links may either be dedicated links, set up via The stub links may either be dedicated links, set up via
provisioning, or may be dynamic links set up on demand, for example provisioning, or may be dynamic links set up on demand, for example
using PPP, voluntary tunneling (see section 6.2), or ATM signalling. using PPP, voluntary tunneling (see section 6.3), or ATM signalling.
With dynamic links it is necessary to authenticate the subscriber, With dynamic links it is necessary to authenticate the subscriber,
and determine the authorized resources that the subscriber can access and determine the authorized resources that the subscriber can access
(e.g. which VPRNs the subscriber may join). Other than the way the (e.g. which VPRNs the subscriber may join). Other than the way the
subscriber is initially bound to the VPRN, (and this process may subscriber is initially bound to the VPRN, (and this process may
involve extra considerations such as dynamic IP address assignment), involve extra considerations such as dynamic IP address assignment),
the subsequent VPRN mechanisms and services can be used for both the subsequent VPRN mechanisms and services can be used for both
types of subscribers in the same way. types of subscribers in the same way.
B. Addressing 5.1.2 Addressing
The addressing used within a VPRN may have no relation to the The addressing used within a VPRN may have no relation to the
addressing used on the IP backbone over which the VPRN is addressing used on the IP backbone over which the VPRN is
instantiated. In particular non-unique private IP addressing may be instantiated. In particular non-unique private IP addressing may be
used [Rekhter1]. Multiple VPRNs may be instantiated over the same used [4]. Multiple VPRNs may be instantiated over the same set of
set of physical devices, and they may use the same or overlapping physical devices, and they may use the same or overlapping address
address spaces. spaces.
C. Forwarding 5.1.3 Forwarding
For a VPRN the tunnel mesh forms an overlay network operating over an For a VPRN the tunnel mesh forms an overlay network operating over an
IP backbone. Within each of the ISP edge routers there must be VPN IP backbone. Within each of the ISP edge routers there must be VPN
specific forwarding state to forward packets received from stub links specific forwarding state to forward packets received from stub links
('ingress traffic') to the appropriate next hop router, and to ('ingress traffic') to the appropriate next hop router, and to
forward packets received from the core ('egress traffic') to the forward packets received from the core ('egress traffic') to the
appropriate stub link. For cases where an ISP edge router supports appropriate stub link. For cases where an ISP edge router supports
multiple stub links belonging to the same VPRN, the tunnels can, as a multiple stub links belonging to the same VPRN, the tunnels can, as a
local matter, either terminate on the edge router, or on a stub link. local matter, either terminate on the edge router, or on a stub link.
In the former case a VPN specific forwarding table is needed for In the former case a VPN specific forwarding table is needed for
egress traffic, in the latter case it is not. A VPN specific egress traffic, in the latter case it is not. A VPN specific
forwarding table is generally needed in the ingress direction, in forwarding table is generally needed in the ingress direction, in
order to direct traffic received on a stub link onto the correct IP order to direct traffic received on a stub link onto the correct IP
tunnel towards the core. tunnel towards the core.
Also since a VPRN operates at the internetwork layer, the IP packets Also since a VPRN operates at the internetwork layer, the IP packets
sent over a tunnel will have their TTL field decremented in the sent over a tunnel will have their Time to Live (TTL) field
normal manner, preventing packets circulating indefinitely in the decremented in the normal manner, preventing packets circulating
event of a routing loop within the VPRN. indefinitely in the event of a routing loop within the VPRN.
D. Multiple concurrent VPRN connectivity 5.1.4 Multiple concurrent VPRN connectivity
Note also that a single customer site may belong concurrently to Note also that a single customer site may belong concurrently to
multiple VPRNs and may want to transmit traffic both onto one or more multiple VPRNs and may want to transmit traffic both onto one or more
VPRNs and to the default Internet, over the same stub link. There VPRNs and to the default Internet, over the same stub link. There
are a number of possible approaches to this problem, but these are are a number of possible approaches to this problem, but these are
outside the scope of this document. outside the scope of this document.
5.1 VPRN related work 5.2 VPRN Related Work
VPRN requirements and mechanisms have been discussed previously in a VPRN requirements and mechanisms have been discussed previously in a
number of different documents. One of the first was [Heinanen2], number of different documents. One of the first was [10], which
which showed how the same VPN functionality can be implemented over showed how the same VPN functionality can be implemented over both
both MPLS and non-MPLS networks. Some others are briefly discussed MPLS and non-MPLS networks. Some others are briefly discussed below.
below.
There are two main variants as regards the mechanisms used to provide There are two main variants as regards the mechanisms used to provide
VPRN membership and reachability functionality, - overlay and VPRN membership and reachability functionality, - overlay and
piggybacking. These are discussed in greater detail in sections piggybacking. These are discussed in greater detail in sections
5.2.2, 5.2.3 and 5.2.4 below. An example of the overlay model is 5.3.2, 5.3.3 and 5.3.4 below. An example of the overlay model is
described in [Muthukrishnan], which discusses the provision of VPRN described in [14], which discusses the provision of VPRN
functionality by means of a separate per-VPN routing protocol functionality by means of a separate per-VPN routing protocol
instance and route and forwarding table instantiation, otherwise instance and route and forwarding table instantiation, otherwise
known as virtual routing. Each VPN routing instance is isolated from known as virtual routing. Each VPN routing instance is isolated from
any other VPN routing instance, and from the routing used across the any other VPN routing instance, and from the routing used across the
backbone. As a result any routing protocol (e.g. OSPF, RIP2, IS-IS) backbone. As a result any routing protocol (e.g. OSPF, RIP2, IS-IS)
can be run with any VPRN, independently of the routing protocols used can be run with any VPRN, independently of the routing protocols used
in other VPRNs, or in the backbone itself. The VPN model described in other VPRNs, or in the backbone itself. The VPN model described
in [Casey1] is also an overlay VPRN model using virtual routing. in [12] is also an overlay VPRN model using virtual routing. That
That document is specifically geared towards the provision of VPRN document is specifically geared towards the provision of VPRN
functionality over MPLS backbones, and it describes how VPRN functionality over MPLS backbones, and it describes how VPRN
membership dissemination can be automated over an MPLS backbone, by membership dissemination can be automated over an MPLS backbone, by
performing VPN neighbour discovery over the base MPLS tunnel mesh. performing VPN neighbour discovery over the base MPLS tunnel mesh.
[Casey2] extends the virtual routing model to include VPN areas, and [31] extends the virtual routing model to include VPN areas, and VPN
VPN border routers which route between VPN areas. VPN areas may be border routers which route between VPN areas. VPN areas may be
defined for administrative or technical reasons, such as different defined for administrative or technical reasons, such as different
underlying network infrastructures (e.g. ATM, MPLS, IP). underlying network infrastructures (e.g. ATM, MPLS, IP).
In contrast [Rosen1] describes the provision of VPN functionality In contrast [15] describes the provision of VPN functionality using a
using a piggybacking approach for membership and reachability piggybacking approach for membership and reachability dissemination,
dissemination, with this information being piggybacked in BGP. VPNs with this information being piggybacked in Border Gateway Protocol 4
are constructed using BGP policies, which are used to control which (BGP) [32] packets. VPNs are constructed using BGP policies, which
sites can communicate with each other. [Li2] also uses BGP for are used to control which sites can communicate with each other. [13]
piggybacking membership information, and piggybacks reachability also uses BGP for piggybacking membership information, and piggybacks
information on the protocol used to establish MPLS LSPs (LDP or reachability information on the protocol used to establish MPLS LSPs
RSVP). Unlike the other proposals, however, this proposal requires (CR-LDP or extended RSVP). Unlike the other proposals, however, this
the participation on the CPE router to implement the VPN proposal requires the participation on the CPE router to implement
functionality. the VPN functionality.
5.2 VPRN Generic Requirements 5.3 VPRN Generic Requirements
There are a number of common requirements which any network-based There are a number of common requirements which any network-based
VPRN solution must address, and there are a number of different VPRN solution must address, and there are a number of different
mechanisms that can be used to meet these requirements. These mechanisms that can be used to meet these requirements. These
generic issues are generic issues are
- The use of a globally unique VPN identifier in order to be able to 1) The use of a globally unique VPN identifier in order to be able to
refer to a particular VPN. refer to a particular VPN.
- VPRN membership determination. An edge router must learn of the 2) VPRN membership determination. An edge router must learn of the
local stub links that are in each VPRN, and must learn of the set local stub links that are in each VPRN, and must learn of the set
of other routers that have members in that VPRN. of other routers that have members in that VPRN.
- Stub link reachability information. An edge router must learn the 3) Stub link reachability information. An edge router must learn the
set of addresses and address prefixes reachable via each stub set of addresses and address prefixes reachable via each stub
link. link.
- Intra-VPRN reachability information. Once an edge router has 4) Intra-VPRN reachability information. Once an edge router has
determined the set of address prefixes associated with each of its determined the set of address prefixes associated with each of its
stub links, then this information must be disseminated to each stub links, then this information must be disseminated to each
other edge router in the VPRN. other edge router in the VPRN.
- Tunneling mechanism. An edge router must construct the necessary 5) Tunneling mechanism. An edge router must construct the necessary
tunnels to other routers that have members in the VPRN, and must tunnels to other routers that have members in the VPRN, and must
perform the encapsulation and decapsulation necessary to send and perform the encapsulation and decapsulation necessary to send and
receive packets over the tunnels. receive packets over the tunnels.
5.2.1 VPN Identifier 5.3.1 VPN Identifier
The IETF [Fox] and the ATM Forum [Petri] have standardized on a The IETF [16] and the ATM Forum [17] have standardized on a single
single format for a globally unique identifier used to identify a VPN format for a globally unique identifier used to identify a VPN - a
- a VPN-ID. Only the format of the VPN-ID has been defined, not its VPN-ID. Only the format of the VPN-ID has been defined, not its
semantics or usage. The aim is to allow its use for a wide variety semantics or usage. The aim is to allow its use for a wide variety
of purposes, and to allow the same identifier to used in with of purposes, and to allow the same identifier to used with different
different technologies and mechanisms. For example a VPN-ID can be technologies and mechanisms. For example a VPN-ID can be included in
included in a MIB to to identify a VPN for management purposes. A a MIB to identify a VPN for management purposes. A VPN-ID can be
VPN-ID can be used in a control plane protocol, for example to bind a used in a control plane protocol, for example to bind a tunnel to a
tunnel to a VPN at tunnel establishment time. All packets that VPN at tunnel establishment time. All packets that traverse the
traverse the tunnel are then implicitly associated with the tunnel are then implicitly associated with the identified VPN. A
identified VPN. A VPN-ID can be used in a data plane encapsulation, VPN-ID can be used in a data plane encapsulation, to allow for an
to allow for an explicit per-packet identification of the VPN explicit per-packet identification of the VPN associated with the
associated with the packet. If a VPN is implemented using different packet. If a VPN is implemented using different technologies (e.g IP
technologies (e.g IP and ATM) in a network, the same identifier can and ATM) in a network, the same identifier can be used to identify
be used to identify the VPN across the different technologies. Also the VPN across the different technologies. Also if a VPN spans
if a VPN spans multiple administrative domains the same identifier multiple administrative domains the same identifier can be used
can be used everywhere. everywhere.
Most of the VPN schemes developed (e.g. [Muthukrishnan], [Jamieson], Most of the VPN schemes developed (e.g. [11], [12], [13], [14])
[Casey1], [Li2]) require the use of a VPN-ID that is carried in require the use of a VPN-ID that is carried in control and/or data
control and/or data packets, which is used to associate the packet packets, which is used to associate the packet with a particular VPN.
with a particular VPN. Although the use of a VPN-ID in this manner Although the use of a VPN-ID in this manner is very common, it is not
is very common, it is not universal. [Rosen1] describes a scheme universal. [15] describes a scheme where there is no protocol field
where there is no protocol field used to identify a VPN in this used to identify a VPN in this manner. In this scheme the VPNs as
manner. In this scheme the VPNs as understood by a user, are understood by a user, are administrative constructs, built using BGP
administrative constructs, built using BGP policies. There are a policies. There are a number of attributes associated with VPN
number of attributes associated with VPN routes, such as a route routes, such as a route distinguisher, and origin and target "VPN",
distinguisher, and origin and target "VPN", that are used by the that are used by the underlying protocol mechanisms for
underlying protocol mechanisms for disambiguation and scoping, and disambiguation and scoping, and these are also used by the BGP policy
these are also used by the BGP policy mechanism in the construction mechanism in the construction of VPNs, but there is nothing
of VPNs, but there is nothing corresponding with the VPN-ID as used corresponding with the VPN-ID as used in the other documents.
in the other documents.
Note also that [Grossman] defines a multiprotocol encapsulation for Note also that [33] defines a multiprotocol encapsulation for use
use over ATM AAL5 that uses the standard VPN-ID format. over ATM AAL5 that uses the standard VPN-ID format.
5.2.2 VPN Membership Information Configuration and Dissemination 5.3.2 VPN Membership Information Configuration and Dissemination
In order to establish a VPRN, or to insert new customer sites into an In order to establish a VPRN, or to insert new customer sites into an
established VPRN, an ISP edge router must determine which stub links established VPRN, an ISP edge router must determine which stub links
are associated with which VPRN. For static links (e.g. an ATM VCC) are associated with which VPRN. For static links (e.g. an ATM VCC)
this information must be configured into the edge router, since the this information must be configured into the edge router, since the
edge router cannot infer such bindings by itself. A management edge router cannot infer such bindings by itself. An SNMP MIB
information base (MIB) allowing for bindings between local stub links allowing for bindings between local stub links and VPN identities is
and VPN identities is one solution. one solution.
For subscribers that attach to the network dynamically (e.g. using For subscribers that attach to the network dynamically (e.g. using
PPP or voluntary tunneling) it is possible to make the association PPP or voluntary tunneling) it is possible to make the association
between stub link and VPRN as part of the end user authentication between stub link and VPRN as part of the end user authentication
processing that must occur with such dynamic links. For example the processing that must occur with such dynamic links. For example the
VPRN to which a user is to be bound may be derived from the domain VPRN to which a user is to be bound may be derived from the domain
name the used as part of PPP authentication. If the user is name the used as part of PPP authentication. If the user is
successfully authenticated (e.g. using a Radius server), then the successfully authenticated (e.g. using a Radius server), then the
newly created dynamic link can be bound to the correct VPRN. Note newly created dynamic link can be bound to the correct VPRN. Note
that static configuration information is still needed, for example to that static configuration information is still needed, for example to
skipping to change at page 26, line 20 skipping to change at page 27, line 48
After learning which stub links are bound to which VPRN, each edge After learning which stub links are bound to which VPRN, each edge
router must learn either the identity of, or, at least, the route to, router must learn either the identity of, or, at least, the route to,
each other edge router supporting other stub links in that particular each other edge router supporting other stub links in that particular
VPRN. Implicit in the latter is the notion that there exists some VPRN. Implicit in the latter is the notion that there exists some
mechanism by which the configured edge routers can then use this edge mechanism by which the configured edge routers can then use this edge
router and/or stub link identity information to subsequently set up router and/or stub link identity information to subsequently set up
the appropriate tunnels between them. The problem of VPRN member the appropriate tunnels between them. The problem of VPRN member
dissemination between participating edge routers, can be solved in a dissemination between participating edge routers, can be solved in a
variety of ways, discussed below. variety of ways, discussed below.
A. Directory Lookup: 5.3.2.1 Directory Lookup
The members of a particular VPRN, that is, the identity of the edge The members of a particular VPRN, that is, the identity of the edge
routers supporting stub links in the VPRN, and the set of static stub routers supporting stub links in the VPRN, and the set of static stub
links bound to the VPRN per edge router, could be configured into a links bound to the VPRN per edge router, could be configured into a
directory, which edge routers could query, using some defined directory, which edge routers could query, using some defined
mechanism (e.g. LDAP), upon startup. mechanism (e.g. Lightweight Directory Access Protocol (LDAP) [34]),
upon startup.
Using a directory allows either a full mesh topology or an arbitrary Using a directory allows either a full mesh topology or an arbitrary
topology to be configured. For a full mesh, the full list of member topology to be configured. For a full mesh, the full list of member
routers in a VPRN is distributed everywhere. For an arbitrary routers in a VPRN is distributed everywhere. For an arbitrary
topology, different routers may receive different member lists. topology, different routers may receive different member lists.
Using a directory allows for authorization checking prior to Using a directory allows for authorization checking prior to
disseminating VPRN membership information, which may be desirable disseminating VPRN membership information, which may be desirable
where VPRNs span multiple administrative domains. In such a case, where VPRNs span multiple administrative domains. In such a case,
directory to directory protocol mechanisms could also be used to directory to directory protocol mechanisms could also be used to
propagate authorized VPRN membership information between the propagate authorized VPRN membership information between the
directory systems of the multiple administrative domains. directory systems of the multiple administrative domains.
There is also need to be some form of database synchronization There also needs to be some form of database synchronization
mechanism (e.g. triggered or regular polling of the directory by edge mechanism (e.g. triggered or regular polling of the directory by edge
routers, or active pushing of update information to the edge routers routers, or active pushing of update information to the edge routers
by the directory) in order for all edge routers to learn the identity by the directory) in order for all edge routers to learn the identity
of newly configured sites inserted into an active VPRN, and also to of newly configured sites inserted into an active VPRN, and also to
learn of sites removed from a VPRN. learn of sites removed from a VPRN.
B. Explicit Management Configuration: 5.3.2.2 Explicit Management Configuration
A VPRN Management Information Base (MIB) could be defined which would A VPRN MIB could be defined which would allow a central management
allow a central management system to configure each edge router with system to configure each edge router with the identities of each
the identities of each other participating edge router and the other participating edge router and the identity of each of the
identity of each of the static stub links bound to the VPRN. Like the static stub links bound to the VPRN. Like the use of a directory,
use of a directory, this mechanism allows both full mesh and this mechanism allows both full mesh and arbitrary topologies to be
arbitrary topologies to be configured. Another mechanism using a configured. Another mechanism using a centralized management system
centralized management system is to use a policy server and use the is to use a policy server and use the Common Open Policy Service
Common Open Policy Service (COPS) protocol [Boyle] to distribute VPRN (COPS) protocol [35] to distribute VPRN membership and policy
membership and policy information, such as the tunnel attributes to information, such as the tunnel attributes to use when establishing a
use when establishing a tunnel, as described in [MacRae]. tunnel, as described in [36].
Note that this mechanism allows the management station to impose Note that this mechanism allows the management station to impose
strict authorization control; on the other hand, it may be more strict authorization control; on the other hand, it may be more
difficult to configure edge routers outside the scope of the difficult to configure edge routers outside the scope of the
management system. The management configuration model can also be management system. The management configuration model can also be
considered a subset of the directory method, in that the management considered a subset of the directory method, in that the management
directories could use MIBs to push VPRN membership information to the directories could use MIBs to push VPRN membership information to the
participating edge routers, either subsequent to, or as part of, the participating edge routers, either subsequent to, or as part of, the
local stub link configuration process. local stub link configuration process.
C. Piggybacking in Routing Protocols: 5.3.2.3 Piggybacking in Routing Protocols
VPRN membership information could be piggybacked into the routing VPRN membership information could be piggybacked into the routing
protocols run by each edge router across the IP backbone, since this protocols run by each edge router across the IP backbone, since this
is an efficient means of automatically propagating information is an efficient means of automatically propagating information
throughout the network to other participating edge routers. throughout the network to other participating edge routers.
Specifically, each route advertisement by each edge router could Specifically, each route advertisement by each edge router could
include, at the minimum, the set of VPN identifiers associated with include, at a minimum, the set of VPN identifiers associated with
each edge router, and adequate information to allow other edge each edge router, and adequate information to allow other edge
routers to determine the identity of, and/or, the route to, the routers to determine the identity of, and/or, the route to, the
particular edge router. Other edge routers would examine received particular edge router. Other edge routers would examine received
route advertisements to determine if any contained information was route advertisements to determine if any contained information was
relevant to a supported (i.e. configured) VPRN; this determination relevant to a supported (i.e. configured) VPRN; this determination
could be done by looking for a VPN identifier matching a locally could be done by looking for a VPN identifier matching a locally
configured VPN. The nature of the piggybacked information, and configured VPN. The nature of the piggybacked information, and
related issues, such as scoping, and the means by which the nodes related issues, such as scoping, and the means by which the nodes
advertising particular VPN memberships will be identified, will advertising particular VPN memberships will be identified, will
generally be a function both of the routing protocol and of the generally be a function both of the routing protocol and of the
nature of the underlying transport. nature of the underlying transport.
Using this method all the routers in the network will have the same Using this method all the routers in the network will have the same
view of the VPRN membership information, and so a full mesh topology view of the VPRN membership information, and so a full mesh topology
is easily supported. Supporting an arbitrary topology is more is easily supported. Supporting an arbitrary topology is more
difficult, however, since some form of pruning would seem to be difficult, however, since some form of pruning would seem to be
needed. needed.
The advantage of the piggybacking scheme is that it allows for The advantage of the piggybacking scheme is that it allows for
efficient information dissemination, particularly across multiple efficient information dissemination, but it does require that all
routing domains (e.g. across different autonomous systems/ISPs) but nodes in the path, and not just the participating edge routers, be
it does require that all nodes in the path, and not just the able to accept such modified route advertisements. A disadvantage is
participating edge routers, be able to accept such modified route that significant administrative complexity may be required to
advertisements. On the other hand, significant administrative configure scoping mechanisms so as to both permit and constrain the
complexity may be required to configure scoping mechanisms so as to dissemination of the piggybacked advertisements, and in itself this
both permit and constrain the dissemination of the piggybacked may be quite a configuration burden, particularly if the VPRN spans
advertisements, and in itself this may be quite a configuration multiple routing domains (e.g. different autonomous systems / ISPs).
burden.
Furthermore, unless some security mechanism is used for routing Furthermore, unless some security mechanism is used for routing
updates so as to permit only all relevant edge routers to read the updates so as to permit only all relevant edge routers to read the
piggybacked advertisements, this scheme generally implies a trust piggybacked advertisements, this scheme generally implies a trust
model where all routers in the path must perforce be authorized to model where all routers in the path must perforce be authorized to
know this information. Depending upon the nature of the routing know this information. Depending upon the nature of the routing
protocol, piggybacking may also require intermediate routers, protocol, piggybacking may also require intermediate routers,
particularly autonomous system (AS) border routers, to cache such particularly autonomous system (AS) border routers, to cache such
advertisements and potentially also re-distribute them between advertisements and potentially also re-distribute them between
multiple routing protocols. multiple routing protocols.
skipping to change at page 28, line 32 skipping to change at page 30, line 14
centralized directory or management system which will maintain VPRN centralized directory or management system which will maintain VPRN
membership information, such as the set of edge routers that are membership information, such as the set of edge routers that are
allowed to support a certain VPRN, the bindings of static stub links allowed to support a certain VPRN, the bindings of static stub links
to VPRNs, or authentication and authorization information for users to VPRNs, or authentication and authorization information for users
that access the network via dynamics links. This information needs that access the network via dynamics links. This information needs
to be configured and stored in some form of database, so that the to be configured and stored in some form of database, so that the
additional steps needed to facilitate the configuration of such additional steps needed to facilitate the configuration of such
information into edge routers, and/or, facilitate edge router access information into edge routers, and/or, facilitate edge router access
to such information, may not be excessively onerous. to such information, may not be excessively onerous.
5.2.3 Stub Link Reachability Information 5.3.3 Stub Link Reachability Information
There are two aspects to stub site reachability - the means by which There are two aspects to stub site reachability - the means by which
VPRN edge routers determine the set of VPRN addresses and address VPRN edge routers determine the set of VPRN addresses and address
prefixes reachable at each stub site, and the means by which the CPE prefixes reachable at each stub site, and the means by which the CPE
routers learn the destinations reachable via each stub link. A routers learn the destinations reachable via each stub link. A
number of common scenarios are outlined below. In each case the number of common scenarios are outlined below. In each case the
information needed by the ISP edge router is the same - the set of information needed by the ISP edge router is the same - the set of
VPRN addresses reachable at the customer site, but the information VPRN addresses reachable at the customer site, but the information
needed by the CPE router differs. needed by the CPE router differs.
1. The CPE router is connected via one link to an ISP edge 5.3.3.1 Stub Link Connectivity Scenarios
router, which provides both VPRN and Internet connectivity.
5.3.3.1.1 Dual VPRN and Internet Connectivity
The CPE router is connected via one link to an ISP edge router, which
provides both VPRN and Internet connectivity.
This is the simplest case for the CPE router, as it just needs a This is the simplest case for the CPE router, as it just needs a
default route pointing to the ISP edge router. default route pointing to the ISP edge router.
2. The CPE router is connected via one link to an ISP edge 5.3.3.1.2 VPRN Connectivity Only
router, which provides VPRN, but not Internet, connectivity.
The CPE router is connected via one link to an ISP edge router, which
provides VPRN, but not Internet, connectivity.
The CPE router must know the set of non-local VPRN destinations The CPE router must know the set of non-local VPRN destinations
reachable via that link. This may be a single prefix, or may be a reachable via that link. This may be a single prefix, or may be a
number of disjoint prefixes. The CPE router may be either statically number of disjoint prefixes. The CPE router may be either statically
configured with this information, or may learn it dynamically by configured with this information, or may learn it dynamically by
running an instance of an IGP. For simplicity it is assumed that the running an instance of an Interior Gateway Protocol (IGP). For
IGP used for this purpose is RIP, though it could be any IGP. The simplicity it is assumed that the IGP used for this purpose is RIP,
ISP edge router will inject into this instance of RIP the VRPN routes though it could be any IGP. The ISP edge router will inject into
which it learns by means of one of the intra-VPRN reachability this instance of RIP the VRPN routes which it learns by means of one
mechanisms described in section 5.2.4. Note that the instance of RIP of the intra-VPRN reachability mechanisms described in section 5.3.4.
run to the CPE, and any instance of a routing protocol used to learn Note that the instance of RIP run to the CPE, and any instance of a
intra-VPRN reachability (even if also RIP) are separate, with the ISP routing protocol used to learn intra-VPRN reachability (even if also
edge router redistributing the routes from one instance to another. RIP) are separate, with the ISP edge router redistributing the routes
from one instance to another.
3. The CPE router is multihomed to the ISP network, which 5.3.3.1.3 Multihomed Connectivity
provides VPRN connectivity.
The CPE router is multihomed to the ISP network, which provides VPRN
connectivity.
In this case all the ISP edge routers could advertise the same VPRN In this case all the ISP edge routers could advertise the same VPRN
routes to the CPE router, which then sees all VPRN prefixes equally routes to the CPE router, which then sees all VPRN prefixes equally
reachable via all links. More specific route redistribution is also reachable via all links. More specific route redistribution is also
possible, whereby each ISP edge router advertises a different set of possible, whereby each ISP edge router advertises a different set of
prefixes to the CPE router. prefixes to the CPE router.
4. The CPE router is connected to the ISP network, which 5.3.3.1.4 Backdoor Links
provides VPRN connectivity, but also has a backdoor link
to another customer site The CPE router is connected to the ISP network, which provides VPRN
connectivity, but also has a backdoor link to another customer site
In this case the ISP edge router will advertise VPRN routes as in In this case the ISP edge router will advertise VPRN routes as in
case 2 to the CPE device. However now the same destination is case 2 to the CPE device. However now the same destination is
reachable via both the ISP edge router and via the backdoor link. If reachable via both the ISP edge router and via the backdoor link. If
the CPE routers connected to the backdoor link are running the the CPE routers connected to the backdoor link are running the
customer's IGP, then the backdoor link may always be the favoured customer's IGP, then the backdoor link may always be the favoured
link as it will appear an an 'internal' path, whereas the destination link as it will appear an an 'internal' path, whereas the destination
as injected via the ISP edge router will appear as an 'external' path as injected via the ISP edge router will appear as an 'external' path
(to the customer's IGP). To avoid this problem, assuming that the (to the customer's IGP). To avoid this problem, assuming that the
customer wants the traffic to traverse the ISP network, then a customer wants the traffic to traverse the ISP network, then a
skipping to change at page 30, line 5 skipping to change at page 31, line 44
edge router. This will then also make the backdoor link appear as an edge router. This will then also make the backdoor link appear as an
external path, and by adjusting the link costs appropriately, the ISP external path, and by adjusting the link costs appropriately, the ISP
path can always be favoured, unless it goes down, when the backdoor path can always be favoured, unless it goes down, when the backdoor
link is then used. link is then used.
The description of the above scenarios covers what reachability The description of the above scenarios covers what reachability
information is needed by the ISP edge routers and the CPE routers, information is needed by the ISP edge routers and the CPE routers,
and discusses some of the mechanisms used to convey this information. and discusses some of the mechanisms used to convey this information.
The sections below look at these mechanisms in more detail. The sections below look at these mechanisms in more detail.
A. Routing Protocol Instance: 5.3.3.1 Routing Protocol Instance
A routing protocol can be run between the CPE edge router and the ISP A routing protocol can be run between the CPE edge router and the ISP
edge router to exchange reachability information. This allows an ISP edge router to exchange reachability information. This allows an ISP
edge router to learn the VPRN prefixes reachable at a customer site, edge router to learn the VPRN prefixes reachable at a customer site,
and also allows a CPE router to learn the destinations reachable via and also allows a CPE router to learn the destinations reachable via
the provider network. the provider network.
The extent of the routing domain for this protocol instance is The extent of the routing domain for this protocol instance is
generally just the ISP edge router and the CPE router although if the generally just the ISP edge router and the CPE router although if the
customer site is also running the same protocol as its IGP, then the customer site is also running the same protocol as its IGP, then the
domain may extend into customer site. If the customer site is domain may extend into customer site. If the customer site is
running a different routing protocol then the CPE router running a different routing protocol then the CPE router
redistributes the routes between the instance running to the ISP edge redistributes the routes between the instance running to the ISP edge
router, and the instance running into the customer site. router, and the instance running into the customer site.
Given the typically restricted scope of this routing instance, a Given the typically restricted scope of this routing instance, a
simple protocol will generally suffice. RIPv2 [Malkin] is likely to simple protocol will generally suffice. RIP is likely to be the most
be the most common protocol used, though any routing protocol, such common protocol used, though any routing protocol, such as OSPF, or
as OSPF [Moy], or BGP-4 [Rekhter2] run in internal mode (IBGP), could BGP run in internal mode (IBGP), could also be used.
also be used.
Note that the instance of the stub link routing protocol is different Note that the instance of the stub link routing protocol is different
from any instance of a routing protocol used for intra-VPRN from any instance of a routing protocol used for intra-VPRN
reachability. For example, if the ISP edge router uses routing reachability. For example, if the ISP edge router uses routing
protocol piggybacking to disseminate VPRN membership and reachability protocol piggybacking to disseminate VPRN membership and reachability
information across the core, then it may redistribute suitably information across the core, then it may redistribute suitably
labeled routes from the CPE routing instance to the core routing labeled routes from the CPE routing instance to the core routing
instance. The routing protocols used for each instance are instance. The routing protocols used for each instance are
decoupled, and any suitable protocol can be used in each case. There decoupled, and any suitable protocol can be used in each case. There
is no requirement that the same protocol, or even the same stub link is no requirement that the same protocol, or even the same stub link
skipping to change at page 31, line 22 skipping to change at page 33, line 13
could be done either by ensuring (and appropriately configuring the could be done either by ensuring (and appropriately configuring the
ISP edge router to know) that particular disjoint address prefixes ISP edge router to know) that particular disjoint address prefixes
are mapped into separate VPRNs, or by tagging the routing are mapped into separate VPRNs, or by tagging the routing
advertisements from the CPE router with the appropriate VPN advertisements from the CPE router with the appropriate VPN
identifier. For example if MPLS was being used to convey stub link identifier. For example if MPLS was being used to convey stub link
reachability information, different MPLS labels would be used to reachability information, different MPLS labels would be used to
differentiate the disjoint prefixes assigned to particular VPRNs. In differentiate the disjoint prefixes assigned to particular VPRNs. In
any case, some administrative procedure would be required for this any case, some administrative procedure would be required for this
coordination. coordination.
B. Configuration: 5.3.3.2 Configuration
The reachability information across each stub link could be manually The reachability information across each stub link could be manually
configured, which may be appropriate if the set of addresses or configured, which may be appropriate if the set of addresses or
prefixes is small and static. prefixes is small and static.
C. ISP Administered Addresses: 5.3.3.3 ISP Administered Addresses
The set of addresses used by each stub site could be administered and The set of addresses used by each stub site could be administered and
allocated via the VPRN edge router, which may be appropriate for allocated via the VPRN edge router, which may be appropriate for
small customer sites, typically containing either a single host, or a small customer sites, typically containing either a single host, or a
single subnet. Address allocation can be carried out using protocols single subnet. Address allocation can be carried out using protocols
such as PPP or DHCP, with, for example, the edge router acting as a such as PPP or DHCP [37], with, for example, the edge router acting
Radius client and retrieving the customer's IP address to use from a as a Radius client and retrieving the customer's IP address to use
Radius server, or acting as a DHCP relay and examining the DHCP reply from a Radius server, or acting as a DHCP relay and examining the
message as it is relayed to the customer site. In this manner the DHCP reply message as it is relayed to the customer site. In this
edge router can build up a table of stub link reachability manner the edge router can build up a table of stub link reachability
information. Although these address assignment mechanisms are information. Although these address assignment mechanisms are
typically used to assign an address to a single host, some vendors typically used to assign an address to a single host, some vendors
have added extensions whereby an address prefix can be assigned, have added extensions whereby an address prefix can be assigned,
with, in some cases, the CPE device acting as a "mini-DHCP" server with, in some cases, the CPE device acting as a "mini-DHCP" server
and assigning addresses for the hosts in the customer site. and assigning addresses for the hosts in the customer site.
Note that with these schemes it is the responsibility of the address Note that with these schemes it is the responsibility of the address
allocation server to ensure that each site in the VPN received a allocation server to ensure that each site in the VPN received a
disjoint address space. Note also that an ISP would typically only disjoint address space. Note also that an ISP would typically only
use this mechanism for small stub sites, which are unlikely to have use this mechanism for small stub sites, which are unlikely to have
backdoor links. backdoor links.
D. MPLS Label Distribution Protocol: 5.3.3.4 MPLS Label Distribution Protocol
In cases where the CPE router runs MPLS, the MPLS LDP could be In cases where the CPE router runs MPLS, LDP can be used to convey
extended to convey the set of prefixes at each stub site, together the set of prefixes at a stub site to a VPRN edge router. Using the
with the appropriate labeling information. While LDP is not a downstream unsolicited mode of label distribution the CPE router can
routing protocol per se, it may be useful to extend it for this distribute a label for each route in the stub site. Note however
particular constrained scenario. that the processing carried out by the edge router in this case is
more than just the normal LDP processing, since it is learning new
routes via LDP, rather than the usual case of learning labels for
existing routes that it has learned via standard routing mechanisms.
5.2.4 Intra-VPN Reachability Information 5.3.4 Intra-VPN Reachability Information
Once an edge router has determined the set of prefixes associated Once an edge router has determined the set of prefixes associated
with each of its stub links, then this information must be with each of its stub links, then this information must be
disseminated to each other edge router in the VPRN. Note also that disseminated to each other edge router in the VPRN. Note also that
there is an implicit requirement that the set of reachable addresses there is an implicit requirement that the set of reachable addresses
within the VPRN be locally unique that is, each VPRN stub link (not within the VPRN be locally unique that is, each VPRN stub link (not
performing load sharing) maintain an address space disjoint from any performing load sharing) maintain an address space disjoint from any
other, so as to permit unambiguous routing. In practical terms, it other, so as to permit unambiguous routing. In practical terms, it
is also generally desirable, though not required, that this address is also generally desirable, though not required, that this address
space be well partitioned i.e. specific, disjoint address prefixes space be well partitioned i.e. specific, disjoint address prefixes
per edge router, so as to preclude the need to maintain and per edge router, so as to preclude the need to maintain and
disseminate large numbers of host routes. disseminate large numbers of host routes.
The intra-VPN reachability information dissemination can be solved in The problem of intra-VPN reachability information dissemination can
a number of ways, some of which include the following: be solved in a number of ways, some of which include the following:
A. Directory Lookup: 5.3.4.1 Directory Lookup
Along with VPRN membership information, a central directory could Along with VPRN membership information, a central directory could
maintain a listing of the address prefixes associated with each end maintain a listing of the address prefixes associated with each
point. Such information could be obtained by the server through customer site. Such information could be obtained by the server
protocol interactions with each edge router. Note that the same through protocol interactions with each edge router. Note that the
directory synchronization issues discussed above in section 5.2.2 same directory synchronization issues discussed above in section
also apply in this case. 5.3.2 also apply in this case.
B. Explicit Configuration: 5.3.4.2 Explicit Configuration
The address spaces associated with each edge router could be The address spaces associated with each edge router could be
explicitly configured into each other router. This is clearly a explicitly configured into each other router. This is clearly a
non-scalable solution, particularly when arbitrary topologies are non-scalable solution, particularly when arbitrary topologies are
used, and also raises the question of how the management system used, and also raises the question of how the management system
learns such information in the first place. learns such information in the first place.
C. Local Intra-VPRN Routing Instantiations: 5.3.4.3 Local Intra-VPRN Routing Instantiations
In this approach, each edge router runs an instance of a routing In this approach, each edge router runs an instance of a routing
protocol (a 'virtual router') per VPRN, running across the VPRN protocol (a 'virtual router') per VPRN, running across the VPRN
tunnels to each peer edge router, to disseminate intra-VPRN tunnels to each peer edge router, to disseminate intra-VPRN
reachability information. Both full-mesh and arbitrary VPRN reachability information. Both full-mesh and arbitrary VPRN
topologies can be easily supported, since the routing protocol itself topologies can be easily supported, since the routing protocol itself
can run over any topology. The intra-VPRN routing advertisements can run over any topology. The intra-VPRN routing advertisements
could be distinguished from normal tunnel data packets either by could be distinguished from normal tunnel data packets either by
being addressed directly to the peer edge router, or by a tunnel being addressed directly to the peer edge router, or by a tunnel
specific mechanism. specific mechanism.
Note that this intra-VPRN routing protocol need have no relationship Note that this intra-VPRN routing protocol need have no relationship
either with the IGP of any customer site or with the routing either with the IGP of any customer site or with the routing
protocols operated by the ISPs in the IP backbone. Depending on the protocols operated by the ISPs in the IP backbone. Depending on the
size and scale of the VPRNs to be supported either a simple protocol size and scale of the VPRNs to be supported either a simple protocol
like RIPv2 [Malkin] or a more sophisticated protocol like OSPF [Moy] like RIP or a more sophisticated protocol like OSPF could be used.
could be used. Because the intra-VPRN routing protocol operates as Because the intra-VPRN routing protocol operates as an overlay over
an overlay over the IP backbone it is wholly transparent to any the IP backbone it is wholly transparent to any intermediate routers,
intermediate routers, and to any edge routers not within the VPRN. and to any edge routers not within the VPRN. This also implies that
This also implies that such routing information can remain opaque to such routing information can remain opaque to such routers, which may
such routers, which may be a necessary security requirements in some be a necessary security requirements in some cases. Also note that
cases. Also note that if the routing protocol runs directly over the if the routing protocol runs directly over the same tunnels as the
same tunnels as the data traffic, then it will inherit the same level data traffic, then it will inherit the same level of security as that
of security as that afforded the data traffic, for example strong afforded the data traffic, for example strong encryption and
encryption and authentication. authentication.
If the tunnels over which an intra-VPRN routing protocol runs are If the tunnels over which an intra-VPRN routing protocol runs are
dedicated to a specific VPN (e.g. a different multiplexing field is dedicated to a specific VPN (e.g. a different multiplexing field is
used for each VPN) then no changes are needed to the routing protocol used for each VPN) then no changes are needed to the routing protocol
itself. On the other hand if shared tunnels are used, then it is itself. On the other hand if shared tunnels are used, then it is
necessary to extend the routing protocol to allow a VPN-ID field to necessary to extend the routing protocol to allow a VPN-ID field to
be included in routing update packets, to allow sets of prefixes to be included in routing update packets, to allow sets of prefixes to
be associated with a particular VPN. be associated with a particular VPN.
D. Link Reachability Protocol 5.3.4.4 Link Reachability Protocol
Given a full mesh topology, each edge router could run a link By link reachability protocol is meant a protocol that allows two
reachability protocol, for instance some variation of MPLS LDP, nodes, connected via a point-to-point link, to exchange reachability
across the tunnel to each peer edge router in the VPRN, carrying the information. Given a full mesh topology, each edge router could run
VPN-ID and the reachability information of each VPRN running across a link reachability protocol, for instance some variation of MPLS
the tunnel between the two edge routers. If VPRN membership CR-LDP, across the tunnel to each peer edge router in the VPRN,
information has already been distributed to an edge router, then the carrying the VPN-ID and the reachability information of each VPRN
neighbour discovery aspects of a traditional routing protocol are not running across the tunnel between the two edge routers. If VPRN
needed, as the set of neighbours is already known. TCP connections membership information has already been distributed to an edge
can be used to interconnect the neighbours, to provide reliability. router, then the neighbour discovery aspects of a traditional routing
This approach may reduce the processing burden of running routing protocol are not needed, as the set of neighbours is already known.
protocol instances per VPRN, and may be of particular benefit where a TCP connections can be used to interconnect the neighbours, to
shared tunnel mechanism is used to connect a set of edge routers provide reliability. This approach may reduce the processing burden
supporting multiple VPRNs. of running routing protocol instances per VPRN, and may be of
particular benefit where a shared tunnel mechanism is used to connect
a set of edge routers supporting multiple VPRNs.
Another approach to a link reachability protocol would be to base it Another approach to developing a link reachability protocol would be
on IBGP. The problem that needs to be solved by a link reachability to base it on IBGP. The problem that needs to be solved by a link
protocol is very similar to that solved by IBGP - conveying address reachability protocol is very similar to that solved by IBGP -
prefixes reliably between edge routers. conveying address prefixes reliably between edge routers.
Using a link reachability protocol it is straightforward to support a Using a link reachability protocol it is straightforward to support a
full mesh topology - each edge router conveys its own local full mesh topology - each edge router conveys its own local
reachability information to all other routers, but does not reachability information to all other routers, but does not
redistribute information received from any other router. However redistribute information received from any other router. However
once an arbitrary topology needs to be supported, the link once an arbitrary topology needs to be supported, the link
reachability protocol needs to develop into a full routing protocol, reachability protocol needs to develop into a full routing protocol,
due to the need to implement mechanisms to avoid loops, and there due to the need to implement mechanisms to avoid loops, and there
would seem little benefit in reinventing another routing protocol to would seem little benefit in reinventing another routing protocol to
deal with this. Some reasons why partially connected meshes may be deal with this. Some reasons why partially connected meshes may be
needed even in a tunneled environment are discussed in section 5.0A. needed even in a tunneled environment are discussed in section 5.1.1.
E. Piggybacking in IP Backbone Routing Protocols: 5.3.4.5 Piggybacking in IP Backbone Routing Protocols
As with VPRN membership, the set of address prefixes associated with As with VPRN membership, the set of address prefixes associated with
each stub interface could also be piggybacked into the routing each stub interface could also be piggybacked into the routing
advertisements from each edge router and propagated through the advertisements from each edge router and propagated through the
network. Other edge routers extract this information from received network. Other edge routers extract this information from received
route advertisements in the same way as they obtain the VPRN route advertisements in the same way as they obtain the VPRN
membership information (which, in this case, is implicit in the membership information (which, in this case, is implicit in the
identification of the source of each route advertisement). Note that identification of the source of each route advertisement). Note that
this scheme may require, depending upon the nature of the routing this scheme may require, depending upon the nature of the routing
protocols involved, that intermediate routers, e.g. border routers, protocols involved, that intermediate routers, e.g. border routers,
cache intra-VPRN routing information in order to propagate it cache intra-VPRN routing information in order to propagate it
further. This also has implications for the trust model, and for the further. This also has implications for the trust model, and for the
level of security possible for intra-VPRN routing information. level of security possible for intra-VPRN routing information.
Note that in any of the cases discussed above, an edge router has the Note that in any of the cases discussed above, an edge router has the
option of disseminating its stub link prefixes in a manner so as to option of disseminating its stub link prefixes in a manner so as to
permit tunneling from remote edge routers directly to the egress stub permit tunneling from remote edge routers directly to the egress stub
links. Alternatively, it could disseminate the information so as to links. Alternatively, it could disseminate the information so as to
associate all such prefixes with the edge router, rather than with associate all such prefixes with the edge router, rather than with
specific stub links. In this case, the edge router would need to specific stub links. In this case, the edge router would need to
implement a VPN specific forwarding mechanism for egress traffic, to implement a VPN specific forwarding mechanism for egress traffic, to
determine the correct egress stub link. The advantage of this is determine the correct egress stub link. The advantage of this is
that it may significantly reduce the number of distinct tunnels or that it may significantly reduce the number of distinct tunnels or
tunnel label information which need to be constructed and maintained. tunnel label information which need to be constructed and maintained.
Note that this choice is purely a local manner and is not visible to Note that this choice is purely a local manner and is not visible to
remote edge routers. remote edge routers.
5.2.5 Tunneling Mechanisms 5.3.5 Tunneling Mechanisms
Once VPRN membership information has been disseminated, the tunnels Once VPRN membership information has been disseminated, the tunnels
comprising the VPRN core can be constructed. comprising the VPRN core can be constructed.
One approach to setting up the tunnel mesh is to use point-to-point One approach to setting up the tunnel mesh is to use point-to-point
IP tunnels, and the requirements and issues for such tunnels have IP tunnels, and the requirements and issues for such tunnels have
been discussed in section 3.0. For example while tunnel been discussed in section 3.0. For example while tunnel
establishment can be done through manual configuration, this is establishment can be done through manual configuration, this is
clearly not likely to be a scalable solution, given the O(n^2) clearly not likely to be a scalable solution, given the O(n^2)
problem of meshed links. As such, tunnel set up should use some form problem of meshed links. As such, tunnel set up should use some form
of signalling protocol to allow two nodes to construct a tunnel to of signalling protocol to allow two nodes to construct a tunnel to
each other knowing only each other's identity. each other knowing only each other's identity.
Another approach is to use the multipoint to point 'tunnels' provided Another approach is to use the multipoint to point 'tunnels' provided
by MPLS. As noted in [Heinanen1], MPLS can be considered to be a by MPLS. As noted in [38], MPLS can be considered to be a form of IP
form of IP tunneling, since the labels of MPLS packets allow for tunneling, since the labels of MPLS packets allow for routing
routing decisions to be decoupled from the addressing information of decisions to be decoupled from the addressing information of the
the packets themselves. MPLS label distribution mechanisms can be packets themselves. MPLS label distribution mechanisms can be used
used to associate specific sets of MPLS labels with particular VPRN to associate specific sets of MPLS labels with particular VPRN
address prefixes supported on particular egress points (i.e. stub address prefixes supported on particular egress points (i.e. stub
links of edge routers) and hence allow other edge routers to links of edge routers) and hence allow other edge routers to
explicitly label and route traffic to particular VPRN stub links. explicitly label and route traffic to particular VPRN stub links.
One attraction of MPLS as a tunneling mechanism is that it may One attraction of MPLS as a tunneling mechanism is that it may
require less processing within each edge router than alternative require less processing within each edge router than alternative
tunneling mechanisms. This is a function of the fact that data tunneling mechanisms. This is a function of the fact that data
security within a MPLS network is implicit in the explicit label security within a MPLS network is implicit in the explicit label
binding, much as with a connection oriented network, such as Frame binding, much as with a connection oriented network, such as Frame
Relay. This may hence lessen customer concerns about data security Relay. This may hence lessen customer concerns about data security
and hence require less processor intensive security mechanisms (e.g. and hence require less processor intensive security mechanisms (e.g.
IPSec). However there are other potential security concerns with IPSec). However there are other potential security concerns with
MPLS. There is no direct support for security features such as MPLS. There is no direct support for security features such as
authentication, confidentiality, and non-repudiation and the trust authentication, confidentiality, and non-repudiation and the trust
model for MPLS means that intermediate routers, (which may belong to model for MPLS means that intermediate routers, (which may belong to
different administrative domains), through which membership and different administrative domains), through which membership and
prefix reachability information is conveyed, must be trusted, not prefix reachability information is conveyed, must be trusted, not
just the edge routers themselves. just the edge routers themselves.
5.3 Multihomed Stub Routers 5.4 Multihomed Stub Routers
The discussion thus far has implicitly assumed that stub routers are The discussion thus far has implicitly assumed that stub routers are
connected to one and only one VPRN edge router. In general, this connected to one and only one VPRN edge router. In general, this
restriction should be capable of being relaxed without any change to restriction should be capable of being relaxed without any change to
VPRN operation, given general market interest in multihoming for VPRN operation, given general market interest in multihoming for
reliability and other reasons. In particular, in cases where the reliability and other reasons. In particular, in cases where the
stub router supports multiple redundant links, with only one stub router supports multiple redundant links, with only one
operational at any given time, with the links connected either to the operational at any given time, with the links connected either to the
same VPRN edge router, or to two or more different VPRN edge routers, same VPRN edge router, or to two or more different VPRN edge routers,
then the stub link reachability mechanisms will both discover the then the stub link reachability mechanisms will both discover the
skipping to change at page 36, line 15 skipping to change at page 38, line 8
An alternative scenario is where the stub node supports multiple An alternative scenario is where the stub node supports multiple
active links, using some form of load sharing algorithm. In such a active links, using some form of load sharing algorithm. In such a
case, multiple VPRN edge routers may have active paths to the stub case, multiple VPRN edge routers may have active paths to the stub
node, and may so advertise across the VPRN. This scenario should not node, and may so advertise across the VPRN. This scenario should not
cause any problem with reachability across the VPRN providing that cause any problem with reachability across the VPRN providing that
the intra-VPRN reachability mechanism can accommodate multiple paths the intra-VPRN reachability mechanism can accommodate multiple paths
to the same prefix, and has the appropriate mechanisms to preclude to the same prefix, and has the appropriate mechanisms to preclude
looping - for instance, distance vector metrics associated with each looping - for instance, distance vector metrics associated with each
advertised prefix. advertised prefix.
5.4 Multicast Support 5.5 Multicast Support
Multicast and broadcast traffic can be supported across VPRN either Multicast and broadcast traffic can be supported across VPRNs either
by edge replication or by native multicast support in the backbone. by edge replication or by native multicast support in the backbone.
These two cases are discussed below. These two cases are discussed below.
5.4.1 Edge Replication 5.5.1 Edge Replication
This is where each VPRN edge router replicates multicast traffic for This is where each VPRN edge router replicates multicast traffic for
transmission across each link in the VPRN. Note that this is the transmission across each link in the VPRN. Note that this is the
same operation that would be performed by CPE routers terminating same operation that would be performed by CPE routers terminating
actual physical links or dedicated connections. As with CPE routers, actual physical links or dedicated connections. As with CPE routers,
multicast routing protocols could also be run on each VPRN edge multicast routing protocols could also be run on each VPRN edge
router to determine the distribution tree for multicast traffic and router to determine the distribution tree for multicast traffic and
hence reduce unnecessary flood traffic. This could be done by hence reduce unnecessary flood traffic. This could be done by
running instances of standard multicast routing protocols, e.g. running instances of standard multicast routing protocols, e.g.
Protocol Independent Multicast (PIM) [Estrin] or Distance Vector Protocol Independent Multicast (PIM) [39] or Distance Vector
Multicast Routing Protocol (DVMRP) [Waitzman], on and between each Multicast Routing Protocol (DVMRP) [40], on and between each VPRN
VPRN edge router, through the VPRN tunnels, in the same way that edge router, through the VPRN tunnels, in the same way that unicast
unicast routing protocols might be run at each VPRN edge router to routing protocols might be run at each VPRN edge router to determine
determine intra-VPN unicast reachability, as discussed in section intra-VPN unicast reachability, as discussed in section 5.3.4.
5.2.4. Alternatively, if a link reachability protocol was run across Alternatively, if a link reachability protocol was run across the
the VPRN tunnels for intra-VPRN reachability, then this could also be VPRN tunnels for intra-VPRN reachability, then this could also be
augmented to allow VPRN edge routers to indicate both the particular augmented to allow VPRN edge routers to indicate both the particular
multicast groups requested for reception at each edge node, and also multicast groups requested for reception at each edge node, and also
the multicast sources at each edge site. the multicast sources at each edge site.
In either case, there would need to be some mechanism to allow for In either case, there would need to be some mechanism to allow for
the VPRN edge routers to determine which particular multicast groups the VPRN edge routers to determine which particular multicast groups
were requested at each site and which sources were present at each were requested at each site and which sources were present at each
site. How this could be done would, in general, be a function of the site. How this could be done would, in general, be a function of the
capabilities of the CPE stub routers at each site. If these run capabilities of the CPE stub routers at each site. If these run
multicast routing protocols, then they can interact directly with the multicast routing protocols, then they can interact directly with the
equivalent protocols at each VPRN edge router. If the CPE device equivalent protocols at each VPRN edge router. If the CPE device
does not run a multicast routing protocol, then in the absence of does not run a multicast routing protocol, then in the absence of
IGMP-proxying [Fenner] the customer site would be limited to a single Internet Group Management Protocol (IGMP) proxying [41] the customer
subnet connected to the VPRN edge router via a bridging device, as site would be limited to a single subnet connected to the VPRN edge
the scope of an IGMP message is limited to a single subnet. However router via a bridging device, as the scope of an IGMP message is
using IGMP-proxying the CPE router can engage in multicast forwarding limited to a single subnet. However using IGMP-proxying the CPE
without running a multicast routing protocol, in constrained router can engage in multicast forwarding without running a multicast
topologies. On its interfaces into the customer site it performs the routing protocol, in constrained topologies. On its interfaces into
router functions of IGMP, and on its interface to the VPRN edge the customer site the CPE router performs the router functions of
router it performs the host functions of IGMP. IGMP, and on its interface to the VPRN edge router it performs the
host functions of IGMP.
5.4.2 Native Multicast Support 5.5.2 Native Multicast Support
This is where VPRN edge routers map intra-VPN multicast traffic onto This is where VPRN edge routers map intra-VPRN multicast traffic onto
a native IP multicast distribution mechanism across the backbone. a native IP multicast distribution mechanism across the backbone.
Note that the latter is not synonymous with the use of native Note that intra-VPRN multicast has the same requirements for
multicast mechanisms per se - e.g. the use of IP multicast across the
backbone - since intra-VPN multicast has the same requirements for
isolation from general backbone traffic as intra-VPRN unicast isolation from general backbone traffic as intra-VPRN unicast
traffic. Currently the only IP tunneling mechanism that has native traffic. Currently the only IP tunneling mechanism that has native
support for multicast is MPLS. On the other hand, while MPLS support for multicast is MPLS. On the other hand, while MPLS
supports native transport of IP multicast packets, additional supports native transport of IP multicast packets, additional
mechanisms would be needed to leverage these mechanisms for the mechanisms would be needed to leverage these mechanisms for the
support of intra-VPN multicast. support of intra-VPRN multicast.
For instance, each VPRN router could prefix multicast group addresses For instance, each VPRN router could prefix multicast group addresses
within each VPRN with the VPN-ID of that VPRN and then redistribute within each VPRN with the VPN-ID of that VPRN and then redistribute
these, essentially treating this VPN-ID/intra-VPRN multicast address these, essentially treating this VPN-ID/intra-VPRN multicast address
tuple as a normal multicast address, within the backbone multicast tuple as a normal multicast address, within the backbone multicast
routing protocols, as with the case of unicast reachability, as routing protocols, as with the case of unicast reachability, as
discussed previously. The MPLS multicast label distribution discussed previously. The MPLS multicast label distribution
mechanisms could then be used to set up the appropriate multicast mechanisms could then be used to set up the appropriate multicast
LSPs to interconnect those sites within each VPRN supporting LSPs to interconnect those sites within each VPRN supporting
particular multicast group addresses. Note, however, that this would particular multicast group addresses. Note, however, that this would
skipping to change at page 38, line 7 skipping to change at page 39, line 48
defined to allow for allocation of backbone multicast group addresses defined to allow for allocation of backbone multicast group addresses
for particular intra-VPRN multicast groups, and to then utilize for particular intra-VPRN multicast groups, and to then utilize
these, through backbone multicast protocols, as discussed above, to these, through backbone multicast protocols, as discussed above, to
limit forwarding of intra-VPRN multicast traffic only to those nodes limit forwarding of intra-VPRN multicast traffic only to those nodes
within the group. within the group.
A particular issue with the use of native multicast support is the A particular issue with the use of native multicast support is the
provision of security for such multicast traffic. Unlike the case of provision of security for such multicast traffic. Unlike the case of
edge replication, which inherits the security characteristics of the edge replication, which inherits the security characteristics of the
underlying tunnel, native multicast mechanisms will need to use some underlying tunnel, native multicast mechanisms will need to use some
form of secure multicast mechanism. The development of architectures form of secure multicast mechanism. The development of architectures
and solutions for secure multicast is an active research area, for and solutions for secure multicast is an active research area, for
example see [Wallner] and [Hardjono]. The Secure Multicast Group example see [42] and [43]. The Secure Multicast Group (SMuG) of the
(SMuG) of the IRTF has been set up to develop prototype solutions, IRTF has been set up to develop prototype solutions, which would then
which would then be passed to the IETF IPSec working group for be passed to the IETF IPSec working group for standardization.
standardization. However considerably more development is needed
before scalable secure native multicast mechanisms can be generally
deployed.
5.5 Recommendations However considerably more development is needed before scalable
secure native multicast mechanisms can be generally deployed.
5.6 Recommendations
The various proposals that have been developed to support some form The various proposals that have been developed to support some form
of VPRN functionality, can be broadly classified into two groups - of VPRN functionality can be broadly classified into two groups -
those that utilize the router piggybacking approach for distributing those that utilize the router piggybacking approach for distributing
VPN membership and/or reachability information ([Rosen1], [Li2]) and VPN membership and/or reachability information ([13],[15]) and those
those that use the virtual routing approach ([Muthukrishnan], that use the virtual routing approach ([12],[14]). In some cases the
[Casey1]). In some cases the mechanisms described rely on the mechanisms described rely on the characteristics of a particular
characteristics of a particular infrastructure (e.g. MPLS) rather infrastructure (e.g. MPLS) rather than just IP.
than just IP.
Within the context of the virtual routing approach it may be useful Within the context of the virtual routing approach it may be useful
to develop a membership distribution protocol based on a directory or to develop a membership distribution protocol based on a directory or
MIB. When combined with the protocol extensions for IP tunneling MIB. When combined with the protocol extensions for IP tunneling
protocols outlined in section 3.2, this would then provide the basis protocols outlined in section 3.2, this would then provide the basis
for a complete set of protocols and mechanisms that support for a complete set of protocols and mechanisms that support
interoperable VPRNs that span multiple administrations over an IP interoperable VPRNs that span multiple administrations over an IP
backbone. Note that the other major pieces of functionality needed - backbone. Note that the other major pieces of functionality needed -
the learning and distribution of customer reachability information, the learning and distribution of customer reachability information,
can be performed by instances of standard routing protocols, without can be performed by instances of standard routing protocols, without
skipping to change at page 38, line 50 skipping to change at page 40, line 41
the limitations and scalability issues associated with this topology the limitations and scalability issues associated with this topology
may not make it worthwhile to develop something specific for this may not make it worthwhile to develop something specific for this
case, as standard routing will just work. case, as standard routing will just work.
Extending routing protocols to allow a VPN-ID to carried in routing Extending routing protocols to allow a VPN-ID to carried in routing
update packets could also be examined, but is not necessary if VPN update packets could also be examined, but is not necessary if VPN
specific tunnels are used. specific tunnels are used.
6.0 VPN Types: Virtual Private Dial Networks 6.0 VPN Types: Virtual Private Dial Networks
A virtual private dial network (VPDN) allows for a remote user to A Virtual Private Dial Network (VPDN) allows for a remote user to
connect on demand through an ad hoc tunnel into another site. The connect on demand through an ad hoc tunnel into another site. The
user is connected to a public IP network via a dial-up PSTN or ISDN user is connected to a public IP network via a dial-up PSTN or ISDN
dial-up link, and user packets are tunneled across the public network link, and user packets are tunneled across the public network to the
to the desired site, giving the impression to the user of being desired site, giving the impression to the user of being 'directly'
'directly' connected into that site. A key characteristic of such ad connected into that site. A key characteristic of such ad hoc
hoc connections is the need for user authentication as a prime connections is the need for user authentication as a prime
requirement, since anyone could potentially attempt to gain access to requirement, since anyone could potentially attempt to gain access to
such a site using a switched dial network. such a site using a switched dial network.
Today many corporate networks allow access to remote users through Today many corporate networks allow access to remote users through
dial connections made through the PSTN, with users setting up PPP dial connections made through the PSTN, with users setting up PPP
connections across an access network to a Network Access Server connections across an access network to a network access server, at
(NAS), at which point the PPP sessions are authenticated using AAA which point the PPP sessions are authenticated using AAA systems
systems running such standard protocols as Radius [Rigney]. Given running such standard protocols as Radius [44]. Given the pervasive
the pervasive deployment of such systems, any VPDN system must in deployment of such systems, any VPDN system must in practice allow
practice allow for the near transparent re-use of such existing for the near transparent re-use of such existing systems.
systems.
The IETF have developed the Layer 2 Tunneling Protocol (L2TP) The IETF have developed the Layer 2 Tunneling Protocol (L2TP) [8]
[Townsley] which allows for the extension of of user PPP sessions which allows for the extension of of user PPP sessions from an L2TP
from an L2TP access concentrator (LAC)to a remote L2TP network server Access Concentrator (LAC) to a remote L2TP Network Server (LNS). The
(LNS). The L2TP protocol itself was based on two earlier protocols, L2TP protocol itself was based on two earlier protocols, the Layer 2
the Layer 2 Forwarding protocol (L2F) [Valencia], and the Point-to- Forwarding protocol (L2F) [45], and the Point-to-Point Tunneling
Point Tunneling Protocol (PPTP) [Hamzeh], and this is reflected in Protocol (PPTP) [46], and this is reflected in the two quite
the two quite different scenarios for which L2TP can be used - different scenarios for which L2TP can be used - compulsory tunneling
compulsory tunneling and voluntary tunneling, discussed further below and voluntary tunneling, discussed further below in sections 6.2 and
in sections 6.2 and 6.3. 6.3.
This document focuses on the use of L2TP over an IP network (using This document focuses on the use of L2TP over an IP network (using
UDP), but L2TP may also be run directly over other protocols such as UDP), but L2TP may also be run directly over other protocols such as
ATM or Frame Relay. Issues specifically related to running L2TP over ATM or Frame Relay. Issues specifically related to running L2TP over
non-IP networks, such as how to secure such tunnels, are not non-IP networks, such as how to secure such tunnels, are not
addressed here. addressed here.
6.1 L2TP protocol characteristics 6.1 L2TP protocol characteristics
This section looks at the characteristics of the L2TP tunneling This section looks at the characteristics of the L2TP tunneling
protocol using the categories outlined in section 3.0. protocol using the categories outlined in section 3.0.
6.1.1 Multiplexing 6.1.1 Multiplexing
L2TP has inherent support for the multiplexing of multiple calls from L2TP has inherent support for the multiplexing of multiple calls from
different users over a single link. Between the same two IP different users over a single link. Between the same two IP
endpoints, there can be multiple L2TP tunnels, as identified by a endpoints, there can be multiple L2TP tunnels, as identified by a
tunnel-id, and multiple sessions within a tunnel, as identified by a tunnel-id, and multiple sessions within a tunnel, as identified by a
session-id. session-id.
6.1.2 Signalling 6.1.2 Signalling
This is supported via the inbuilt control connection protocol, This is supported via the inbuilt control connection protocol,
allowing both tunnels and sessions to be established dynamically. allowing both tunnels and sessions to be established dynamically.
6.1.3 Data Security 6.1.3 Data Security
By allowing for the transparent extension of PPP from the user, By allowing for the transparent extension of PPP from the user,
through the LAC to the LNS, L2TP allows for the use of whatever through the LAC to the LNS, L2TP allows for the use of whatever
security mechanisms, with respect to both connection set up, and data security mechanisms, with respect to both connection set up, and data
transfer, may be used with normal PPP connections. However this does transfer, may be used with normal PPP connections. However this does
not provide security for the L2TP control protocol itself. In this not provide security for the L2TP control protocol itself. In this
case L2TP could be further secured by running it in combination with case L2TP could be further secured by running it in combination with
IPSec through IP backbones [Patel1], [Srisuresh2], or related IPSec through IP backbones [47], [48], or related mechanisms on non-
mechanisms on non-IP backbones [Calhoun2]. IP backbones [49].
The interaction of L2TP with AAA systems for user authentication and The interaction of L2TP with AAA systems for user authentication and
authorization is a function of the specific means by which L2TP is authorization is a function of the specific means by which L2TP is
used, and the nature of the devices supporting the LAC and the LNS. used, and the nature of the devices supporting the LAC and the LNS.
These issues are discussed in depth in [Aboba1]. These issues are discussed in depth in [50].
The means by which the host determines the correct LAC to connect to, The means by which the host determines the correct LAC to connect to,
and the means by which the LAC determines which users to further and the means by which the LAC determines which users to further
tunnel, and the LNS parameters associated with each user, are outside tunnel, and the LNS parameters associated with each user, are outside
the scope of the operation of VPDN, but may be addressed, for the scope of the operation of a VPDN, but may be addressed, for
instance, by evolving Internet roaming specifications [Aboba2]. instance, by evolving Internet roaming specifications [51].
6.1.4 Multiprotocol Transport 6.1.4 Multiprotocol Transport
L2TP transports PPP packets (and only PPP packets) and thus can be L2TP transports PPP packets (and only PPP packets) and thus can be
used to carry multiprotocol traffic since PPP itself is used to carry multiprotocol traffic since PPP itself is
multiprotocol. multiprotocol.
6.1.5 Sequencing 6.1.5 Sequencing
L2TP supports sequenced delivery of packets. This is a capability L2TP supports sequenced delivery of packets. This is a capability
that be negotiated at session establishment, and can be turned on and that can be negotiated at session establishment, and that can be
off by an LNS during a session. The sequence number field in L2TP turned on and off by an LNS during a session. The sequence number
can also be used to provide an indication of dropped packets, which field in L2TP can also be used to provide an indication of dropped
is needed by various PPP compression algorithms to operate correctly. packets, which is needed by various PPP compression algorithms to
If no compression is in use, and the LNS determines that the operate correctly. If no compression is in use, and the LNS
protocols in use (as evidenced by the PPP NCP negotiations) can deal determines that the protocols in use (as evidenced by the PPP NCP
with out of sequence packets (e.g. IP), then it may disable the use negotiations) can deal with out of sequence packets (e.g. IP), then
of sequencing. it may disable the use of sequencing.
6.1.6 Tunnel Maintenance 6.1.6 Tunnel Maintenance
A keepalive protocol is used by L2TP in order to allow it to A keepalive protocol is used by L2TP in order to allow it to
distinguish between a tunnel outage and prolonged periods of tunnel distinguish between a tunnel outage and prolonged periods of tunnel
inactivity. inactivity.
6.1.7 Large MTUs 6.1.7 Large MTUs
L2TP itself has no inbuilt support for a segmentation and reassembly L2TP itself has no inbuilt support for a segmentation and reassembly
capability, but when run over UDP/IP IP fragmentation will take place capability, but when run over UDP/IP IP fragmentation will take place
if necessary. Note that a LAC or LNS may adjust the MRU negotiated if necessary. Note that a LAC or LNS may adjust the Maximum Receive
via PPP in order to preclude fragmentation, if it has knowledge of Unit (MRU) negotiated via PPP in order to preclude fragmentation, if
the MTU used on the path between LAC and LNS. To this end, there is it has knowledge of the MTU used on the path between LAC and LNS. To
a proposal to allow the use of MTU discovery for cases where the L2TP this end, there is a proposal to allow the use of MTU discovery for
tunnel transports IP frames [Shea]. cases where the L2TP tunnel transports IP frames [52].
6.1.8 Tunnel Overhead 6.1.8 Tunnel Overhead
L2TP as used over IP networks runs over UDP and must be used to carry L2TP as used over IP networks runs over UDP and must be used to carry
PPP traffic. This results in a significant amount of overhead, both PPP traffic. This results in a significant amount of overhead, both
in the data plane with UDP, L2TP and PPP headers, and also in the in the data plane with UDP, L2TP and PPP headers, and also in the
control plane, with the L2TP and PPP control protocols. This is control plane, with the L2TP and PPP control protocols. This is
discussed further in section 6.2 discussed further in section 6.3
6.1.9 Flow and Congestion Control 6.1.9 Flow and Congestion Control
L2TP supports flow and congestion control mechanisms for the control L2TP supports flow and congestion control mechanisms for the control
protocol, but not for data traffic. See section 3.1.9 for more protocol, but not for data traffic. See section 3.1.9 for more
details. details.
6.1.10 QoS / Traffic Management 6.1.10 QoS / Traffic Management
An L2TP header contains a 1-bit priority field, which can be set for An L2TP header contains a 1-bit priority field, which can be set for
packets that may need preferential treatment (e.g. keepalives) during packets that may need preferential treatment (e.g. keepalives) during
local queuing and transmission. Also by transparently extending PPP, local queuing and transmission. Also by transparently extending PPP,
L2TP has inherent support for such PPP mechanisms as multi-link PPP L2TP has inherent support for such PPP mechanisms as multi-link PPP
[Sklower] and its associated control protocols [Richard], which allow [53] and its associated control protocols [54], which allow for
for bandwidth on demand to meet user requirements. bandwidth on demand to meet user requirements.
In addition L2TP calls can be mapped into whatever underlying traffic In addition L2TP calls can be mapped into whatever underlying traffic
management mechanisms may exist in the network, and there are management mechanisms may exist in the network, and there are
proposals to allow for requests through L2TP signalling for specific proposals to allow for requests through L2TP signalling for specific
differentiated services behaviors [Calhoun1]. differentiated services behaviors [55].
6.1.11 Miscellaneous 6.1.11 Miscellaneous
Since L2TP is designed to transparently extend PPP, it does not Since L2TP is designed to transparently extend PPP, it does not
attempt to supplant the normal address assignment mechanisms attempt to supplant the normal address assignment mechanisms
associated with PPP. Hence, in general terms the host initiating the associated with PPP. Hence, in general terms the host initiating the
PPP session will be assigned an address by the LNS using PPP PPP session will be assigned an address by the LNS using PPP
procedures. This addressing may have no relation to the addressing procedures. This addressing may have no relation to the addressing
used for communication between the LAC and LNS. The LNS will also used for communication between the LAC and LNS. The LNS will also
need to support whatever forwarding mechanisms are needed to route need to support whatever forwarding mechanisms are needed to route
traffic to and from the remote host. traffic to and from the remote host.
6.2 Compulsory Tunneling 6.2 Compulsory Tunneling
Compulsory tunneling refers to the scenario in which a network node - Compulsory tunneling refers to the scenario in which a network node -
a dial or network access server, for instance - acting as a LAC, a dial or network access server, for instance - acting as a LAC,
extends a PPP session across a backbone using L2TP to a remote LNS, extends a PPP session across a backbone using L2TP to a remote LNS,
as illustrated below. This operation is transparent to the user as illustrated below. This operation is transparent to the user
initiating the PPP session to the LAC. This allows for the initiating the PPP session to the LAC. This allows for the
decoupling of the location and/or ownership of the modem pools used decoupling of the location and/or ownership of the modem pools used
to terminate dial calls, from the site to which users are provided to terminate dial calls, from the site to which users are provided
access. Support for this scenario was the original intent of the L2F access. Support for this scenario was the original intent of the L2F
specification, upon which the L2TP specification was based. Note specification, upon which the L2TP specification was based.
that the diagram below shows access to a corporate network, but other
deployment scenarios are possible. For example an ISP might provide There are a number of different deployment scenarios possible. One
Internet access via an LNS. example, shown in the diagram below, is where a subscriber host dials
into a NAS acting as a LAC, and is tunneled across an IP network
(e.g. the Internet) to a gateway acting as an LNS. The gateway
provides access to a corporate network, and could either be a device
in the corporate network itself, or could be an ISP edge router, in
the case where a customer has outsourced the maintenance of LNS
functionality to an ISP. Another scenario is where an ISP uses L2TP
to provide a subscriber with access to the Internet. The subscriber
host dials into a NAS acting as a LAC, and is tunneled across an
access network to an ISP edge router acting as an LNS. This ISP edge
router then feeds the subscriber traffic into the Internet. Yet
other scenarios are where an ISP uses L2TP to provide a subscriber
with access to a VPRN, or with concurrent access to both a VPRN and
the Internet.
A VPDN, whether using compulsory or voluntary tunneling, can be
viewed as just another type of access method for subscriber traffic,
and as such can be used to provide connectivity to different types of
networks, e.g. a corporate network, the Internet, or a VPRN. The last
scenario is also an example of how a VPN service as provided to a
customer may be implemented using a combination of different types of
VPN.
10.0.0.1 10.0.0.1
+----+ +----+
|Host|----- ------------- 10.0.0.0/8 |Host|----- LAC ------------- LNS 10.0.0.0/8
+----+ / +-----+ ( ) +-----+ --------- +----+ / +-----+ ( ) +-----+ ---------
/----| LAC |---( IP Backbone )---| LNS |----( Corp. ) /----| NAS |---( IP Backbone )---| GW |----( Corp. )
dial +-----+ ( ) +-----+ ( Network ) dial +-----+ ( ) +-----+ ( Network )
connection ------------- --------- connection ------------- ---------
<------- L2TP Tunnel -------> <------- L2TP Tunnel ------->
<--------------------- PPP Session -------> <--------------------- PPP Session ------->
Figure 6.1: Compulsory Tunneling Figure 6.1: Compulsory Tunneling Example
Compulsory tunneling was originally intended for deployment on dial Compulsory tunneling was originally intended for deployment on
access servers supporting VPDN or wholesale dial services, allowing network access servers supporting wholesale dial services, allowing
for remote dial access through common facilities to an enterprise for remote dial access through common facilities to an enterprise
site, while precluding the need for the enterprise to deploy its own site, while precluding the need for the enterprise to deploy its own
dial servers. Another example of this is where an ISP outsources its dial servers. Another example of this is where an ISP outsources its
own dial connectivity to an access network provider (such as a Local own dial connectivity to an access network provider (such as a Local
Exchange Carrier (LEC) in the US) removing the need for an ISP to Exchange Carrier (LEC) in the USA) removing the need for an ISP to
maintain its own dial servers and allowing the LEC to serve multiple maintain its own dial servers and allowing the LEC to serve multiple
ISPs. More recently, compulsory tunneling mechanisms have also been ISPs. More recently, compulsory tunneling mechanisms have also been
proposed for evolving xDSL services [ADSL1], [ADSL2], which also seek proposed for evolving Digital Subscriber Line (DSL) services [56],
to leverage the existing AAA infrastructure. [57], which also seek to leverage the existing AAA infrastructure.
Call routing for compulsory tunnels requires that some aspect of the Call routing for compulsory tunnels requires that some aspect of the
initial PPP call set up can be used to allow the LAC to determine the initial PPP call set up can be used to allow the LAC to determine the
identity of the LNS. As noted in [Aboba1], these aspects can include identity of the LNS. As noted in [50], these aspects can include the
the user identity, as determined through some aspect of the access user identity, as determined through some aspect of the access
network, including calling party number, or some attribute of the network, including calling party number, or some attribute of the
called party, such as the fully qualified domain name (FQDN) of the called party, such as the Fully Qualified Domain Name (FQDN) of the
CHAP/PAP user name. identity claimed during PPP authentication.
It is also possible to chain two L2TP tunnels together, whereby a LAC It is also possible to chain two L2TP tunnels together, whereby a LAC
initiates a tunnel to an intermediate relay device, which acts as an initiates a tunnel to an intermediate relay device, which acts as an
LNS to this first LAC, and acts as a LAC to the final LNS. This may LNS to this first LAC, and acts as a LAC to the final LNS. This may
be needed in some cases due to administrative, organizational or be needed in some cases due to administrative, organizational or
regulatory issues pertaining to the split between access network regulatory issues pertaining to the split between access network
provider, IP backbone provider and enterprise customer. provider, IP backbone provider and enterprise customer.
6.3 Voluntary Tunnels 6.3 Voluntary Tunnels
Voluntary tunneling refers to the case where an individual host Voluntary tunneling refers to the case where an individual host
connects to a remote site using a tunnel originating on the host, connects to a remote site using a tunnel originating on the host,
with no involvement from intermediate network nodes, as illustrated with no involvement from intermediate network nodes, as illustrated
below. The PPTP specification, parts of which have been incorporated below. The PPTP specification, parts of which have been incorporated
into L2TP, was based upon a voluntary tunneling model. Note that the into L2TP, was based upon a voluntary tunneling model.
diagram below shows access to a corporate network, but other
deployment scenarios are possible. For example an ISP might provide As with compulsory tunneling there are different deployment scenarios
Internet access via an LNS. possible. The diagram below shows a subscriber host accessing a
corporate network with either L2TP or IPSec being used as the
voluntary tunneling mechanism. Another scenario is where voluntary
tunneling is used to provide a subscriber with access to a VPRN.
6.3.1 Issues with Use of L2TP for Voluntary Tunnels
The L2TP specification has support for voluntary tunneling, insofar
as the LAC can be located on a host, not only on a network node.
Note that such a host has two IP addresses - one for the LAC-LNS IP
tunnel, and another, typically allocated via PPP, for the network to
which the host is connecting. The benefits of using L2TP for
voluntary tunneling are that the existing authentication and address
assignment mechanisms used by PPP can be reused without modification.
For example an LNS could also include a Radius client, and
10.0.0.1 10.0.0.1
+----+ +----+
|Host|----- ------------- 10.0.0.0/8 |Host|----- ------------- 10.0.0.0/8
+----+ / +-----+ ( ) +-----+ --------- +----+ / +-----+ ( ) +-----+ ---------
/----| RAS |---( IP Backbone )---| LNS |----( Corp. ) /----| NAS |---( IP Backbone )---| GW |----( Corp. )
dial +-----+ ( ) +-----+ ( Network ) dial +-----+ ( ) +-----+ ( Network )
connection ------------- --------- connection ------------- ---------
<-------------- L2TP Tunnel --------------> <-------------- L2TP Tunnel -------------->
with LAC on host
<-------------- PPP Session --------------> LNS on gateway
<-------------- PPP Session --------------> or
Figure 6.2: Voluntary Tunneling <-------------- IPSEC Tunnel -------------->
Figure 6.2: Voluntary Tunneling Example
The L2TP specification has support for voluntary tunneling, insofar
as the LAC can be located on a host, not only on a network node.
Note that such a host has two IP addresses - one for the LAC-LNS IP
tunnel, and another, typically allocated via PPP, for the network to
which the host is connecting. The benefits of using L2TP for
voluntary tunneling are that the existing authentication and address
assignment mechanisms used by PPP can be reused without modification.
For example an LNS could also include a Radius client, and
communicate with a Radius server to authenticate a PPP PAP or CHAP communicate with a Radius server to authenticate a PPP PAP or CHAP
exchange, and to retrieve configuration information for the host such exchange, and to retrieve configuration information for the host such
as its IP address and a list of DNS servers to use. This information as its IP address and a list of DNS servers to use. This information
can then be passed to the host via the PPP IPCP protocol. can then be passed to the host via the PPP IPCP protocol.
The above procedure is not without its costs, however. There is The above procedure is not without its costs, however. There is
considerable overhead with such a protocol stack, particularly when considerable overhead with such a protocol stack, particularly when
IPSec is also needed for security purposes, and given that the host IPSec is also needed for security purposes, and given that the host
may be connected via a low-bandwidth dial up link. The overhead may be connected via a low-bandwidth dial up link. The overhead
consists of both extra headers in the data plane and extra control consists of both extra headers in the data plane and extra control
protocols needed in the control plane. Using L2TP for voluntary protocols needed in the control plane. Using L2TP for voluntary
tunneling, secured with IPSec, means a web application, for example, tunneling, secured with IPSec, means a web application, for example,
would run over the following stack would run over the following stack
HTTP/TCP/IP/PPP/L2TP/UDP/ESP/IP/PPP/AHDLC HTTP/TCP/IP/PPP/L2TP/UDP/ESP/IP/PPP/AHDLC
It is proposed in [Gupta] that IPSec alone be used for voluntary It is proposed in [58] that IPSec alone be used for voluntary tunnels
tunnels reducing overhead, using the following stack. reducing overhead, using the following stack.
HTTP/TCP/IP/ESP/IP/PPP/AHDLC HTTP/TCP/IP/ESP/IP/PPP/AHDLC
In this case IPSec is used in tunnel mode, with the tunnels In this case IPSec is used in tunnel mode, with the tunnel
terminating on IPSec edge devices at the enterprise site. There are terminating either on an IPSec edge device at the enterprise site, or
two possibilities for the IP addressing of the host. Two IP on the provider edge router connected to the enterprise site. There
are two possibilities for the IP addressing of the host. Two IP
addresses could be used, in a similar manner to the L2TP case. addresses could be used, in a similar manner to the L2TP case.
Alternatively the host can use a single public IP address as the Alternatively the host can use a single public IP address as the
source IP address in both inner and outer IP headers, with the source IP address in both inner and outer IP headers, with the
gateway performing NAT before forwarding the traffic to the gateway performing Network Address Translation (NAT) before
enterprise network. To other hosts in the enterprise network the forwarding the traffic to the enterprise network. To other hosts in
host appears to have an 'internal' IP address. Using NAT has some the enterprise network the host appears to have an 'internal' IP
limitations and restrictions, also pointed out in [Gupta]. address. Using NAT has some limitations and restrictions, also
pointed out in [58].
Another area of potential problems with PPP is due to the fact that Another area of potential problems with PPP is due to the fact that
the characteristics of a link layer implemented via an L2TP tunnel the characteristics of a link layer implemented via an L2TP tunnel
over an IP backbone are quite different to a link layer run over a over an IP backbone are quite different to a link layer run over a
serial line, as discussed in the L2TP specification itself. Poorly serial line, as discussed in the L2TP specification itself. For
chosen PPP parameters may lead to frequent resets and timeouts, example, poorly chosen PPP parameters may lead to frequent resets and
particularly if compression is in use. This is because an L2TP timeouts, particularly if compression is in use. This is because an
tunnel may misorder packets, and may silently drop packets, neither L2TP tunnel may misorder packets, and may silently drop packets,
of which normally occurs on serial lines. The general packet loss neither of which normally occurs on serial lines. The general packet
rate could also be significantly higher due to network congestion. loss rate could also be significantly higher due to network
Using the sequence number field in an L2TP header addresses the congestion. Using the sequence number field in an L2TP header
misordering issue, and for cases where the LAC and LNS are coincident addresses the misordering issue, and for cases where the LAC and LNS
with the PPP endpoints, as in voluntary tunneling, the sequence are coincident with the PPP endpoints, as in voluntary tunneling, the
number field can also be used to detect a dropped packet, and to pass sequence number field can also be used to detect a dropped packet,
a suitable indication to any compression entity in use, which and to pass a suitable indication to any compression entity in use,
typically requires such knowledge in order to keep the compression which typically requires such knowledge in order to keep the
histories in synchronization at both ends. (In fact this is more of compression histories in synchronization at both ends. (In fact this
an issue with compulsory tunneling since the LAC may have to is more of an issue with compulsory tunneling since the LAC may have
deliberately issue a corrupted frame to the PPP host, to give an to deliberately issue a corrupted frame to the PPP host, to give an
indication of packet loss, and some hardware may not allow this). indication of packet loss, and some hardware may not allow this).
If IPSec is used for voluntary tunneling the functions of user 6.3.2 Issues with Use of IPSec for Voluntary Tunnels
authentication and host configuration still need to be carried out,
however. A distinction needs to be drawn here between machine If IPSec is used for voluntary tunneling, the functions of user
authentication and user authentication. 'Two factor' authentication authentication and host configuration, achieved by means of PPP when
is carried out on the basis of both something the user has, such as a using L2TP, still need to be carried out. A distinction needs to be
machine or smartcard with a digital certificate, and something the drawn here between machine authentication and user authentication.
user knows, such as a password. (Another example is getting money 'Two factor' authentication is carried out on the basis of both
from an bank ATM machine - you need a card and a PIN number). Many something the user has, such as a machine or smartcard with a digital
of the existing legacy schemes currently in use to perform user certificate, and something the user knows, such as a password.
authentication are asymmetric in nature, and are not supported by (Another example is getting money from an bank ATM machine - you need
IKE. For remote access the most common existing user authentication a card and a PIN number). Many of the existing legacy schemes
mechanism is to use PPP between the user and access server, and currently in use to perform user authentication are asymmetric in
Radius between the access server and authentication server. The nature, and are not supported by IKE. For remote access the most
authentication exchanges that occur in this case, e.g. a PAP or CHAP common existing user authentication mechanism is to use PPP between
exchange, are asymmetric. Also CHAP supports the ability for the the user and access server, and Radius between the access server and
network to reauthenticate the user at any time after the initial authentication server. The authentication exchanges that occur in
session has been established, to ensure that the current user is the this case, e.g. a PAP or CHAP exchange, are asymmetric. Also CHAP
same person that initiated the session. supports the ability for the network to reauthenticate the user at
any time after the initial session has been established, to ensure
that the current user is the same person that initiated the session.
While IKE provides strong support for machine authentication, it has While IKE provides strong support for machine authentication, it has
only limited support for any form of user authentication and has no only limited support for any form of user authentication and has no
support for asymmetric user authentication. While a user password support for asymmetric user authentication. While a user password
can be used to derive a key used as a preshared key, this cannot be can be used to derive a key used as a preshared key, this cannot be
used with IKE Main Mode in a remote access environment, as the user used with IKE Main Mode in a remote access environment, as the user
will not have a fixed IP address, and while Agressive Mode can be will not have a fixed IP address, and while Aggressive Mode can be
used instead, this affords no identity protection. To this end there used instead, this affords no identity protection. To this end there
have been a number of proposals to allow for support of legacy have been a number of proposals to allow for support of legacy
asymmetric user level authentication schemes with IPSec. [Pereira1] asymmetric user level authentication schemes with IPSec. [59]
defines a new ISAKMP message exchange - the transaction exchange - defines a new IKE message exchange - the transaction exchange - which
which allows for both Request/Reply and Set/Acknowledge message allows for both Request/Reply and Set/Acknowledge message sequences,
sequences. This draft also defines attributes that can be used for and it also defines attributes that can be used for client IP stack
client IP stack configuration. [Pereira2] and [Litvin] describe configuration. [60] and [61] describe mechanisms that use the
mechanisms that use the transaction message exchange, or a series of transaction message exchange, or a series of such exchanges, carried
such exchanges, carried out between the IKE Phase 1 and Phase 2 out between the IKE Phase 1 and Phase 2 exchanges, to perform user
exchanges, to perform user authentication. A different approach, that authentication. A different approach, that does not extend the IKE
does not extend the IKE protocol itself, is described in [Kelly]. protocol itself, is described in [62]. With this approach a user
With this approach a user establishes a Phase 1 SA with a security establishes a Phase 1 SA with a security gateway and then sets up a
gateway and then sets up a Phase 2 SA to the gateway, over which an Phase 2 SA to the gateway, over which an existing authentication
existing authentication protocol is run. The gateway acts as a proxy protocol is run. The gateway acts as a proxy and relays the protocol
and relays the protocol messages to an authentication server. messages to an authentication server.
In addition there have also been proposals to allow the remote host In addition there have also been proposals to allow the remote host
to be configured with an IP address and other configuration to be configured with an IP address and other configuration
information over IPSec. For example [Patel2] describes a method information over IPSec. For example [63] describes a method whereby
whereby a remote host first establishes a Phase 1 SA with a security a remote host first establishes a Phase 1 SA with a security gateway
gateway and then sets up a Phase 2 SA to the gateway, over which the and then sets up a Phase 2 SA to the gateway, over which the DHCP
DHCP protocol is run. The gateway acts as a proxy and relays the protocol is run. The gateway acts as a proxy and relays the protocol
protocol messages to the DHCP server. Again, like [Kelly], this messages to the DHCP server. Again, like [62], this proposal does
proposal does not involve extensions to the IKE protocol itself. not involve extensions to the IKE protocol itself.
Another aspect of PPP functionality that may need to supported is Another aspect of PPP functionality that may need to supported is
multiprotocol operation, as there may be a need to carry network multiprotocol operation, as there may be a need to carry network
layer protocols other than IP, and even to carry link layer protocols layer protocols other than IP, and even to carry link layer protocols
(e.g. ethernet) as would be needed to support bridging over IPSec. (e.g. ethernet) as would be needed to support bridging over IPSec.
This is discussed in section 3.1.4. This is discussed in section 3.1.4.
The methods of supporting legacy user authentication and host The methods of supporting legacy user authentication and host
configuration capabilities in a remote access environment are configuration capabilities in a remote access environment are
currently being discussed in the IPSec working group. currently being discussed in the IPSec working group.
6.3 Networked Host Support 6.4 Networked Host Support
The current PPP based dial model assumes a host directly connected to The current PPP based dial model assumes a host directly connected to
a connection oriented dial access network. Recent work on new access a connection oriented dial access network. Recent work on new access
technologies such a xDSL have attempted to replicate this model technologies such as DSL have attempted to replicate this model [57],
[ADSL], so as to allow for the re-use of existing AAA systems. The so as to allow for the re-use of existing AAA systems. The
proliferation of personal computers, printers and other network proliferation of personal computers, printers and other network
appliances in homes and small businesses, and the ever lowering costs appliances in homes and small businesses, and the ever lowering costs
of networks, however, are increasingly challenging the directly of networks, however, are increasingly challenging the directly
connected host model. Increasingly, most hosts will access the connected host model. Increasingly, most hosts will access the
Internet through small, typically Ethernet, local area networks Internet through small, typically Ethernet, local area networks.
(LANs).
There is hence interest in means of accommodating the existing AAA There is hence interest in means of accommodating the existing AAA
infrastructure within service providers, whilst also supporting infrastructure within service providers, whilst also supporting
multiple networked hosts at each customer site. The principal multiple networked hosts at each customer site. The principal
complication with this scenario is the need to support the login complication with this scenario is the need to support the login
dialogue, through which the appropriate AAA information is exchanged. dialogue, through which the appropriate AAA information is exchanged.
A number of proposals have been made to address this scenario: A number of proposals have been made to address this scenario:
A. Extension of PPP to Hosts Through L2TP: 6.4.1 Extension of PPP to Hosts Through L2TP
A number of proposals (e.g. [ADSL1]) have been made to extend L2TP A number of proposals (e.g. [56]) have been made to extend L2TP over
over Ethernet so that PPP sessions can run from networked hosts out Ethernet so that PPP sessions can run from networked hosts out to the
to the network, in much the same manner as a directly attached host. network, in much the same manner as a directly attached host.
B. Extension of PPP Directly to Hosts: 6.4.2 Extension of PPP Directly to Hosts:
There is also a specification for mapping PPP directly onto Ethernet There is also a specification for mapping PPP directly onto Ethernet
(PPPOE) [Mamakos] which uses a broadcast mechanism to allow hosts to (PPPOE) [64] which uses a broadcast mechanism to allow hosts to find
find appropriate access servers with which to connect. Such servers appropriate access servers with which to connect. Such servers could
could then further tunnel, if needed, the PPP sessions using L2TP or then further tunnel, if needed, the PPP sessions using L2TP or a
a similar mechanism. similar mechanism.
C. Use of IPSec: 6.4.3 Use of IPSec
The IPSec based voluntary tunneling mechanisms discussed above can be The IPSec based voluntary tunneling mechanisms discussed above can be
used either with networked or directly connected hosts. used either with networked or directly connected hosts.
Note that all of these methods require additional host software to be Note that all of these methods require additional host software to be
used, which implements either LAC, PPPOE client or IPSec client used, which implements either LAC, PPPOE client or IPSec client
functionality. functionality.
6.4 Recommendations 6.5 Recommendations
The L2TP specification has been finalized and will be widely used for The L2TP specification has been finalized and will be widely used for
compulsory tunneling. As discussed in section 3.2, defining specific compulsory tunneling. As discussed in section 3.2, defining specific
modes of operation for IPSec when used to secure L2TP would be modes of operation for IPSec when used to secure L2TP would be
beneficial. beneficial.
Also, for voluntary tunneling, completing the work needed to provide Also, for voluntary tunneling using IPSec, completing the work needed
support for the following areas would be useful to provide support for the following areas would be useful
- asymmetric / legacy user authentication (6.3) - asymmetric / legacy user authentication (6.3)
- host address assignment and configuration (6.3) - host address assignment and configuration (6.3)
along with any other issues specifically related to the support of along with any other issues specifically related to the support of
remote hosts. Currently as there are many different non-interoperable remote hosts. Currently as there are many different non-interoperable
proprietary solutions in this area. proprietary solutions in this area.
7.0 VPN Types: Virtual Private LAN Segment 7.0 VPN Types: Virtual Private LAN Segment
A virtual private LAN segment (VPLS) is the emulation of a LAN A Virtual Private LAN Segment (VPLS) is the emulation of a LAN
segment using Internet facilities. A VPLS can be used to provide segment using Internet facilities. A VPLS can be used to provide
what is sometimes known also as a transparent LAN service (TLS), what is sometimes known also as a Transparent LAN Service (TLS),
which can be used to interconnect multiple stub CPE nodes, either which can be used to interconnect multiple stub CPE nodes, either
bridges or routers, in a protocol transparent manner. A VPLS emulates bridges or routers, in a protocol transparent manner. A VPLS
a LAN segment over IP, in the same way as protocols such as LANE emulates a LAN segment over IP, in the same way as protocols such as
[ATMF1] emulate a LAN segment over ATM. The primary benefits of a LANE emulate a LAN segment over ATM. The primary benefits of a VPLS
VPLS are complete protocol transparency, which may be important both are complete protocol transparency, which may be important both for
for multiprotocol transport and for regulatory reasons in particular multiprotocol transport and for regulatory reasons in particular
service provider contexts. service provider contexts.
10.1.1.1 +--------+ +--------+ 10.1.1.2 10.1.1.1 +--------+ +--------+ 10.1.1.2
+---+ | ISP | IP tunnel | ISP | +---+ +---+ | ISP | IP tunnel | ISP | +---+
|CPE|-------| edge |-----------------------| edge |-------|CPE| |CPE|-------| edge |-----------------------| edge |-------|CPE|
+---+ stub | node | | node | stub +---+ +---+ stub | node | | node | stub +---+
link +--------+ +--------+ link link +--------+ +--------+ link
^ | | ^ ^ | | ^
| | --------------- | | | | --------------- | |
| | ( ) | | | | ( ) | |
skipping to change at page 48, line 29 skipping to change at page 50, line 45
+-----------| edge |-----------+ +-----------| edge |-----------+
| node | | node |
+--------+ subnet = 10.1.1.0/24 +--------+ subnet = 10.1.1.0/24
| |
stub link | stub link |
| |
+---+ +---+
|CPE| 10.1.1.3 |CPE| 10.1.1.3
+---+ +---+
Figure 7.1: Example VPLS Figure 7.1: VPLS Example
7.1 VPLS Requirements 7.1 VPLS Requirements
Topologically and operationally a VPLS can be most easily modelled as Topologically and operationally a VPLS can be most easily modelled as
being essentially equivalent to a VPRN, except that each VPLS edge being essentially equivalent to a VPRN, except that each VPLS edge
node implements link layer bridging rather than network layer node implements link layer bridging rather than network layer
forwarding. As such, most of the VPRN tunneling and configuration forwarding. As such, most of the VPRN tunneling and configuration
mechanisms discussed previously can also be used for a VPLS, with the mechanisms discussed previously can also be used for a VPLS, with the
appropriate changes to accommodate link layer, rather than network appropriate changes to accommodate link layer, rather than network
layer, packets and addressing information. The following sections layer, packets and addressing information. The following sections
skipping to change at page 49, line 34 skipping to change at page 51, line 52
configuration is independent of the nature of the forwarding at each configuration is independent of the nature of the forwarding at each
VPN edge node. As such, any of the mechanisms for VPN member VPN edge node. As such, any of the mechanisms for VPN member
configuration and dissemination discussed for VPRN configuration can configuration and dissemination discussed for VPRN configuration can
also be applied to VPLS configuration. Also as with VPRNs, the also be applied to VPLS configuration. Also as with VPRNs, the
topology of the VPLS could be easily manipulated by controlling the topology of the VPLS could be easily manipulated by controlling the
configuration of peer nodes at each VPLS edge node, assuming that the configuration of peer nodes at each VPLS edge node, assuming that the
membership dissemination mechanism was such as to permit this. It is membership dissemination mechanism was such as to permit this. It is
likely that typical VPLSs will be fully meshed, however, in order to likely that typical VPLSs will be fully meshed, however, in order to
preclude the need for traffic between two VPLS nodes to transit preclude the need for traffic between two VPLS nodes to transit
through another VPLS node, which would then require the use of the through another VPLS node, which would then require the use of the
spanning tree protocol [IEEE] for loop prevention. Spanning Tree protocol [65] for loop prevention.
7.1.4 CPE Stub Node Types 7.1.4 CPE Stub Node Types
A VPLS can support either bridges or routers as a CPE device. A VPLS can support either bridges or routers as a CPE device.
CPE routers would peer transparently across a VPLS with each other CPE routers would peer transparently across a VPLS with each other
without requiring any router peering with any nodes within the VPLS. without requiring any router peering with any nodes within the VPLS.
The same scalability issues that apply to a full mesh topology for The same scalability issues that apply to a full mesh topology for
VPRNs, apply also in this case, only that now the number of peering VPRNs, apply also in this case, only that now the number of peering
routers is potentially greater, since the ISP edge device is no routers is potentially greater, since the ISP edge device is no
skipping to change at page 50, line 12 skipping to change at page 52, line 30
localized, but is visible throughout the domain. As such this localized, but is visible throughout the domain. As such this
scenario is generally only suited for support of non-routable scenario is generally only suited for support of non-routable
protocols. protocols.
The nature of the CPE impacts the nature of the encapsulation, The nature of the CPE impacts the nature of the encapsulation,
addressing, forwarding and reachability protocols within the VPLS, addressing, forwarding and reachability protocols within the VPLS,
and are discussed separately below. and are discussed separately below.
7.1.5 Stub Link Packet Encapsulation 7.1.5 Stub Link Packet Encapsulation
A. Bridge CPE: 7.1.5.1 Bridge CPE
In this case, packets sent to and from the VPLS across stub links are In this case, packets sent to and from the VPLS across stub links are
link layer frames, with a suitable access link encapsulation. The link layer frames, with a suitable access link encapsulation. The
most common case is likely to be ethernet frames, using an most common case is likely to be ethernet frames, using an
encapsulation appropriate to the particular access technology, such encapsulation appropriate to the particular access technology, such
as ATM, connecting the CPE bridges to the VPLS edge nodes. Such as ATM, connecting the CPE bridges to the VPLS edge nodes. Such
frames are then forwarded at layer 2 onto a tunnel used in the VPLS. frames are then forwarded at layer 2 onto a tunnel used in the VPLS.
As noted previously, this does mandate the use of an IP tunneling As noted previously, this does mandate the use of an IP tunneling
protocol which can transport such link layer frames. Note that this protocol which can transport such link layer frames. Note that this
does not necessarily mandate, however, the use of a protocol does not necessarily mandate, however, the use of a protocol
identification field in each tunnel packet, since the nature of the identification field in each tunnel packet, since the nature of the
encapsulated traffic (e.g. ethernet frames) could be indicated at encapsulated traffic (e.g. ethernet frames) could be indicated at
tunnel setup. tunnel setup.
B. Router CPE: 7.1.5.2 Router CPE
In this case, typically, CPE routers send link layer packets to and In this case, typically, CPE routers send link layer packets to and
from the VPLS across stub links, destined to the link layer addresses from the VPLS across stub links, destined to the link layer addresses
of their peer CPE routers. Other types of encapsulations may also of their peer CPE routers. Other types of encapsulations may also
prove feasible in such a case, however, since the relatively prove feasible in such a case, however, since the relatively
constrained addressing space needed for a VPLS to which only router constrained addressing space needed for a VPLS to which only router
CPE are connected, could allow for alternative encapsulations, as CPE are connected, could allow for alternative encapsulations, as
discussed further below. discussed further below.
7.1.6 CPE Addressing and Address Resolution 7.1.6 CPE Addressing and Address Resolution
A. Bridge CPE: 7.1.6.1 Bridge CPE
Since a VPLS operates at the link layer, all hosts within all stub Since a VPLS operates at the link layer, all hosts within all stub
sites, in the case of bridge CPE, will typically be in the same sites, in the case of bridge CPE, will typically be in the same
network layer subnet. (Multinetting, whereby multiple subnets network layer subnet. (Multinetting, whereby multiple subnets
operate over the same LAN segment, is possible, but much less operate over the same LAN segment, is possible, but much less
common). Frames are forwarded across and within the VPLS based upon common). Frames are forwarded across and within the VPLS based upon
the link layer addresses - e.g. IEEE MAC addresses - associated with the link layer addresses - e.g. IEEE MAC addresses - associated with
the individual hosts. The VPLS needs to support broadcast traffic, the individual hosts. The VPLS needs to support broadcast traffic,
such as that typically used for the address resolution mechanism used such as that typically used for the address resolution mechanism used
to map the host network addresses to their respective link addresses. to map the host network addresses to their respective link addresses.
The VPLS forwarding and reachability algorithms also need to be able The VPLS forwarding and reachability algorithms also need to be able
to accommodate flooded traffic. to accommodate flooded traffic.
B. Router CPE: 7.1.6.2 Router CPE
A single network layer subnet is generally used to interconnect A single network layer subnet is generally used to interconnect
router CPE devices, across a VPLS. Behind each CPE router are hosts router CPE devices, across a VPLS. Behind each CPE router are hosts
in different network layer subnets. CPE routers transfer packets in different network layer subnets. CPE routers transfer packets
across the VPLS by mapping next hop network layer addresses to the across the VPLS by mapping next hop network layer addresses to the
link layer addresses of a router peer. A link layer encapsulation is link layer addresses of a router peer. A link layer encapsulation is
used, most commonly ethernet, as for the bridge case. used, most commonly ethernet, as for the bridge case.
As noted above, however, in cases where all of the CPE nodes As noted above, however, in cases where all of the CPE nodes
connected to the VPLS are routers, then it may be possible, due to connected to the VPLS are routers, then it may be possible, due to
the constrained addressing space of the VPLS, to use encapsulations the constrained addressing space of the VPLS, to use encapsulations
that use a different address space than normal MAC addressing. See, that use a different address space than normal MAC addressing. See,
for instance, [Jamieson], for a proposed mechanism for VPLSs over for instance, [11], for a proposed mechanism for VPLSs over MPLS
MPLS networks, leveraging earlier work on VPRN support over MPLS networks, leveraging earlier work on VPRN support over MPLS [38],
[Heinanen1], which proposes MPLS as the tunneling mechanism, and which proposes MPLS as the tunneling mechanism, and locally assigned
locally assigned MPLS labels as the link layer addressing scheme to MPLS labels as the link layer addressing scheme to identify the CPE
identify the CPE LSR routers connected to the VPLS. LSR routers connected to the VPLS.
7.1.7 VPLS Edge Node Forwarding and Reachability Mechanisms 7.1.7 VPLS Edge Node Forwarding and Reachability Mechanisms
A. Bridge CPE: 7.1.7.1 Bridge CPE
The only practical VPLS edge node forwarding mechanism in this case The only practical VPLS edge node forwarding mechanism in this case
is likely to be standard link layer packet flooding and MAC address is likely to be standard link layer packet flooding and MAC address
learning, as per [IEEE]. As such, no explicit intra-VPLS reachability learning, as per [65]. As such, no explicit intra-VPLS reachability
protocol will be needed, though there will be a need for broadcast protocol will be needed, though there will be a need for broadcast
mechanisms to flood traffic, as discussed above. In general, it may mechanisms to flood traffic, as discussed above. In general, it may
not prove necessary to also implement the spanning tree protocol not prove necessary to also implement the Spanning Tree protocol
[IEEE] between VPLS edge nodes, if the VPLS topology is such that no between VPLS edge nodes, if the VPLS topology is such that no VPLS
VPLS edge node is used for transit traffic between any other VPLS edge node is used for transit traffic between any other VPLS edge
edge nodes - in other words, where there is both full mesh nodes - in other words, where there is both full mesh connectivity
connectivity and transit is explicitly precluded. On the other hand, and transit is explicitly precluded. On the other hand, the CPE
the CPE bridges may well implement the spanning tree protocol in bridges may well implement the spanning tree protocol in order to
order to safeguard against 'backdoor' paths that bypass connectivity safeguard against 'backdoor' paths that bypass connectivity through
through the VPLS. the VPLS.
B. Router CPE: 7.1.7.2 Router CPE
Standard bridging techniques can also be used in this case. In Standard bridging techniques can also be used in this case. In
addition, the smaller link layer address space of such a VPLS may addition, the smaller link layer address space of such a VPLS may
also permit other techniques, with explicit link layer routes between also permit other techniques, with explicit link layer routes between
CPE routers. [Jamieson], for instance, proposes that MPLS LSPs be set CPE routers. [11], for instance, proposes that MPLS LSPs be set up,
up, at the insertion of any new CPE router into the VPLS, between all at the insertion of any new CPE router into the VPLS, between all CPE
CPE LSRs. This then precludes the need for packet flooding. In the LSRs. This then precludes the need for packet flooding. In the more
more general case, if stub link reachability mechanisms were used to general case, if stub link reachability mechanisms were used to
configure VPLS edge nodes with the link layer addresses of the CPE configure VPLS edge nodes with the link layer addresses of the CPE
routers connected to them, then modifications of any of the intra-VPN routers connected to them, then modifications of any of the intra-VPN
reachability mechanisms discussed for VPRNs could be used to reachability mechanisms discussed for VPRNs could be used to
propagate this information to each other VPLS edge node. This would propagate this information to each other VPLS edge node. This would
then allow for packet forwarding across the VPLS without flooding. then allow for packet forwarding across the VPLS without flooding.
Mechanisms could also be developed to further propagate the link Mechanisms could also be developed to further propagate the link
layer addresses of peer CPE routers and their corresponding network layer addresses of peer CPE routers and their corresponding network
layer addresses across the stub links to the CPE routers, where such layer addresses across the stub links to the CPE routers, where such
information could be inserted into the CPE router's address information could be inserted into the CPE router's address
resolution tables. This would then also preclude the need for resolution tables. This would then also preclude the need for
broadcast address resolution protocols across the VPLS. broadcast address resolution protocols across the VPLS.
Clearly there would be no need for the support of spanning tree Clearly there would be no need for the support of spanning tree
protocols if explicit link layer routes were determined across the protocols if explicit link layer routes were determined across the
VPLS. If normal flooding mechanisms were used then spanning tree VPLS. If normal flooding mechanisms were used then spanning tree
would only be required again only if full mesh connectivity was not would only be required if full mesh connectivity was not available
available and hence VPLS nodes had to carry transit traffic. and hence VPLS nodes had to carry transit traffic.
7.2 Recommendations 7.2 Recommendations
There is significant commonality between VPRNs and VPLSs, and, where There is significant commonality between VPRNs and VPLSs, and, where
possible, this similarity should be exploited in order to reduce possible, this similarity should be exploited in order to reduce
development and configuration complexity. In particular, VPLSs development and configuration complexity. In particular, VPLSs
should utilize the same tunneling and membership configuration should utilize the same tunneling and membership configuration
mechanisms, with changes only to reflect the specific characteristics mechanisms, with changes only to reflect the specific characteristics
of VPLSs. of VPLSs.
skipping to change at page 53, line 4 skipping to change at page 55, line 22
For IKE/IPSec: For IKE/IPSec:
- the transport of a VPN-ID when establishing an SA (3.1.2) - the transport of a VPN-ID when establishing an SA (3.1.2)
- a null encryption and null authentication option (3.1.3) - a null encryption and null authentication option (3.1.3)
- multiprotocol operation (3.1.4) - multiprotocol operation (3.1.4)
- frame sequencing (3.1.5) - frame sequencing (3.1.5)
- asymmetric / legacy user authentication (8.2)
- host address assignment and configuration (8.2) - asymmetric / legacy user authentication (6.3)
- host address assignment and configuration (6.3)
For L2TP: For L2TP:
- defining modes of operation of IPSec when used to support L2TP - defining modes of operation of IPSec when used to support L2TP
(5.2) (3.2)
For VPNs generally: For VPNs generally:
- defining a VPN membership information configuration and - defining a VPN membership information configuration and
dissemination mechanism, that uses some form of directory or MIB dissemination mechanism, that uses some form of directory or MIB
(section 5.1.2 A,B) (5.3.2)
- ensure that solutions developed, as far as possible, are
applicable to different types of VPNs, rather than being specific
to a single type of VPN.
9.0 Security considerations 9.0 Security considerations
Security considerations are an integral part of any VPN mechanisms, Security considerations are an integral part of any VPN mechanisms,
and these are discussed in the sections describing those mechanisms. and these are discussed in the sections describing those mechanisms.
10.0 Acknowledgements 10.0 Acknowledgements
Thanks to Anthony Alles, of Nortel Networks, for his invaluable Thanks to Anthony Alles, of Nortel Networks, for his invaluable
assistance with the generation of this document, and who developed assistance with the generation of this document, and who developed
much of the material on which early versions of this document were much of the material on which early versions of this document were
based. Thanks also to Joel Halpern for his helpful review comments. based. Thanks also to Joel Halpern for his helpful review comments.
11.0 References 11.0 References
[Aboba1] Aboba, B. and Zorn, G. - "Implementation of PPTP/L2TP [1] ATM Forum. "LAN Emulation over ATM 1.0", af-lane-0021.000,
Compulsory Tunneling via RADIUS", draft-ietf-radius-tunnel-imp- January 1995.
05.txt.
[Aboba2] Aboba, B. and Zorn, G. - "Criteria for Evaluating Roaming
Protocols", RFC 2477.
[ADSL1] ADSL Forum - "An Interoperable End-to-end Broadband Service
Architecture over ADSL Systems (Version 3.0)", ADSL Forum 97-215.
[ADSL2] ADSL Forum - "Core Network Architectures for ADSL Access
Systems (Version 1.01)", ADSL Forum 998-017.
[ATMF1] ATM Forum - "LAN Emulation over ATM 1.0", af-lane-0021.000,
January 1995.
[ATMF2] ATM Forum - "Multi-Protocol Over ATM Specification v1.0",
af-mpoa-0087.000, June 1997.
[Bates] Bates, T. "Multiprotocol Extensions for BGP-4", RFC 2283.
[Bernet] Bernet, Y., et al - "A Framework for Differentiated
Services", draft-ietf-diffserv-framework-02.txt.
[Boyle] Boyle, J. - " The COPS (Common Open Policy Service)
Protocol", draft-ietf-rap-cops-07.txt.
[Brown] Brown, C. and Malis, A. - "Multiprotocol Interconnect over
Frame Relay", RFC 2427.
[Calhoun1] Calhoun, P. and Peirce, K. - "Layer Two Tunneling Protocol [2] ATM Forum. "Multi-Protocol Over ATM Specification v1.0", af-
"L2TP" IP Differential Services Extension", draft-ietf-pppext- mpoa-0087.000, June 1997.
l2tp-ds-03.txt.
[Calhoun2] Calhoun, P., et al - "Layer Two Tunneling Protocol "L2TP" [3] Ferguson, P. and Huston, G. "What is a VPN?", Revision 1, April
Security Extensions for Non-IP networks", draft-ietf-pppext-l2tp- 1 1998; http://www.employees.org/~ferguson/vpn.pdf.
sec-04.txt.
[Calhoun3] Calhoun, P. et al - "Tunnel Establishment Protocol", [4] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and
draft-ietf-mobileip-calhoun-tep-02.txt. E. Lear, "Address Allocation for Private Internets", BCP 5, RFC
1918, February 1996.
[Casey1] Casey, L. et al - "IP VPN Realization using MPLS Tunnels", [5] Kent, S. and R. Atkinson, "Security Architecture for the
draft-casey-vpn-mpls-00.txt. Internet Protocol", RFC 2401, November 1998.
[Casey2] Casey, L. "An extended IP VPN Architecture", draft-casey- [6] Perkins, C., "IP Encapsulation within IP", RFC 2003, October
vpn-extns-00.txt. 1996.
[Chandra] Chandra, R. and Traina, P. "BGP Communities Attribute", [7] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic
RFC 1998. Routing Encapsulation (GRE)", RFC 1702, October 1994.
[Coltun] Coltun, R. "The OSPF Opaque LSA Option", RFC 2370. [8] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and
B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661,
August 1999.
[Davie] Davie, B., et al - "Use of Label Switching with RSVP", [9] Rosen, E., et al "Multiprotocol Label Switching Architecture",
draft-ietf-mpls-rsvp-02.txt Work in Progress.
[Duffield] Duffield N, et al - "A Performance Oriented Service [10] Heinanen, J., et al. "MPLS Mappings of Generic VPN Mechanisms",
Interface for Virtual Private Networks", draft-duffield-vpn-qos- Work in Progress.
framework-00.txt.
[Estrin] Estrin, D., et al - "Protocol Independent Multicast-Sparse [11] Jamieson, D., et al. "MPLS VPN Architecture", Work in Progress.
Mode (PIM-SM) Protocol Specification", RFC 2362.
[Fenner] Fenner, W. - "IGMP-based Multicast Forwarding (IGMP [12] Casey, L. et al. "IP VPN Realization using MPLS Tunnels", Work
Proxying)", draft-fenner-igmp-proxy-01.txt in Progress.
[Ferguson] Ferguson, P. and Huston, G. - "What is a VPN?", Revision, [13] Li, T. "CPE based VPNs using MPLS", Work in Progress.
April 1 1998; http://www.employees.org:80/~ferguson/vpn.pdf.
[Fox] Fox, B. and Gleeson, B. "Virtual Private Networks Identifier", [14] Muthukrishnan, K. and Malis A. "Core IP VPN Architecture", Work
RFC 2685. in Progress.
[Grossman] Grossman, D. and Heinanen, J. - "Multiprotocol [15] Rosen, E. and Rekhter, Y. "BGP/MPLS VPNs", RFC 2547, March
Encapsulation over ATM Adaptation Layer 5", RFC 2684. 1999.
[Gupta] Gupta, V. - "Secure, Remote Access over the Internet using [16] Fox, B. and Gleeson, B. "Virtual Private Networks Identifier",
IPSec", draft-gupta-ipsec-remote-access-02.txt. RFC 2685, September 1999.
[Hamzeh] Hamzeh, K., et al - "Point-to-Point Tunneling Protocol [17] Petri, B. (editor) "MPOA v1.1 Addendum on VPN support", ATM
(PPTP)", RFC 2637 Forum, af-mpoa-0129.000.
[Hanks] Hanks, S., et al "Generic Routing Encapsulation over Ipv4 [18] Harkins, D. and C. Carrel, "The Internet Key Exchange (IKE)",
Networks", RFC 1702. RFC 2409, November 1998.
[Hardjono] Hardjono, T. et al. - "Secure IP Multicast: Problem areas, [19] Calhoun, P. et al. "Tunnel Establishment Protocol", Work in
Framework, and Building Blocks" draft-irtf-smug-framework-00.txt Progress.
[Harkins] Harkins, D. and Carrel, D. "The Internet Key Exchange [20] Andersson, L., et al. "LDP Specification", Work in Progress.
(IKE)", RFC 2409.
[Heinanen1] Heinanen, J. and Rosen, E. "VPN Support with MPLS" [21] Jamoussi, B. et al. "Constraint-Based LSP Setup using LDP" Work
draft-heinanen-mpls-vpn-01.txt. in Progress.
[Heinanen2] Heinanen, J., et al - "MPLS Mappings of Generic VPN [22] Awduche, D. et al. "Extensions to RSVP for LSP Tunnels", Work
Mechanisms", draft-heinanen-generic-vpn-mpls-00.txt. in Progress.
[Heinanen3] Heinanen, J. - "Multiprotocol Encapsulation over ATM [23] Kent, S. and R. Atkinson, "IP Encapsulating Security Protocol
Adaptation Layer 5", RFC1483. (ESP)", RFC 2406, November 1998.
[IEEE] ANSI/IEEE - 10038: 1993 (ISO/IEC) Information technology -- [24] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
Telecommunications and information exchange between systems -- 51, RFC 1661, July 1994.
Local area networks -- Media access control (MAC) bridges,
ANSI/IEEE Std 802.1D, 1993 Edition.
[Jacobson] Jacobson, V. et al - "An Expedited Forwarding PHB", RFC [25] Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D. and
2598. A. Malis, "ATM Signalling Support for IP over ATM", RFC 1755,
February 1995.
[Jamieson] Jamieson, D., et al - "MPLS VPN Architecture", draft- [26] Malkin, G. "RIP Version 2 Carrying Additional Information",
jamieson-mpls-vpn-00.txt. RFC 1723, November 1994.
[Jamieson2] Jamieson, D and Wang, R. - "Solicitation Extensions for [27] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
BGP-4" draft-jamieson-bgp-solicit-00.txt.
[Kelly] Kelly, S. et al. - "User-level Authentication Mechanisms for [28] Shacham, A., Monsour, R., Pereira, R. and Thomas, M. "IP
IPsec", draft-kelly-ipsra-userauth-00.txt. Payload Compression Protocol (IPComp)" RFC 2393, December 1998.
[Kent] Kent, S. and Atkinson, R. "Security Architecture for the [29] Duffield N, et al. "A Performance Oriented Service Interface
Internet Protocol", RFC 2401. for Virtual Private Networks", Work in Progress.
[Kent2] Kent, S. and Atkinson, R. "IP Encapsulating Security [30] Jacobson, V., Nichols, K. and Poduri, K. "An Expedited
Payload (ESP)", RFC 2406. Forwarding PHB", RFC2598, June 1999
[Li] Li, T. and Rekhter, Y. - "Provider Architecture for [31] Casey, L. "An extended IP VPN Architecture", Work in Progress.
Differentiated Services and Traffic Engineering (PASTE)", RFC
2430.
[Li2] Li, T. - "CPE based VPNs using MPLS", draft-li-mpls-vpn-00.txt. [32] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4),"
RFC 1771, March 1995.
[Litvin] Litvin, M. et al - "A Hybrid Authentication Mode for IKE", [33] Grossman, D. and Heinanen, J. "Multiprotocol Encapsulation over
draft-ietf-ipsec-isakmp-hybrid-auth-02.txt. ATM Adaptation Layer 5", RFC 2684, September 1999.
[MacRae] MacRae, M. and Ayandeh, S. - "Using COPS for VPN [34] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
Connectivity" draft-macrae-policy-cops-vpn-00.txt Protocol (v3)", RFC 2251, December 1997.
[Malkin] Malkin, G. "RIP Version 2 Carrying Additional [35] Boyle, J. et al. "The COPS (Common Open Policy Service)
Information", RFC 1723. Protocol", Work in Progress.
[Mamakos] Mamakos, L. et al. - "A Method for Transmitting PPP Over [36] MacRae, M. and Ayandeh, S. "Using COPS for VPN Connectivity"
Ethernet (PPPoE)" RFC 2516. Work in Progress.
[Moy] Moy, J. "OSPF Version 2", RFC 2328. [37] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[Muthukrishnan] Muthukrishnan, K. and Malis A. - "Core IP VPN [38] Heinanen, J. and Rosen, E. "VPN Support with MPLS" Work in
Architecture", draft-muthukrishnan-corevpn-arch-00.txt. Progress.
[Patel1] Patel, B. et al. - "Securing L2TP using IPSEC", draft-ietf- [39] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S.,
pppext-l2tp-security-04.txt. Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei,
"Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
Specification", RFC 2362, June 1998.
[Patel2] Patel, B. - "Dynamic configuration of IPSEC VPN host using [40] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector
DHCP", draft-ietf-ipsec-dhcp-02.txt Multicast Routing Protocol", RFC 1075, November 1988.
[Pegrum] Pegrum, S. - "VPN Point to Multipoint Tunnel Protocol [41] Fenner, W. "IGMP-based Multicast Forwarding (IGMP Proxying)",
(VPMT)", draft-pegrum-vmmt-01.txt. Work in Progress.
[Pereira1] Pereira, R. et al - "The ISAKMP Configuration Method", [42] Wallner, D., Harder, E. and Agee R. "Key Management for
draft-ietf-ipsec-isakmp-mode-cfg-05.txt. Multicast: Issues and Architectures" RFC 2627, June 1999
[Pereira2] Pereira, R. and Beaulieu, S. - "Extended Authentication [43] Hardjono, T. et al. "Secure IP Multicast: Problem areas,
Within ISAKMP/Oakley", draft-ietf-ipsec-isakmp-xauth-05.txt. Framework, and Building Blocks" Work in Progress.
[Perez] Perez, M., Liaw, F. et al. "ATM Signaling Support for IP over [44] Rigney, C., Rubens, A., Simpson, W., and Willens, S., "Remote
ATM" RFC 1755. Authentication Dial In User Service (RADIUS)", RFC 2138, April
1997.
[Perkins] Perkins, C. - "IP Encapsulation within IP" RFC 2003. [45] Valencia, A., Littlewood, M. and T. Kolar. "Cisco Layer Two
Forwarding (Protocol) "L2F"", RFC 2341, May 1998.
[Petri] Petri, B. (editor) - "MPOA v1.1 Addendum on VPN support", ATM [46] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and
Forum, af-mpoa-0129.000. Zorn G., "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637,
July 1999.
[Rekhter1] Rekhter, Y., et al "Address Allocation for Private [47] Patel, B. et al. "Securing L2TP using IPSEC", Work in Progress.
Internets", RFC 1918.
[Rekhter2] Rekhter, Y. and Li, T. "A Border Gateway Protocol 4 [48] Srisuresh, P. "Secure Remote Access with L2TP", Work in
(BGP-4)", RFC 1771. Progress.
[Rekhter3] Rekhter, Y. and Rosen, E. "Carrying Label Information in [49] Calhoun, P., et al. "Layer Two Tunneling Protocol "L2TP"
BGP-4", draft-ietf-mpls-bgp4-mpls-03.txt. Security Extensions for Non-IP networks", Work in Progress.
[Rigney] Rigney, C., et al - "Remote Authentication Dial In User [50] Aboba, B. and Zorn, G. "Implementation of PPTP/L2TP Compulsory
Service (RADIUS)", RFC 2138. Tunneling via RADIUS", Work in progress.
[Richard] Richard, C. and Smith, K. - "The PPP Bandwidth Allocation [51] Aboba, B. and Zorn, G. "Criteria for Evaluating Roaming
Protocol (BAP), The PPP Bandwidth Allocation Control Protocol Protocols", RFC 2477, January 1999.
(BACP)" RFC 2125.
[Rosen1] Rosen, E. and Rekhter, Y. - "BGP/MPLS VPNs", RFC 2457. [52] Shea, R. "L2TP-over-IP Path MTU Discovery (L2TPMTU)", Work in
Progress.
[Rosen2] Rosen, E., et al "Multiprotocol Label Switching [53] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T.
Architecture", draft-ietf-mpls-arch-06.txt. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August
1996.
[Shacham] Shacham, A., et al - "IP Payload Compression Protocol [54] Richards, C. and K. Smith, "The PPP Bandwidth Allocation
(IPComp)", RFC 2393. Protocol (BAP) The PPP Bandwidth Allocation Control Protocol
(BACP)", RFC 2125, March 1997.
[Shea] Shea, R. - "L2TP-over-IP Path MTU Discovery (''L2TPMTU'')", [55] Calhoun, P. and Peirce, K. "Layer Two Tunneling Protocol "L2TP"
draft- ietf-pppext-l2tpmtu-00.txt. IP Differential Services Extension", Work in Progress.
[Shieh1] Shieh, P et al. "The Architecture for Extending PPP [56] ADSL Forum. "An Interoperable End-to-end Broadband Service
Connections for Home Network Clients", ADSL Forum contribution Architecture over ADSL Systems (Version 3.0)", ADSL Forum 97-
98-140. 215.
[Shieh2] Shieh, P et al. "The Requirement and Comparisons of [57] ADSL Forum. "Core Network Architectures for ADSL Access Systems
Extending PPP over Ethernet", ADSL Forum contribution 98-141. (Version 1.01)", ADSL Forum 98-017.
[Sklower] Sklower, K., et al - "The PPP Multilink Protocol (MP)", RFC [58] Gupta, V. "Secure, Remote Access over the Internet using
1990. IPSec", Work in Progress.
[Srisuresh1] Srisuresh, P. and Holdrege, M. - "IP Network Address [59] Pereira, R. et al. "The ISAKMP Configuration Method", Work in
Translator (NAT) Terminology and Considerations", draft-ietf-nat- Progress.
terminology-03.txt.
[Srisuresh2] Srisuresh, P. - "Secure Remote Access with L2TP", [60] Pereira, R. and Beaulieu, S. "Extended Authentication Within
<draft-ietf-pppext-secure-ra-00.txt> ISAKMP/Oakley", Work in Progress.
[Thomas] Thomas, B., et al - "LDP Specification", draft-ietf-mpls- [61] Litvin, M. et al. "A Hybrid Authentication Mode for IKE", Work
ldp-06.txt. in Progress.
[Townsley] Townsley, M., et al - "Layer Two Tunneling Protocol [62] Kelly, S. et al. "User-level Authentication Mechanisms for
'L2TP'", RFC 2661. IPsec", Work in Progress.
[Valencia] Valencia, A., et al "Cisco Layer Two Forwarding [63] Patel, B. et al. "DHCP Configuration of IPSEC Tunnel Mode",
(Protocol) "L2F"", RFC 2341. Work in Progress.
[Waitzman] Waitzman, D., et al - "Distance Vector Multicast Routing [64] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. and
Protocol", RFC 1075. Wheeler, R., "A Method for Transmitting PPP Over Ethernet
(PPPoE)", RFC 2516, February 1999
[Wallner] Wallner, D., et al - "Key Management for Multicast: Issues [65] ANSI/IEEE - 10038: 1993 (ISO/IEC) Information technology -
and Architectures" RFC2627. Telecommunications and information exchange between systems -
Local area networks - Media access control (MAC) bridges,
ANSI/IEEE Std 802.1D, 1993 Edition.
12.0 Author Information 12.0 Author Information
Bryan Gleeson Bryan Gleeson
Nortel Networks Nortel Networks
4500 Great America Parkway 4500 Great America Parkway
Santa Clara CA 95054 Santa Clara CA 95054
USA USA
Tel: +1 (408) 548 3711 Tel: +1 (408) 548 3711
Email: bgleeson@shastanets.com Email: bgleeson@shastanets.com
 End of changes. 293 change blocks. 
906 lines changed or deleted 1002 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/