tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 2764

 Errata 
Informational
Pages: 62
Top     in Index     Prev     Next
in Group Index     No Prev: Lowest Number in Group     Next in Group     Group: ~vpn

A Framework for IP Based Virtual Private Networks

Part 1 of 3, p. 1 to 18
None       Next RFC Part

 


Top       ToC       Page 1 
Network Working Group                                         B. Gleeson
Request for Comments: 2764                                        A. Lin
Category: Informational                                  Nortel Networks
                                                             J. Heinanen
                                                           Telia Finland
                                                             G. Armitage
                                                                A. Malis
                                                     Lucent Technologies
                                                           February 2000


           A Framework for IP Based Virtual Private Networks


Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

IESG Note

   This document is not the product of an IETF Working Group.  The IETF
   currently has no effort underway to standardize a specific VPN
   framework.

Abstract

   This document describes a framework for Virtual Private Networks
   (VPNs) running across IP backbones.  It discusses the various
   different types of VPNs, their respective requirements, and proposes
   specific mechanisms that could be used to implement each type of VPN
   using existing or proposed specifications.  The objective of this
   document is to serve as a framework for related protocol development
   in order to develop the full set of specifications required for
   widespread deployment of interoperable VPN solutions.

Top       Page 2 
Table of Contents

   1.0 Introduction ................................................  4
   2.0 VPN Application and Implementation Requirements .............  5
   2.1 General VPN Requirements ....................................  5
   2.1.1 Opaque Packet Transport:  .................................  6
   2.1.2 Data Security .............................................  7
   2.1.3 Quality of Service Guarantees .............................  7
   2.1.4 Tunneling Mechanism .......................................  8
   2.2 CPE and Network Based VPNs ..................................  8
   2.3 VPNs and Extranets ..........................................  9
   3.0 VPN Tunneling ............................................... 10
   3.1 Tunneling Protocol Requirements for VPNs .................... 11
   3.1.1 Multiplexing .............................................. 11
   3.1.2 Signalling Protocol ....................................... 12
   3.1.3 Data Security ............................................. 13
   3.1.4 Multiprotocol Transport ................................... 14
   3.1.5 Frame Sequencing .......................................... 14
   3.1.6 Tunnel Maintenance ........................................ 15
   3.1.7 Large MTUs ................................................ 16
   3.1.8 Minimization of Tunnel Overhead ........................... 16
   3.1.9 Flow and congestion control ............................... 17
   3.1.10 QoS / Traffic Management ................................. 17
   3.2 Recommendations ............................................. 18
   4.0 VPN Types:  Virtual Leased Lines ............................ 18
   5.0 VPN Types:  Virtual Private Routed Networks ................. 20
   5.1 VPRN Characteristics ........................................ 20
   5.1.1 Topology .................................................. 23
   5.1.2 Addressing ................................................ 24
   5.1.3 Forwarding ................................................ 24
   5.1.4 Multiple concurrent VPRN connectivity ..................... 24
   5.2 VPRN Related Work ........................................... 24
   5.3 VPRN Generic Requirements ................................... 25
   5.3.1 VPN Identifier ............................................ 26
   5.3.2 VPN Membership Information Configuration .................. 27
   5.3.2.1 Directory Lookup ........................................ 27
   5.3.2.2 Explicit Management Configuration ....................... 28
   5.3.2.3 Piggybacking in Routing Protocols ....................... 28
   5.3.3 Stub Link Reachability Information ........................ 30
   5.3.3.1 Stub Link Connectivity Scenarios ........................ 30
   5.3.3.1.1 Dual VPRN and Internet Connectivity ................... 30
   5.3.3.1.2 VPRN Connectivity Only ................................ 30
   5.3.3.1.3 Multihomed Connectivity ............................... 31
   5.3.3.1.4 Backdoor Links ........................................ 31
   5.3.3.1 Routing Protocol Instance ............................... 31
   5.3.3.2 Configuration ........................................... 33
   5.3.3.3 ISP Administered Addresses .............................. 33
   5.3.3.4 MPLS Label Distribution Protocol ........................ 33

Top      ToC       Page 3 
   5.3.4 Intra-VPN Reachability Information ........................ 34
   5.3.4.1 Directory Lookup ........................................ 34
   5.3.4.2 Explicit Configuration .................................. 34
   5.3.4.3 Local Intra-VPRN Routing Instantiations ................. 34
   5.3.4.4 Link Reachability Protocol .............................. 35
   5.3.4.5 Piggybacking in IP Backbone Routing Protocols ........... 36
   5.3.5 Tunneling Mechanisms ...................................... 36
   5.4 Multihomed Stub Routers ..................................... 37
   5.5 Multicast Support ........................................... 38
   5.5.1 Edge Replication .......................................... 38
   5.5.2 Native Multicast Support .................................. 39
   5.6 Recommendations ............................................. 40
   6.0 VPN Types:  Virtual Private Dial Networks ................... 41
   6.1 L2TP protocol characteristics ............................... 41
   6.1.1 Multiplexing .............................................. 41
   6.1.2 Signalling ................................................ 42
   6.1.3 Data Security ............................................. 42
   6.1.4 Multiprotocol Transport ................................... 42
   6.1.5 Sequencing ................................................ 42
   6.1.6 Tunnel Maintenance ........................................ 43
   6.1.7 Large MTUs ................................................ 43
   6.1.8 Tunnel Overhead ........................................... 43
   6.1.9 Flow and Congestion Control ............................... 43
   6.1.10 QoS / Traffic Management ................................. 43
   6.1.11 Miscellaneous ............................................ 44
   6.2 Compulsory Tunneling ........................................ 44
   6.3 Voluntary Tunnels ........................................... 46
   6.3.1 Issues with Use of L2TP for Voluntary Tunnels ............. 46
   6.3.2 Issues with Use of IPSec for Voluntary Tunnels ............ 48
   6.4 Networked Host Support ...................................... 49
   6.4.1 Extension of PPP to Hosts Through L2TP .................... 49
   6.4.2 Extension of PPP Directly to Hosts:  ...................... 49
   6.4.3 Use of IPSec .............................................. 50
   6.5 Recommendations ............................................. 50
   7.0 VPN Types:  Virtual Private LAN Segment ..................... 50
   7.1 VPLS Requirements ........................................... 51
   7.1.1 Tunneling Protocols ....................................... 51
   7.1.2 Multicast and Broadcast Support ........................... 52
   7.1.3 VPLS Membership Configuration and Topology ................ 52
   7.1.4 CPE Stub Node Types ....................................... 52
   7.1.5 Stub Link Packet Encapsulation ............................ 53
   7.1.5.1 Bridge CPE .............................................. 53
   7.1.5.2 Router CPE .............................................. 53
   7.1.6 CPE Addressing and Address Resolution ..................... 53
   7.1.6.1 Bridge CPE .............................................. 53
   7.1.6.2 Router CPE .............................................. 54
   7.1.7 VPLS Edge Node Forwarding and Reachability Mechanisms ..... 54
   7.1.7.1 Bridge CPE .............................................. 54

Top      ToC       Page 4 
   7.1.7.2 Router CPE .............................................. 54
   7.2 Recommendations ............................................. 55
   8.0 Summary of Recommendations .................................. 55
   9.0 Security Considerations ..................................... 56
   10.0 Acknowledgements ........................................... 56
   11.0 References ................................................. 56
   12.0 Author Information ......................................... 61
   13.0 Full Copyright Statement ................................... 62

1.0  Introduction

   This document describes a framework for Virtual Private Networks
   (VPNs) running across IP backbones.  It discusses the various
   different types of VPNs, their respective requirements, and proposes
   specific mechanisms that could be used to implement each type of VPN
   using existing or proposed specifications.  The objective of this
   document is to serve as a framework for related protocol development
   in order to develop the full set of specifications required for
   widespread deployment of interoperable VPN solutions.

   There is currently significant interest in the deployment of virtual
   private networks across IP backbone facilities.  The widespread
   deployment of VPNs has been hampered, however, by the lack of
   interoperable implementations, which, in turn, derives from the lack
   of general agreement on the definition and scope of VPNs and
   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
   defined as the 'emulation of a private Wide Area Network (WAN)
   facility using IP facilities' (including the public Internet, or
   private IP backbones).  As such, there are as many types of VPNs as
   there are types of WANs, hence the confusion over what exactly
   constitutes a VPN.

   In this document a VPN is modeled as a connectivity object.  Hosts
   may be attached to a VPN, and VPNs may be interconnected together, in
   the same manner as hosts today attach to physical networks, and
   physical networks are interconnected together (e.g., via bridges or
   routers).  Many aspects of networking, such as addressing, forwarding
   mechanism, learning and advertising reachability, quality of service
   (QoS), security, and firewalling, have common solutions across both
   physical and virtual networks, and many issues that arise in the
   discussion of VPNs have direct analogues with those issues as
   implemented in physical networks.  The introduction of VPNs does not
   create the need to reinvent networking, or to introduce entirely new
   paradigms that have no direct analogue with existing physical
   networks.  Instead it is often useful to first examine how a
   particular issue is handled in a physical network environment, and
   then apply the same principle to an environment which contains

Top      ToC       Page 5 
   virtual as well as physical networks, and to develop appropriate
   extensions and enhancements when necessary.  Clearly having
   mechanisms that are common across both physical and virtual networks
   facilitates the introduction of VPNs into existing networks, and also
   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
   types, showing the specific applications of each, their specific
   requirements, and the specific types of mechanisms that may be most
   appropriate for their implementation.  The intent of this document is
   to serve as a framework to guide a coherent discussion of the
   specific modifications that may be needed to existing IP mechanisms
   in order to develop a full range of interoperable VPN solutions.

   The document first discusses the likely expectations customers have
   of any type of VPN, and the implications of these for the ways in
   which VPNs can be implemented.  It also discusses the distinctions
   between Customer Premises Equipment (CPE) based solutions, and
   network based solutions.  Thereafter it presents a taxonomy of the
   various VPN types and their respective requirements.  It also
   outlines suggested approaches to their implementation, hence also
   pointing to areas for future standardization.

   Note also that this document only discusses implementations of VPNs
   across IP backbones, be they private IP networks, or the public
   Internet.  The models and mechanisms described here are intended to
   apply to both IPV4 and IPV6 backbones.  This document specifically
   does not discuss means of constructing VPNs using native mappings
   onto switched backbones - e.g., VPNs constructed using the LAN
   Emulation over ATM (LANE) [1] or Multiprotocol over ATM (MPOA) [2]
   protocols operating over ATM backbones.  Where IP backbones are
   constructed using such protocols, by interconnecting routers over the
   switched backbone, the VPNs discussed operate on top of this IP
   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, whereas IP based VPNs can extend to the
   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
   Forum.

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
   effective means of building and deploying private communication
   networks for multi-site communication than with existing approaches.

Top      ToC       Page 6 
   Existing private networks can be generally categorized into two types
   - dedicated WANs that permanently connect together multiple sites,
   and dial networks, that allow on-demand connections through the
   Public Switched Telephone Network (PSTN) to one or more sites in the
   private network.

   WANs are typically implemented using leased lines or dedicated
   circuits - for instance, Frame Relay or ATM connections - between the
   multiple sites.  CPE routers or switches at the various sites connect
   these dedicated facilities together and allow for connectivity across
   the network.  Given the cost and complexity of such dedicated
   facilities and the complexity of CPE device configuration, such
   networks are generally not fully meshed, but instead have some form
   of hierarchical topology.  For example remote offices could be
   connected directly to the nearest regional office, with the regional
   offices connected together in some form of full or partial mesh.

   Private dial networks are used to allow remote users to connect into
   an enterprise network using PSTN or Integrated Services Digital
   Network (ISDN) links.  Typically, this is done through the deployment
   of Network Access Servers (NASs) at one or more central sites.  Users
   dial into such NASs, which interact with Authentication,
   Authorization, and Accounting (AAA) servers to verify the identity of
   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
   speed Internet connections to their private corporate networks, there
   has been significant interest in the deployment of CPE based VPNs
   running across the Internet.  This has been driven typically by the
   ubiquity and distance insensitive pricing of current Internet
   services, that can result in significantly lower costs than typical
   dedicated or leased line services.

   The notion of using the Internet for private communications is not
   new, and many techniques, such as controlled route leaking, have been
   used for this purpose [3].  Only in recent times, however, have the
   appropriate IP mechanisms needed to meet customer requirements for
   VPNs all come together.  These requirements include the following:

2.1.1 Opaque Packet Transport:

   The traffic carried within a VPN may have no relation to the traffic
   on the IP backbone, either because the traffic is multiprotocol, or
   because the customer's IP network may use IP addressing unrelated to
   that of the IP backbone on which the traffic is transported.  In
   particular, the customer's IP network may use non-unique, private IP
   addressing [4].

Top      ToC       Page 7 
2.1.2 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
   such model is where the customer does not trust the service provider
   to provide any form of security, and instead implements a VPN using
   CPE devices that implement firewall functionality and that are
   connected together using secure tunnels.  In this case the service
   provider is used solely for IP packet transport.

   An alternative model is where the customer trusts the service
   provider to provide a secure managed VPN service.  This is similar to
   the trust involved when a customer utilizes a public switched Frame
   Relay or ATM service, in that the customer trusts that packets will
   not be misdirected, injected into the network in an unauthorized
   manner, snooped on, modified in transit, or subjected to traffic
   analysis by unauthorized parties.

   With this model providing firewall functionality and secure packet
   transport services is the responsibility of the service provider.
   Different levels of security may be needed within the provider
   backbone, depending on the deployment scenario used.  If the VPN
   traffic is contained within a single provider's IP backbone then
   strong security mechanisms, such as those provided by the IP Security
   protocol suite (IPSec) [5], may not be necessary for tunnels between
   backbone nodes.  If the VPN traffic traverses networks or equipment
   owned by multiple administrations then strong security mechanisms may
   be appropriate.  Also a strong level of security may be applied by a
   provider to customer traffic to address a customer perception that IP
   networks, and particularly the Internet, are insecure.  Whether or
   not this perception is correct it is one that must be addressed by
   the VPN implementation.

2.1.3 Quality of Service Guarantees

   In addition to ensuring communication privacy, existing private
   networking techniques, building upon physical or link layer
   mechanisms, also offer various types of quality of service
   guarantees.  In particular, leased and dial up lines offer both
   bandwidth and latency guarantees, while dedicated connection
   technologies like ATM and Frame Relay have extensive mechanisms for
   similar guarantees.  As IP based VPNs become more widely deployed,
   there will be market demand for similar guarantees, in order to
   ensure end to end application transparency.  While the ability of IP
   based VPNs to offer such guarantees will depend greatly upon the
   commensurate capabilities of the underlying IP backbones, a VPN
   framework must also address the means by which VPN systems can
   utilize such capabilities, as they evolve.

Top      ToC       Page 8 
2.1.4 Tunneling Mechanism

   Together, the first two of the requirements listed above imply that
   VPNs must be implemented through some form of IP tunneling mechanism,
   where the packet formats and/or the addressing used within the VPN
   can be unrelated to that used to route the tunneled packets across
   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
   be mapped into evolving IP traffic management mechanisms.  There are
   already defined a large number of IP tunneling mechanisms.  Some of
   these are well suited to VPN applications, as discussed in section
   3.0.

2.2  CPE and Network Based VPNs

   Most current VPN implementations are based on CPE equipment.  VPN
   capabilities are being integrated into a wide variety of CPE devices,
   ranging from firewalls to WAN edge routers and specialized VPN
   termination devices.  Such equipment may be bought and deployed by
   customers, or may be deployed (and often remotely managed) by service
   providers in an outsourcing service.

   There is also significant interest in 'network based VPNs', where the
   operation of the VPN is outsourced to an Internet Service Provider
   (ISP), and is implemented on network as opposed to CPE equipment.
   There is significant interest in such solutions both by customers
   seeking to reduce support costs and by ISPs seeking new revenue
   sources.  Supporting VPNs in the network allows the use of particular
   mechanisms which may lead to highly efficient and cost effective VPN
   solutions, with common equipment and operations support amortized
   across large numbers of customers.

   Most of the mechanisms discussed below can apply to either CPE based
   or network based VPNs.  However particular mechanisms are likely to
   prove applicable only to the latter, since they leverage tools (e.g.,
   piggybacking on routing protocols) which are accessible only to ISPs
   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
   coordinating joint management of the CPE gear by both the ISP and the
   customer.  This document will indicate which techniques are likely to
   apply only to network based VPNs.

Top      ToC       Page 9 
2.3  VPNs and Extranets

   The term 'extranet' is commonly used to refer to a scenario whereby
   two or more companies have networked access to a limited amount of
   each other's corporate data.  For example a manufacturing company
   might use an extranet for its suppliers to allow it to query
   databases for the pricing and availability of components, and then to
   order and track the status of outstanding orders.  Another example is
   joint software development, for instance, company A allows one
   development group within company B to access its operating system
   source code, and company B allows one development group in company A
   to access its security software.  Note that the access policies can
   get arbitrarily complex.  For example company B may internally
   restrict access to its security software to groups in certain
   geographic locations to comply with export control laws, for example.

   A key feature of an extranet is thus the control of who can access
   what data, and this is essentially a policy decision.  Policy
   decisions are typically enforced today at the interconnection points
   between different domains, for example between a private network and
   the Internet, or between a software test lab and the rest of the
   company network.  The enforcement may be done via a firewall, router
   with access list functionality, application gateway, or any similar
   device capable of applying policy to transit traffic.  Policy
   controls may be implemented within a corporate network, in addition
   to between corporate networks.  Also the interconnections between
   networks could be a set of bilateral links, or could be a separate
   network, perhaps maintained by an industry consortium.  This separate
   network could itself be a VPN or a physical network.

   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
   the Internet, in exactly the same manner as is done today without
   VPNs.  For example two VPNs could be interconnected, which each
   administration locally imposing its own policy controls, via a
   firewall, on all traffic that enters its VPN from the outside,
   whether from another VPN or from the Internet.

   This model of a VPN provides for a separation of policy from the
   underlying mode of packet transport used.  For example, a router may
   direct voice traffic to ATM Virtual Channel Connections (VCCs) for
   guaranteed QoS, non-local internal company traffic to secure tunnels,
   and other traffic to a link to the Internet.  In the past the secure
   tunnels may have been frame relay circuits, now they may also be
   secure IP tunnels or MPLS Label Switched Paths (LSPs)

Top      ToC       Page 10 
   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
   the policy rules imposed by a network administrator can get quite
   complex, the number of distinct sets of application flows that are
   used in the policy rulebase, and hence the number of VPNs, can thus
   grow quite large, and there can be multiple overlapping VPNs.
   However there is little to be gained by introducing such new
   complexity into a network.  Instead a VPN should be viewed as a
   direct analogue to a physical network, as this allows the leveraging
   of existing protocols and procedures, and the current expertise and
   skill sets of network administrators and customers.

3.0  VPN Tunneling

   As noted above in section 2.1, VPNs must be implemented using some
   form of tunneling mechanism.  This section looks at the generic
   requirements for such VPN tunneling mechanisms.  A number of
   characteristics and aspects common to any link layer protocol are
   taken and compared with the features offered by existing tunneling
   protocols.  This provides a basis for comparing different protocols
   and is also useful to highlight areas where existing tunneling
   protocols could benefit from extensions to better support their
   operation in a VPN environment.

   An IP tunnel connecting two VPN endpoints is a basic building block
   from which a variety of different VPN services can be constructed.
   An IP tunnel operates as an overlay across the IP backbone, and the
   traffic sent through the tunnel is opaque to the underlying IP
   backbone.  In effect the IP backbone is being used as a link layer
   technology, and the tunnel forms a point-to-point link.

   A VPN device may terminate multiple IP tunnels and forward packets
   between these tunnels and other network interfaces in different ways.
   In the discussion of different types of VPNs, in later sections of
   this document, the primary distinguishing characteristic of these
   different types is the manner in which packets are forwarded between
   interfaces (e.g., bridged or routed).  There is a direct analogy with
   how existing networking devices are characterized today.  A two-port
   repeater just forwards packets between its ports, and does not
   examine the contents of the packet.  A bridge forwards packets using
   Media Access Control (MAC) layer information contained in the packet,
   while a router forwards packets using layer 3 addressing information
   contained in the packet.  Each of these three scenarios has a direct
   VPN analogue, as discussed later.  Note that an IP tunnel is viewed
   as just another sort of link, which can be concatenated with another
   link, bound to a bridge forwarding table, or bound to an IP
   forwarding table, depending on the type of VPN.

Top      ToC       Page 11 
   The following sections look at the requirements for a generic IP
   tunneling protocol that can be used as a basic building block to
   construct different types of VPNs.

3.1  Tunneling Protocol Requirements for VPNs

   There are numerous IP tunneling mechanisms, including IP/IP [6],
   Generic Routing Encapsulation (GRE) tunnels [7], Layer 2 Tunneling
   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
   transport of frames as packet payload across an IP network, with
   forwarding disjoint from the address fields of the encapsulated
   packets.

   Note, however, that there is one significant distinction between each
   of the IP tunneling protocols mentioned above, and MPLS.  MPLS can be
   viewed as a specific link layer for IP, insofar as MPLS specific
   mechanisms apply only within the scope of an MPLS network, whereas IP
   based mechanisms extend to the extent of IP reachability.  As such,
   VPN mechanisms built directly upon MPLS tunneling mechanisms cannot,
   by definition, extend outside the scope of MPLS networks, any more so
   than, for instance, ATM based mechanisms such as LANE can extend
   outside of ATM networks.  Note however, that an MPLS network can span
   many different link layer technologies, and so, like an IP network,
   its scope is not limited by the specific link layers used.  A number
   of proposals for defining a set of mechanisms to allow for
   interoperable VPNs specifically over MPLS networks have also been
   produced ([10] [11] [12] [13], [14] and [15]).

   There are a number of desirable requirements for a VPN tunneling
   mechanism, however, that are not all met by the existing tunneling
   mechanisms.  These requirements include:

3.1.1  Multiplexing

   There are cases where multiple VPN tunnels may be needed between the
   same two IP endpoints.  This may be needed, for instance, in cases
   where the VPNs are network based, and each end point supports
   multiple customers.  Traffic for different customers travels over
   separate tunnels between the same two physical devices.  A
   multiplexing field is needed to distinguish which packets belong to
   which tunnel.  Sharing a tunnel in this manner may also reduce the
   latency and processing burden of tunnel set up.  Of the existing IP
   tunneling mechanisms, L2TP (via the tunnel-id and session-id fields),
   MPLS (via the label) and IPSec (via the Security Parameter Index
   (SPI) field) have a multiplexing mechanism.  Strictly speaking GRE
   does not have a multiplexing field.  However the key field, which was

Top      ToC       Page 12 
   intended to be used for authenticating the source of a packet, has
   sometimes been used as a multiplexing field.  IP/IP does not have a
   multiplexing field.

   The IETF [16] and the ATM Forum [17] have standardized on a single
   format for a globally unique identifier used to identify a VPN (a
   VPN-ID).  A VPN-ID can be used in the control plane, to bind a tunnel
   to a VPN at tunnel establishment time, or in the data plane, to
   identify the VPN associated with a packet, on a per-packet basis.  In
   the data plane a VPN encapsulation header can be used by MPLS, MPOA
   and other tunneling mechanisms to aggregate packets for different
   VPNs over a single tunnel.  In this case an explicit indication of
   VPN-ID is included with every packet, and no use is made of any
   tunnel specific multiplexing field.  In the control plane a VPN-ID
   field can be included in any tunnel establishment signalling protocol
   to allow for the association of a tunnel (e.g., as identified by the
   SPI field) with a VPN.  In this case there is no need for a VPN-ID to
   be included with every data packet.  This is discussed further in
   section 5.3.1.

3.1.2  Signalling Protocol

   There is some configuration information that must be known by an end
   point in advance of tunnel establishment, such as the IP address of
   the remote end point, and any relevant tunnel attributes required,
   such as the level of security needed.  Once this information is
   available, the actual tunnel establishment can be completed in one of
   two ways - via a management operation, or via a signalling protocol
   that allows tunnels to be established dynamically.

   An example of a management operation would be to use an SNMP
   Management Information Base (MIB) to configure various tunneling
   parameters, e.g., MPLS labels, source addresses to use for IP/IP or
   GRE tunnels, L2TP tunnel-ids and session-ids, or security association
   parameters for IPSec.

   Using a signalling protocol can significantly reduce the management
   burden however, and as such, is essential in many deployment
   scenarios.  It reduces the amount of configuration needed, and also
   reduces the management co-ordination needed if a VPN spans multiple
   administrative domains.  For example, the value of the multiplexing
   field, described above, is local to the node assigning the value, and
   can be kept local if distributed via a signalling protocol, rather
   than being first configured into a management station and then
   distributed to the relevant nodes.  A signalling protocol also allows
   nodes that are mobile or are only intermittently connected to
   establish tunnels on demand.

Top      ToC       Page 13 
   When used in a VPN environment a signalling protocol should allow for
   the transport of a VPN-ID to allow the resulting tunnel to be
   associated with a particular VPN.  It should also allow tunnel
   attributes to be exchanged or negotiated, for example the use of
   frame sequencing or the use of multiprotocol transport.  Note that
   the role of the signalling protocol need only be to negotiate tunnel
   attributes, not to carry information about how the tunnel is used,
   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
   signalling - the same signalling protocol is used to set up Classical
   IP logical subnetworks as well as for LANE emulated LANs.

   Of the various IP tunneling protocols, the following ones support a
   signalling protocol that could be adapted for this purpose: L2TP (the
   L2TP control protocol), IPSec (the Internet Key Exchange (IKE)
   protocol [18]), and GRE (as used with mobile-ip tunneling [19]). Also
   there are two MPLS signalling protocols that can be used to establish
   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

   A VPN tunneling protocol must support mechanisms to allow for
   whatever level of security may be desired by customers, including
   authentication and/or encryption of various strengths.  None of the
   tunneling mechanisms discussed, other than IPSec, have intrinsic
   security mechanisms, but rely upon the security characteristics of
   the underlying IP backbone.  In particular, MPLS relies upon the
   explicit labeling of label switched paths to ensure that packets
   cannot be misdirected, while the other tunneling mechanisms can all
   be secured through the use of IPSec.  For VPNs implemented over non-
   IP backbones (e.g., MPOA, Frame Relay or ATM virtual circuits), data
   security is implicitly provided by the layer two switch
   infrastructure.

   Overall VPN security is not just a capability of the tunnels alone,
   but has to be viewed in the broader context of how packets are
   forwarded onto those tunnels.  For example with VPRNs implemented
   with virtual routers, the use of separate routing and forwarding
   table instances ensures the isolation of traffic between VPNs.
   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
   first VPN.

Top      ToC       Page 14 
   If some form of signalling mechanism is used by one VPN end point to
   dynamically establish a tunnel with another endpoint, then there is a
   requirement to be able to authenticate the party attempting the
   tunnel establishment.  IPSec has an array of schemes for this
   purpose, allowing, for example, authentication to be based on pre-
   shared keys, or to use digital signatures and certificates.  Other
   tunneling schemes have weaker forms of authentication.  In some cases
   no authentication may be needed, for example if the tunnels are
   provisioned, rather than dynamically established, or if the trust
   model in use does not require it.

   Currently the IPSec Encapsulating Security Payload (ESP) protocol
   [23] can be used to establish SAs that support either encryption or
   authentication or both.  However the protocol specification precludes
   the use of an SA where neither encryption or authentication is used.
   In a VPN environment this "null/null" option is useful, since other
   aspects of the protocol (e.g., that it supports tunneling and
   multiplexing) may be all that is required.  In effect the "null/null"
   option can be viewed as just another level of data security.

3.1.4  Multiprotocol Transport

   In many applications of VPNs, the VPN may carry opaque, multiprotocol
   traffic.  As such, the tunneling protocol used must also support
   multiprotocol transport.  L2TP is designed to transport Point-to-
   Point Protocol (PPP) [24] packets, and thus can be used to carry
   multiprotocol traffic since PPP itself is multiprotocol.  GRE also
   provides for the identification of the protocol being tunneled.
   IP/IP and IPSec tunnels have no such protocol identification field,
   since the traffic being tunneled is assumed to be IP.

   It is possible to extend the IPSec protocol suite to allow for the
   transport of multiprotocol packets.  This can be achieved, for
   example, by extending the signalling component of IPSec - IKE, to
   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)
   with each tunneled packet.  This approach is similar to that used for
   the same purpose in ATM networks, where signalling is used to
   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 AAL5 payload, the latter being known as VC-multiplexing (see
   [25]).

3.1.5  Frame Sequencing

   One quality of service attribute required by customers of a VPN may
   be frame sequencing, matching the equivalent characteristic of
   physical leased lines or dedicated connections.  Sequencing may be

Top      ToC       Page 15 
   required for the efficient operation of particular end to end
   protocols or applications.  In order to implement frame sequencing,
   the tunneling mechanism must support a sequencing field.  Both L2TP
   and GRE have such a field.  IPSec has a sequence number field, but it
   is used by a receiver to perform an anti-replay check, not to
   guarantee in-order delivery of packets.

   It is possible to extend IPSec to allow the use of the existing
   sequence field to guarantee in-order delivery of packets.  This can
   be achieved, for example, by using IKE to negotiate whether or not
   sequencing is to be used, and to define an end point behaviour which
   preserves packet sequencing.

3.1.6  Tunnel Maintenance

   The VPN end points must monitor the operation of the VPN tunnels to
   ensure that connectivity has not been lost, and to take appropriate
   action (such as route recalculation) if there has been a failure.

   There are two approaches possible.  One is for the tunneling protocol
   itself to periodically check in-band for loss of connectivity, and to
   provide an explicit indication of failure.  For example L2TP has an
   optional keep-alive mechanism to detect non-operational tunnels.

   The other approach does not require the tunneling protocol itself to
   perform this function, but relies on the operation of some out-of-
   band mechanism to determine loss of connectivity.  For example if 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 neighbor within a certain period of time will
   result in the routing protocol declaring the tunnel to be down.
   Another out-of-band approach is to perform regular ICMP pings with a
   peer.  This is generally sufficient assurance that the tunnel is
   operational, due to the fact the tunnel also runs across the same IP
   backbone.

   When tunnels are established dynamically a distinction needs to be
   drawn between the static and dynamic tunnel information needed.
   Before a tunnel can be established some static information is needed
   by a node, such as the identify of the remote end point and the
   attributes of the tunnel to propose and accept.  This is typically
   put in place as a result of a configuration operation.  As a result
   of the signalling exchange to establish a tunnel, some dynamic state
   is established in each end point, such as the value of the
   multiplexing field or keys to be used.  For example with IPSec, the
   establishment of a Security Association (SA) puts in place the keys
   to be used for the lifetime of that SA.

Top      ToC       Page 16 
   Different policies may be used as to when to trigger the
   establishment of a dynamic tunnel.  One approach is to use a data-
   driven approach and to trigger tunnel establishment whenever there is
   data to be transferred, and to timeout the tunnel due to inactivity.
   This approach is particularly useful if resources for the tunnel are
   being allocated in the network for QoS purposes.  Another approach is
   to trigger tunnel establishment whenever the static tunnel
   configuration information is installed, and to attempt to keep the
   tunnel up all the time.

3.1.7  Large MTUs

   An IP tunnel has an associated Maximum Transmission Unit (MTU), just
   like a regular link. It is conceivable that this MTU may be larger
   than the MTU of one or more individual hops along the path between
   tunnel endpoints. If so, some form of frame fragmentation will be
   required within the tunnel.

   If the frame to be transferred is mapped into one IP datagram, normal
   IP fragmentation will occur when the IP datagram reaches a hop with
   an MTU smaller than the IP tunnel's MTU. This can have undesirable
   performance implications at the router performing such mid-tunnel
   fragmentation.

   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.

3.1.8  Minimization of Tunnel Overhead

   There is clearly benefit in minimizing the overhead of any tunneling
   mechanisms.  This is particularly important for the transport of
   jitter and latency sensitive traffic such as packetized voice and
   video.  On the other hand, the use of security mechanisms, such as
   IPSec, do impose their own overhead, hence the objective should be to
   minimize overhead over and above that needed for security, and to not
   burden those tunnels in which security is not mandatory with
   unnecessary overhead.

   One area where the amount of overhead may be significant is when
   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
   discussed further in section 6.3.

Top      ToC       Page 17 
3.1.9  Flow and congestion control

   During the development of the L2TP protocol procedures were developed
   for flow and congestion control.  These were necessitated primarily
   because of the need to provide adequate performance over lossy
   networks when PPP compression is used, which, unlike IP Payload
   Compression Protocol (IPComp) [28], is stateful across packets.
   Another motivation was to accommodate devices with very little
   buffering, used for example to terminate low speed dial-up lines.
   However the flow and congestion control mechanisms defined in the
   final version of the L2TP specification are used only for the control
   channels, and not for data traffic.

   In general the interactions between multiple layers of flow and
   congestion control schemes can be very complex.  Given the
   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
   not clear that there is much benefit to implementing similar
   mechanisms within tunneling protocols.  Good flow and congestion
   control schemes, that can adapt to a wide variety of network
   conditions and deployment scenarios are complex to develop and test,
   both in themselves and in understanding the interaction with other
   schemes that may be running in parallel.  There may be some benefit,
   however, in having the capability whereby a sender can shape traffic
   to the capacity of a receiver in some manner, and in providing the
   protocol mechanisms to allow a receiver to signal its capabilities to
   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

   As noted above, customers may require that VPNs yield similar
   behaviour to physical leased lines or dedicated connections with
   respect to such QoS parameters as loss rates, jitter, latency and
   bandwidth guarantees.  How such guarantees could be delivered will,
   in general, be a function of the traffic management characteristics
   of the VPN nodes themselves, and the access and backbone networks
   across which they are connected.

   A full discussion of QoS and VPNs is outside the scope of this
   document, however by modeling a VPN tunnel as just another type of
   link layer, many of the existing mechanisms developed for ensuring
   QoS over physical links can also be applied.  For example at a VPN
   node, the mechanisms of policing, marking, queuing, shaping and

Top      ToC       Page 18 
   scheduling can all be applied to VPN traffic with VPN-specific
   parameters, queues and interfaces, just as for non-VPN traffic.  The
   techniques developed for Diffserv, Intserv and for traffic
   engineering in MPLS are also applicable.  See also [29] for a
   discussion of QoS and VPNs.

   It should be noted, however, that this model of tunnel operation is
   not necessarily consistent with the way in which specific tunneling
   protocols are currently modeled.  While a model is an aid to
   comprehension, and not part of a protocol specification, having
   differing models can complicate discussions, particularly if a model
   is misinterpreted as being part of a protocol specification or as
   constraining choice of implementation method.  For example, IPSec
   tunnel processing can be modeled both as an interface and as an
   attribute of a particular packet flow.

3.2  Recommendations

   IPSec is needed whenever there is a requirement for strong encryption
   or strong authentication.  It also supports multiplexing and a
   signalling protocol - IKE.  However extending the IPSec protocol
   suite to also cover the following areas would be beneficial, in order
   to better support the tunneling requirements of a VPN environment.

   -  the transport of a VPN-ID when establishing an SA (3.1.2)

   -  a null encryption and null authentication option (3.1.3)

   -  multiprotocol operation (3.1.4)

   -  frame sequencing (3.1.5)

   L2TP provides no data security by itself, and any PPP security
   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.
   Defining specific modes of operation for IPSec when it is used to
   support L2TP traffic will aid interoperability.  This is currently a
   work item for the proposed L2TP working group.



(page 18 continued on part 2)

Next RFC Part