[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 rfc2764                                           
Internet Engineering Task Force                Bryan Gleeson, Arthur Lin
INTERNET DRAFT                                     Shasta Networks, Inc.
Expires March 1999                                         Juha Heinanen
                                                     Telia Finland, Inc.
                                                      Grenville Armitage
                                          Bell Labs, Lucent Technologies


           A Framework for IP Based Virtual Private Networks
                  <draft-gleeson-vpn-framework-00.txt>



1. Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).


2.0 Abstract

   This document describes a framework for virtual private networks
   (VPN) 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
   Draft 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.


3.0 Introduction

   There is currently significant interest in the deployment of virtual
   private networks (VPN), across IP backbone facilities.  The



Gleeson et al.                                                  [Page 1]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   widespread deployment of VPNs has been hampered, however, by the lack
   of interoperable implementations, which, in turn, derive 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 Draft, 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.

   This framework Draft 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 Draft 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 Draft 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 Draft only discusses implementations of VPNs
   across IP backbones, be they private IP networks, or the public
   Internet.  It specifically does not discuss means of constructing
   VPNs using native mappings onto switched backbones - e.g. VPNs
   constructed using, for instance, the LAN Emulation over ATM (LANE)
   [ATMF1] or Multiprotocol over ATM (MPOA) [ATMF2] protocols operating
   over ATM backbones.  IP backbones may be constructed using such
   native protocols, interconnecting routers across the switched
   backbone. IP VPNs would then operate on top of this IP network, and
   hence would not directly utilize the native mechanisms of the
   underlying backbone.  Native VPNs would be 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.

4.0 VPN Application and Implementation Requirements

   There is growing interest in the use of IP VPNs as a more cost
   effective means of building and deploying private communication



Gleeson et al.                                                  [Page 2]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   networks for multi-site communication than with existing approaches.
   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 PSTN
   network 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 have a complex mix of
   tree and mesh topologies with remote offices, for instance, star
   wired to the nearest central site, with the latter then 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 ISDN links.  Typically, this is
   done through the deployment of network access servers (NAS) at one or
   more central sites. Users dial into such NAS, which interact with
   AAAA ('Authentication, Authorization, Accounting and Administration')
   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, in addition to previous private 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 [Ferguson].  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:

   A.  Support for 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 latter may also be non-unique, private IP addressing
   [Rekhter1].



Gleeson et al.                                                  [Page 3]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   B.  Support for Data Security:

   In general, customers using VPNs require some form of data security,
   given the general perceptions of the lack of security of IP networks,
   and particularly that of the Internet.  Whether or not this
   perception is correct, it is one that must be addressed by any VPN
   implementation.  Note that some security concerns - e.g. snooping -
   may be alleviated in cases where all of the VPN traffic stays within
   a single service provider's closed IP backbone; on the other hand,
   this alone may not address other concerns such as packet
   misdirection, data integrity or ability of third parties to insert
   unauthorized packets.  Most recent VPN implementations are converging
   on the use of standard IPSec facilities [Kent] for this purpose.

   C.  Support for 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.

   Together, the first two of these requirements 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 further
   below.








Gleeson et al.                                                  [Page 4]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


4.1  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.  The Draft will indicate which techniques are likely to
   apply only to network based VPNs.


5.0  VPN Types:  'Virtual Leased Lines'

   The simplest form of a VPN is a 'virtual leased line' (VLL) service.
   In this case, the two VPN endpoints are connected by an IP tunnel
   which seeks to emulate a physical leased line or dedicated
   connection. The 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 IP tunnel forms a point-to-point link.
   A device may terminate multiple such VLLs and route or bridge between
   them, but the manner in which the the VLLs are connected, i.e. at
   layer 3 or layer 2, is independent of the operation of the VLL
   itself. For example at layer 3 the VLL can be bound to an IP
   forwarding table, which views it as just another point-to-point IP
   interface. A simple example of forwarding at layer 2 is the operation
   of relaying frames between an ATM VCC and a VLL, in effect forming a
   point-to-point link. VLLs can also be used to interconnect bridging
   devices.



Gleeson et al.                                                  [Page 5]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   More generally, a VLL can also be considered to be the building block
   of more complex VPN types and topologies.  Specifically, as will be
   discussed in following sections, there are also VPN types in which
   the forwarding operation, be it at the link layer or the network
   layer, is also part of the operation of the VPN.  In this case, the
   tunnels connecting each of the VPN nodes can be constructed using VLL
   tunneling mechanisms, since these have the same requirements.

   The following section, therefore, looks at the requirements of a
   generic IP tunneling protocol that can be used both for simple VLL
   applications, and also for more complex types of VPNs.


5.1  Tunneling Protocol Requirements for VLLs

   There are numerous IP tunneling mechanisms, including IP/IP
   [Simpson], GRE tunnels [Hanks], L2TP [Valencia1], MPLS [Callon] and
   IPSec [Kent].  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, with forwarding disjoint from
   the address fields of the encapsulated packets.  As such, any of
   these could be applied to the operation of a VLL, albeit with some
   modifications, as discussed below.

   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 (e.g. as
   described in [Heinanen1] or [Jamieson]) 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. Parallel work on defining a set of
   mechanisms to allow for interoperable VPNs specifically over MPLS
   networks is also underway, as addressed in [Heinanen2] and
   [Jamieson], and as will be discussed later.

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








Gleeson et al.                                                  [Page 6]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


5.1.1  Support for VLL Multiplexing:

   There are cases where multiple VLLs may be needed between the same
   two IP endpoints. This may be needed, for instance, in cases where
   the VLLs are network based, and each end point supports multiple
   customers. Traffic for different customers travels over separate VLLs
   between the same two physical devices. A multiplexing field is needed
   to distinguish which packets belong to which VLL. 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 call-id fields), MPLS (via the label) and IPSec
   (via the SPI field) have a multiplexing mechanism. Strictly speaking
   GRE does not have a multiplexing field. However the key field, which
   was 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.

5.1.2 Support for a Signalling Protocol

   For a VLL 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). Following this
   configuration 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 MIB to
   configure various tunneling parameters, e.g. MPLS labels, source
   addresses to use for IP/IP or GRE tunnels, L2TP tunnel-ids and call-
   ids, or security association parameters for IPSec.

   Using a signalling protocol can significantly reduce the management
   burden however and should be a requirement for any standard VLL
   tunneling mechanism. It reduces the amount of configuration needed,
   and 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. Signalling is particularly
   useful for the VPRN scenario described later (section 6.0).

   A signalling protocol should allow for the transport of a VPN
   identifier (see 6.1.1) to allow the resulting tunnel to be associated
   with a particular VLL. It should also allow tunnel attributes to be



Gleeson et al.                                                  [Page 7]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   exchanged or negotiated, for example the use of frame sequencing or
   the use of multiprotocol transport. Note that the role of the
   signalling protocol is solely 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 LISs as well as
   LANE ELANs).

   Of the various tunneling protocols, the following ones support a
   signaling protocol that could possibly be adapted for this purpose:
   MPLS (the various mechanisms for label distribution, including the
   label distribution protocol (LDP)  [Thomas]), L2TP (the L2TP control
   channel) and IPSec (the Internet Key Exchange (IKE) protocol
   [Harkins]), and GRE (as used with mobile-ip tunneling [Calhoun3]).

5.1.3  Support for Data Security:

   A VLL tunneling mechanism 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 (LSP) to ensure that
   packets cannot be misdirected, while the other tunneling mechanisms
   can all be secured through the use of IPSec.

   If some form of signalling mechanism is used by one VLL 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 public/private key pairs with 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.

5.1.4  Support for Multiprotocol Transport

   In many applications of VLLs, the VLL may carry opaque, multiprotocol
   traffic.  As such, the tunneling protocol must also support
   multiprotocol transport.  The only tunneling mechanism which will
   preclude such transport is IP/IP. L2TP is designed to transport PPP
   packets, and thus can be used to carry multiprotocol traffic since
   PPP itself is multiprotocol.  IPSec has been designed to transport IP
   packets, but may be readily generalized to carry multiprotocol



Gleeson et al.                                                  [Page 8]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   traffic. The signalling component of IPSec (IKE) could be extended to
   indicate the type of traffic carried over the IP tunnel or the type
   of packet multiplexing header used (e.g. LLC/SNAP, GRE), if the
   traffic is not IP.

5.1.5  Support for Frame Sequencing:

   One quality of service attribute required by customers of a VLL, may
   be frame sequencing, matching the equivalent characteristic of
   physical leased lines or dedicated connections.  Sequencing may be
   required for the efficient operation of particular end to end
   protocols or applications.  In order to implement frame sequencing, a
   VLL tunneling mechanism should have the option of a sequencing field.
   At present, only the L2TP specification has 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.

5.1.6  Support for Tunnel Maintenance:

   The VLL end points must monitor the operation of the VLL tunnels to
   ensure that connectivity has not been lost.  Note that this does not
   necessarily require inband verification, since IP backbone
   connectivity with the VLL end point is sufficient assurance, due to
   the fact the tunnel also runs across the same backbone. L2TP has an
   optional in-band keep-alive mechanism to detect non-operational
   tunnels. Other tunneling mechanisms will likely require some out of
   band mechanism to determine connectivity - for instance, regular ICMP
   pings.

   Note also that tunnel inactivity should be differentiated from tunnel
   deletion. A distinction needs to be made between the creation and
   deletion of a VLL tunnel, and the establishment and termination of a
   tunnel instance. The creation of a VLL tunnel is a configuration
   operation, whereby the information needed to dynamically establish a
   tunnel (e.g. the remote IP end point) is installed. Similarly the
   deletion of such a VLL tunnel is a configuration operation that
   removes this information. The establishment of a tunnel instance
   occurs as a result of a signalling exchange, with parameters being
   transferred (e.g. the value of the multiplexing field) and any needed
   resources being put in place. This may occur immediately the VLL
   tunnel is created, or a data-driven approach could be used, whereby
   the tunnel instance is only established when there is some data to be
   transferred. Also the tunnel instance could be maintained until VLL
   tunnel deletion, whether or not it was being used, or it could be
   terminated due to an idle timeout, and re-established whenever there
   was subsequently data ready for transfer. The latter approach may be
   useful if resources are being allocated for traffic management
   purposes, to avoid dedicating resources for inactive tunnel



Gleeson et al.                                                  [Page 9]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   instances.

5.1.7  Support for Large MTUs

   Since the traffic sent through a VLL may often be opaque to the
   underlying IP backbone, it cannot also generally be assumed that the
   maximum transfer unit (MTU) of the VLL itself, is less than or equal
   to that of the MTU of the particular route of the VLL across the IP
   backbone. As such, the VLL tunneling mechanism may need mechanisms to
   allow for frame fragmentation, either within the tunnel, or at the IP
   level.

   If the frame to be transferred is mapped into one IP datagram, normal
   IP fragmentation mechanisms can be used. There may also be value in
   defining fragmentation techniques that operate at the tunnel level
   (using the tunnel sequence number and an end-of-message marker of
   some sort) in order to avoid IP level fragmentation. This subject is
   for further study.

5.1.8 Minimization of Tunnel Overhead

   There is clearly benefit in minimizing the overhead of VLL tunneling
   mechanisms.  This is particularly important for the transport of
   small, 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 VLLs in which security is not mandatory with
   unnecessary overhead.

5.1.9 Flow and congestion control issues

   Of the existing tunneling schemes only L2TP has procedures for flow
   and congestion control. These were necessitated in part due to the
   need to provide adequate performance over lossy networks when PPP
   compression (which, unlike the IP Payload Compression Protocol
   (IPComp) [Shacham], is stateful across packets) is being used, and to
   accommodate devices with very little buffering. The flow and
   congestion control mechanisms used with L2TP are largely specific to
   the use of PPP and devices that terminate low speed dial-up lines.

   More analysis is needed to see if any flow and congestion control
   mechanisms should be incorporated into a generic IP tunneling
   protocol. For TCP traffic, the end-to-end flow and congestion control
   provided by TCP itself will generally suffice. 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



Gleeson et al.                                                 [Page 10]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   with other schemes (e.g. TCP's) 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 area is for further
   study.

5.1.10 Traffic Management issues

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

   However, it is likely that the most general solution would be to
   model a VLL as a logical link which extends across the backbone
   between two terminating devices.  As such, all of the capabilities
   currently being developed and deployed for traffic management,
   including link sharing, differentiated services [Bernet] and fair
   scheduling could also be applied to the VLL.  The specific
   capabilities that may be needed from VLL tunneling mechanisms to
   support such requirements is for further study.

   It will be noted, however, that this proposed model of tunnel
   operation may not wholly consistent with the way in which specific
   tunneling protocols are currently modeled. In particular, it is
   unclear whether an IPSec tunnel is considered in the current IPSec
   architecture to be an interface, per se, or an attribute of a
   particular packet flow.


5.2  Specification Recommendations

   There is a need for a standard VLL tunneling mechanism, that
   addresses each of the requirements discussed above. Given the
   necessity for strong encryption and strong authentication
   capabilities it would appear that a modification of IKE/IPSec may
   well be the optimal choice, particularly for non-MPLS based networks,
   since in addition to addressing the need for secure tunnels, it
   already has well defined signaling and multiplexing capabilities
   which can be readily amended for the specific needs of VLLs. To
   minimize overhead, including the overhead of configuration, control
   state, and processing cycles, as well as extra header fields added to
   a data packet, it also seems advantageous to converge on the use of a
   single signalling protocol and associated data encapsulation, rather



Gleeson et al.                                                 [Page 11]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   than use multiple protocols in parallel (e.g. IKE/IPSec and L2TP).
   However the use of IPSec as a VPN tunneling mechanism may require
   amendments to the envisaged model of IPSec usage implicit in the
   current IPSec architecture. A future draft will discuss these
   amendments in greater detail. Note that parallel work is also
   underway in the MPLS WG on MPLS-based tunneling mechanisms as
   discussed in [Heinanen2].


6.0 VPN Types:  Virtual Private Routed Networks

   A virtual private routed network (VPRN) is defined to be the
   emulation of a multi-site wide area routed network using IP
   facilities. This section looks at how a network-based VPRN service
   can be provided.  CPE-based VPRNs are also possible, but are not
   specifically discussed here. With network-based VPRNs many of the
   issues that need to be addressed are concerned with configuration and
   operational issues, which must take into account the split in
   administrative responsibility between the service provider (ISP) and
   the service user (customer).

   A VPRN consists of a mesh of IP tunnels between ISP routers, together
   with the routing capabilities needed to forward traffic received at
   each VPRN site to the appropriate destination site. Attached to these
   ISP routers are CPE routers connected via one or more links, termed
   'stub' links. This is illustrated in the following diagram, which
   shows 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 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 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
   that does not traverse the ISP network.


















Gleeson et al.                                                 [Page 12]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


               +--------+                       +--------+
   +---+       | ISP    |                       | ISP    |      +---+
   |CPE|-------| edge   |-----------------------| edge   |------|CPE|
   +---+       | router |     IP tunnel         | router |      +---+
         stub  +--------+                       +--------+ stub   :
         link   |   |                                |     link   :
                |   |                                |            :
                |   |         IP BACKBONE            |            :
                |   |                                |            :
                |   |IP tunnel              IP tunnel|            :
                |   |           +--------+           |            :
                |   |           | ISP    |           |            :
                |   +-----------| edge   |-----------+            :
                |               | router |                        :
          backup|               +--------+                backdoor:
           link |                |      |                   link  :
                |      stub link |      |  stub link              :
                |                |      |                         :
                |             +---+    +---+                      :
                +-------------|CPE|    |CPE|......................:
                              +---+    +---+



   The principal benefit of a VPRN is that the configuration of the CPE
   router is simplified. To a CPE router, the ISP edge router appears as
   a neighbour router in the customer's network, to which it sends all
   traffic for non-local VPRN destinations. 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.

   This is in contrast to the scenario where the tunnel mesh extends to
   the CPE routers. In this case the ISP network provides layer 2
   connectivity alone. This can be implemented either as a set of VLLs
   between CPE routers, in which case the ISP network provides a set of
   layer 2 point-to-point links, or as a Virtual Private LAN Segment
   (VPLS) (see section 8.0), in which case the ISP network is used to
   emulate a multiaccess LAN segment. With these scenarios a customer
   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
   more complex configuration for the customer. Thus, depending on
   customer requirements, a VPRN or a VPLS may be the more appropriate
   solution.

   Because a VPRN carries out forwarding at the network layer, a single
   VPRN only directly supports a single network layer protocol. For
   multiprotocol support, a separate VPRN for each network layer



Gleeson et al.                                                 [Page 13]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   protocol could be used, or one protocol could be tunneled over
   another (e.g.  non-IP protocols tunneled over an IP VPRN) or
   alternatively the ISP network could be used to provide layer 2
   connectivity only, such as with a VPLS as mentioned above.

   The issues to be addressed for VPRNs include initial configuration,
   determination of the set of routers that have members in a VPRN,
   determination by an ISP edge router of the set of IP address prefixes
   reachable via each stub link, determination by a CPE router of the
   set of IP address prefixes to be forwarded to an ISP edge router, the
   mechanism used to disseminate stub reachability information to the
   correct set of ISP routers, and the establishment and use of the
   tunnels used to carry the data traffic.  Note also that, although
   discussed first for VPRNs, many of these issues also apply to the
   VPLS scenario described later, with the network layer addresses being
   replaced by link layer addresses.

   Note that VPRN operation is decoupled from the mechanisms used by the
   customer sites to access the Internet. A typical scenario would be
   for the ISP edge router to be used for both VPRN and Internet
   connectivity. In this case the CPE router would have a default route
   pointing to the ISP edge router. However a customer site could have
   Internet connectivity via an ISP router not involved in the VPRN, or
   even via a different ISP. In this case, for VPRN traffic, the CPE
   router would have a route (or set of routes) for all non-local VPRN
   destinations, pointing to the ISP edge router. This is termed a 'VPRN
   default route', and is used where necessary in contrast to 'default
   route' which refers to all non-local destinations (including both
   non-local VPRN destinations and external Internet destinations).

   VPRN requirements and mechanisms have been discussed previously in
   [Heinanen2], with a particular focus in that Draft showing how the
   same VPRN functionality can be implemented over both MPLS and non-
   MPLS networks.

   A. Topology

   The topology of a VPRN may consist of a full mesh of tunnels between
   each VPRN site, or may be an arbitrary topology, such as a set of
   remote offices connected to the nearest central site, with these
   central sites connected together via a full or partial mesh. With
   VPRNs there is much less cost assumed with full meshing than in cases
   where physical resources (e.g. Frame Relay DLCI or a leased line)
   must be allocated for each connected pair of sites.  This yields
   optimal routing, since it precludes the need for traffic between two
   sites to traverse through a third. One attraction of a full mesh
   topology is that there is no need to configure topology information
   for the VPRN. Instead, given the member routers of a VPRN, the



Gleeson et al.                                                 [Page 14]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   topology is implicit. If the number of ISP edge routers in a VPRN is
   very large, however, a full mesh topology may not be appropriate, due
   to the scaling issues involved, for example, the growth in the number
   of tunnels needed between sites, (which for n sites is n(n-1)/2), or
   the number of routing peers per router. Network policy may also lead
   to non full mesh topologies, for example an administrator may wish to
   set up the topology so that traffic between two remote sites passes
   through a central site, rather than go directly between the remote
   sites.  It is also necessary to deal with the scenario where there is
   only partial connectivity across the IP backbone under certain error
   conditions (e.g. A can reach B, and B can reach C, but A cannot reach
   C directly), which can occur if policy routing is being used.

   For a network-based VPRN, it is assumed that each customer site CPE
   router connects to an ISP edge router through one or more dedicated
   point-to-point stub links (e.g. leased lines, ATM or Frame Relay
   connections). The ISP routers are responsible for learning and
   disseminating reachability information amongst themselves. The CPE
   routers must learn the set of destinations reachable via each stub
   link, though this may be as simple as a default route.

   B. Addressing

   The addressing used within a VPRN may have no relation to the
   addressing used on the IP backbone over which the VPRN is
   instantiated. In particular non-unique private IP addressing may be
   used [Rekhter1]. Multiple VPRNs may be instantiated over the same set
   of physical devices, and they may use the same or overlapping address
   spaces.

   C. Forwarding

   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
   specific forwarding mechanisms to forward packets received from stub
   links ('ingress traffic') to the appropriate next hop router, and to
   forward packets received from the core ('egress traffic') to the
   appropriate stub link. For cases where a ISP edge router supports
   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.
   In the former case a VPN specific forwarding table is needed for
   egress traffic, in the latter case it is not. A VPN specific
   forwarding table is generally needed in the ingress direction, in
   order to direct traffic received on a stub link onto the correct IP
   tunnel towards the core.

   Also since a VPRN operates at the internetwork layer, the IP packets
   send over a tunnel will have their TTL field decremented in the



Gleeson et al.                                                 [Page 15]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   normal manner, preventing packets circulating indefinitely in the
   event of a routing loop within the VPRN.

   D. Multiple concurrent VPRN connectivity

   Note also that a single customer site may belong concurrently to
   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 are
   a number of possible approaches to this problem, but these are
   outside the scope of the current Draft.

6.1 VPRN Generic Requirements

   There are a number of common requirements which any network-based
   VPRN solution must address, and there are a number of different
   mechanisms that can be used to meet these requirements. These generic
   issues are

   - The use of a globally unique VPN identifier in order to be able to
   refer to a particular VPN.

   - VPRN membership determination. An edge router must learn of the
   other routers that have members in that VPRN.

   - Stub link reachability information. An edge router must learn the
   set of addresses and address prefixes reachable via each stub link.

   - Intra-VPRN reachability information. Once an edge router has
   determined the set of address prefixes associated with each of its
   stub links, then this information must be disseminated to each other
   edge router in the VPRN.

   - Tunneling mechanism. An edge router must construct the necessary
   tunnels to other routers that have members in the VPRN, and must
   perform the encapsulation and decapsulation necessary to send and
   receive packets over the tunnels.


6.1.1 VPN Identifier

   Network-based VPRNs may potentially span multiple autonomous systems
   (ASs) and multiple management domains. This implies the need for a
   VPN identifier than can be unique across multiple ASs. To that end,
   [Heinanen1] proposed a globally unique VPN identifier (note that such
   an identifier may be useful for VPN types other than VPRNs) made up
   of the concatenation of an AS number, and a label assigned by the AS
   administrator which is locally unique within the particular AS. This
   is one solution to the need for a globally unique VPN identifier used



Gleeson et al.                                                 [Page 16]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   across public networks. Specifically a VPN ID could be coded as a
   four octet BGP Communities Attribute [Chandra], made up of a two
   octet AS number and a 2 octet, unstructured integer VPN number, to
   allow for sufficient numbers of VPNs per AS.

   Note that where a VPN crosses multiple ASs, then there must be some
   administrative mechanisms to coordinate VPN ID assignment e.g.
   through the notion of a 'home AS' for a particular VPN, which is used
   in the VPN ID of that VPN. A VPN ID coded as proposed could also be
   easily piggybacked in BGP, and could also be easily specified within
   BGP policy filters in AS border routers for scoping and
   administrative purposes.

   In other environments where VPRN functionality is required, but where
   using an AS number is not convenient (because the VPRN functionality
   is being provided on private IP backbone facilities, for example), an
   Organizationally Unique Identifier (OUI), could be used instead of an
   AS number.  This is a 3 octet number, assigned by the IEEE. With the
   addition of a locally assigned 2 octet VPN number this would form a 5
   octet VPN identifier.

   Note that the intent of the VPN ID is that it be used in
   configuration and control messages in order to refer to a particular
   VPN.  There is a also a need to be able to associate a data packet
   received on a tunnel with a particular VPN, however the VPN ID is not
   intended to be used for this purpose, since including an extra 4 or 5
   byte quantity with every data packet transmitted is neither efficient
   or necessary. Instead a tunnel specific multiplexing field is used
   for that purpose. For example an IPSec tunnel uses the SPI field, an
   L2TP tunnel uses the call-id field, and an MPLS tunnel uses the MPLS
   label.

   There is a need for a standard VPN identifier. This could use the OUI
   format described above, or could be a hybrid which allows both an AS
   or an OUI to be used, or perhaps some other method. The ATM Forum
   also have a similar problem to solve, and ideally a single mechanism
   should be used for both cases. For the remainder of this draft it is
   assumed that such a globally unique VPN identifier exists.


6.1.2. VPN Membership Information Configuration and Dissemination

   In order to establish a VPRN, or to insert new customer sites into an
   established VPRN, the stub links on each edge router from those sites
   in the particular VPRN must first be configured with the identity of
   the particular VPRN to which the stub links belong.  Note that this
   first step of stub link configuration is unavoidable, since clearly
   the edge router cannot infer such bindings and hence must be



Gleeson et al.                                                 [Page 17]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   configured with this information. A management information base (MIB)
   allowing for bindings between local stub links and VPN identities is
   one solution.

   Thereafter, each edge router must learn either the identity of, or,
   at least, the route to, each other edge router supporting other stub
   links in that particular VPRN.  Implicit in the latter is the notion
   that there exists some mechanism by which the configured edge routers
   can then use this edge router and/or stub link identity information
   to subsequently set up the appropriate tunnels between them; this is
   discussed further below.

   In order to configure each stub link with the identity of the VPN to
   which it belongs, a VPN identifier is required (see 6.1.1); the scope
   of uniqueness of this identifier is a function of its usage, which is
   related to how VPRN membership is disseminated.  This problem, of
   VPRN member dissemination between participating edge routers, can be
   solved in a variety of ways, discussed below.

   A. Directory Lookup:

   The members of a particular VPRN, that is, at a minimum, the identity
   of the edge routers supporting stub links in the VPRN, and possibly
   also the identity of each of the stub links, could be configured into
   a directory, which edge routers could query, using some defined
   mechanism (e.g. LDAP), upon configuration of their local stub
   interfaces and VPN identifier.

   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
   routers in a VPRN is distributed everywhere. For an arbitrary
   topology, different routers may receive different member lists.

   Using a directory allows for authorization checking prior to
   disseminating VPRN membership information, which may be desirable
   where VPRNs span multiple administrative domains.  In such a case,
   directory to directory protocol mechanisms could also be used to
   propagate authorized VPRN membership information between the
   directory systems of the multiple administrative domains.

   There would also need to be some form of database synchronization
   mechanism (e.g. triggered or regular polling of the directory by edge
   routers, or active pushing of update information to the edge routers
   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
   learn of sites removed from a VPRN.

   B. Explicit Management Configuration:



Gleeson et al.                                                 [Page 18]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   A VPRN Management Information Base (MIB) could be defined which would
   allow a central management system to configure each edge router with
   the identities of each other participating edge router and possibly
   also the identity of each of the stub links.  Similar mechanisms
   could also be used, as noted above, to configure the VPN bindings of
   the local stub links on the edge router. Like the use of a directory,
   this mechanism allows both full mesh and arbitrary topologies to be
   configured.

   Note that this mechanism allows the management station to impose
   strict authorization control; on the other hand, it may be more
   difficult to configure edge routers outside the scope of the
   management system.  The management configuration model can also be
   considered a subset of the directory method, in that the (management)
   directories could use MIBs to push VPRN membership information to the
   participating edge routers, either subsequent to, or as part of, the
   local stub link configuration process.

   C. Piggybacking in Routing Protocols:

   VPRN membership information could be piggybacked into the routing
   protocols run by each edge router across the IP backbone, since this
   is an efficient means of automatically propagating information
   throughout the network to other participating edge routers.
   Specifically, each route advertisement by each edge router could
   include, at the minimum, the set of VPN identifiers associated with
   each edge router, and adequate information to allow other edge
   routers to determine the identity of, and/or, the route to, the
   particular edge router.  Other edge routers would examine received
   route advertisements to determine if any contained information was
   relevant to a supported (i.e. configured) VPRN; this determination
   could be done by looking for a VPN identifier matching a locally
   configured VPN.  The nature of the piggybacked information, and
   related issues, such as scoping, and the means by which the nodes
   advertising particular VPN memberships will be identified, will
   generally be a function both of the routing protocol and of the
   nature of the underlying transport, and is discussed further in
   Appendix A.

   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
   is easily supported. Supporting an arbitrary topology is more
   difficult, however, since some form of pruning would seem to be
   needed.

   The advantage of the piggybacking scheme is that it allows for very
   efficient information dissemination, particularly across multiple
   routing domains (e.g. across different autonomous systems/ISPs) but



Gleeson et al.                                                 [Page 19]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   it does require that all nodes in the path, and not just the
   participating edge routers, be able to accept such modified route
   advertisements. On the other hand, significant administrative
   complexity may be required to configure scoping mechanisms so as to
   both permit and constrain the dissemination of the piggybacked
   advertisements, and in itself this may be quite a configuration
   burden.

   Furthermore, unless some security mechanism is used for routing
   updates so as to permit only all relevant edge routers to read the
   piggybacked advertisements, this scheme generally implies a trust
   model where all routers in the path must perforce be authorized to
   know this information.  Depending upon the nature of the routing
   protocol, piggybacking may also require intermediate routers,
   particularly autonomous system (AS) border routers, to cache such
   advertisements and potentially also re-distribute them between
   multiple routing protocols.

   Each of the schemes described above have merit in particular
   situations. Note that, in practice, there will almost always be some
   directory or management system which will maintain VPRN membership
   information, since, as noted above, the binding of VPRNs to stub
   links must be configured, hence, presumably, such information would
   be obtained from, and stored within, some database.  Hence the
   additional steps to facilitate the configuration of such information
   into edge routers, and/or, facilitate edge router access to such
   information, may not be excessively onerous.


6.1.3 Stub Link Reachability Information

   There are two aspects to stub site reachability - the means by which
   VPRN edge routers determine the set of VPRN addresses and address
   prefixes reachable at each stub site, and the means by which the CPE
   routers learn the destinations reachable via each stub link. A number
   of common scenarios are outlined below. In each case the information
   needed by the ISP edge router is the same - the set of VPRN addresses
   reachable at the customer site, but the information needed by the CPE
   router differs.

   1. 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
   default route pointing to the ISP edge router.

   2. The CPE router is connected via one link to an ISP edge
      router, which provides VPRN, but not Internet, connectivity.



Gleeson et al.                                                 [Page 20]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   The CPE router must know the set of non-local VPRN destinations
   reachable via that link - the VPRN default route. This may be a
   single prefix, or may be a number of disjoint prefixes.  The CPE
   router may be either statically configured with this information, or
   may learn it dynamically by running an instance of an IGP. For
   simplicity it is assumed that the IGP used for this purpose is RIP,
   though it could be any IGP. The ISP edge router will inject into this
   instance of RIP the VPRN default route, which it learns by means of
   one of the intra-VPRN reachability mechanisms described in section
   6.1.4. Note that the instance of RIP run to the CPE, and any instance
   of a routing protocol used to learn intra-VPRN reachability (even if
   also 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
      provides VPRN connectivity.

   In this case all the ISP edge routers could advertise the same VPRN
   default route to the CPE router, which then sees all VPRN prefixes
   equally reachable via all links. More specific route redistribution
   is also possible, whereby each ISP edge router advertises specific
   prefixes (perhaps the ones locally connected) in addition to, or with
   more favoured metrics than, the VPRN default route.

   4. 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 the VPRN default
   route as in case 2. However now the same destination is reachable via
   both the ISP edge router and via the backdoor link. If the CPE
   routers connected to the backdoor link are running the customer's
   IGP, then the backdoor link may always be the favoured 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
   (to the customer's IGP).  To avoid this problem, assuming that the
   customer wants the traffic to traverse the ISP network, then a
   separate instance of  RIP should be run between the CPE routers at
   both ends of the backdoor link, in the same manner as an instance of
   RIP is run on a stub or backup link between a CPE router and an ISP
   edge router. This will then also make the backdoor link appear as an
   external path, and by adjusting the link costs appropriately, the ISP
   path can always be favoured, unless it goes down, when the backdoor
   link is then used.

   The description of the above scenarios covers what reachability
   information is needed by the ISP edge routers and the CPE routers,
   and discusses some of the mechanisms used to convey this information.



Gleeson et al.                                                 [Page 21]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   The sections below look at these mechanisms in more detail.

   A. Routing Protocol Instance:

   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 learn the VPRN prefixes reachable at a customer site,
   and also allows a CPE router to learn the destinations reachable via
   its stub links.

   The extent of the routing domain for this protocol instance is
   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
   domain may extend into customer site. If the customer site is running
   a different routing protocol then the CPE router redistributes the
   routes between the instance running to the ISP edge router, and the
   instance running into the customer site.

   Given the typically restricted scope of this routing instance, a
   simple protocol will generally suffice. RIPv2 [Malkin] is likely to
   be the most common protocol used, though any routing protocol, such
   as OSPF [Moy], or BGP-4 [Rekhter2] run in internal mode (IBGP), could
   also be used.

   Note that the instance of the stub link routing protocol is different
   from any instance of a routing protocol used for intra-VPRN
   reachability. For example, if the ISP edge router uses routing
   protocol piggybacking to disseminate VPRN membership and reachability
   information across the core, then it may redistribute suitably
   labeled routes from the CPE routing instantiation to the core routing
   instantiation. The routing protocols used for each instantiation are
   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
   reachability information gathering mechanism, be run between each CPE
   router and associated ISP edge router in a particular VPRN, since
   this is a purely local matter.

   This decoupling allows ISPs to deploy a common (across all VPRNs)
   intra-VPRN reachability mechanism, and a common stub link
   reachability mechanism, with these mechanisms isolated both from each
   other, and from the particular IGP used in a customer network. In the
   first case, due to the IGP-IGP boundary implemented on the ISP edge
   router, the ISP can insulate the intra-VPRN reachability mechanism
   from misbehaving stub link protocol instances. In the second case the
   ISP is not required to be aware of the particular IGP running in a
   customer site. Other scenarios are possible, where the ISP edge
   routers are running a routing protocol in the same instance as the
   customer's IGP, but are unlikely to be practical, since it defeats



Gleeson et al.                                                 [Page 22]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   the purpose of a VPRN simplifying CPE router configuration.  In cases
   where a customer wishes to run an IGP across multiple sites, a VPLS
   solution is more suitable.

   Note that if a particular customer site concurrently belongs to
   multiple VPRNs (or wishes to concurrently communicate with both a
   VPRN and the Internet), then the ISP edge router must have some means
   of unambiguously mapping stub link address prefixes to particular
   VPRNs. A simple way is to have multiple stub links, one per VPRN. It
   is also possible to run multiple VPRNs over one stub link. This could
   be done either by ensuring (and appropriately configuring the ISP
   edge router to know) that particular disjoint address prefixes are
   mapped into separate VPRNs, or by tagging the routing advertisements
   from the CPE router with the appropriate VPN identifier.  For example
   if MPLS was being used to convey stub link reachability information,
   different MPLS labels would be used to differentiate the disjoint
   prefixes assigned to particular VPRNs. In any case, some
   administrative procedure would be required for this coordination.

   B. Configuration:

   The reachability information across each stub link could be manually
   configured, which may be appropriate if the set of addresses or
   prefixes is small and static.

   C. ISP Administered Addresses:

   The set of addresses used by each stub site could be administered and
   allocated via the VPRN edge router, which may be appropriate for
   small customer sites.  In such a case the ISP edge router could
   determine these addresses by proxying for the particular address
   administration mechanism (e.g. DHCP).  Note that in this case it
   would be the responsibility of the address allocation mechanism to
   ensure that each site in the VPN received a disjoint address space.
   Note also that an ISP would typically only use this mechanism for
   small stub sites, which are unlikely to have backdoor links.


   D. MPLS Label Distribution Protocol:

   In cases where the CPE router runs MPLS, the MPLS LDP could be
   extended to convey the set of prefixes at each stub site, together
   with the appropriate labeling information.  While LDP is not
   generally considered a routing protocol per se, it may be useful to
   extend it for this particular constrained scenario.  This is for
   further study.





Gleeson et al.                                                 [Page 23]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


6.1.4 Intra-VPN Reachability Information

   Once an edge router has determined the set of prefixes associated
   with each of its stub links, then this information must be
   disseminated to each other edge router in the VPRN.  Note also that
   there is an implicit requirement that the set of reachable addresses
   within the VPRN be locally unique that is, each VPRN stub link (not
   performing load sharing) maintain an address space disjoint from any
   other, so as to permit unambiguous routing.  In practical terms, it
   is also generally desirable, though not required, that this address
   space be well partitioned i.e. specific, disjoint address prefixes
   per stub link, so as to preclude the need to maintain and disseminate
   large numbers of host routes.

   The intra-VPN reachability information dissemination can be solved in
   a number of ways, some of which include the following:

   A. Directory Lookup:

   Along with VPRN membership information, a central directory could
   maintain a listing of the address prefixes associated with each end
   point.  Such information could be obtained by the server through
   protocol interactions with each edge router.  Note that the same
   directory synchronization issues discussed above would apply in this
   case.

   B. Explicit Configuration:

   The address spaces associated with each edge router could be
   explicitly configured into each other router. This is clearly a non-
   scalable solution, particularly when arbitrary topologies are used,
   and also raises the question of how the management system learns such
   information in the first place.

   C. Local Intra-VPRN Routing Instantiations:

   In this approach, each edge router runs an instantiation of a routing
   protocol (a 'virtual router') per VPRN, running across the VPRN
   tunnels to each peer edge router, to disseminate intra-VPRN
   reachability information. Both full-mesh and arbitrary VPRN
   topologies can be easily supported, since the routing protocol itself
   can run over any topology.  The intra-VPRN routing advertisements
   could be distinguished from normal tunnel data packets either by
   being addressed directly to the peer edge router, or by a tunnel
   specific mechanism.

   Note that this intra-VPRN routing protocol need have no relationship
   either with the IGP of each customer site or with the routing



Gleeson et al.                                                 [Page 24]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   protocols operated by the ISPs in the IP backbone. Specifically, the
   intra-VPRN routing protocol operates as an overlay over the IP
   backbone, and could be a simple protocol, such as RIPv2 [Malkin], at
   least unless the VPRN spans a very large number of edge routers.
   Since the intra-VPN routing protocol runs as an overlay, it is also
   wholly transparent to any intermediate routers, and to any edge
   routers not within the VPRN.  This also implies that such routing
   information can also remain opaque to such routers, which may be a
   necessary security requirements in some cases.

   If the tunnels over which an intra-VPRN routing protocol runs are
   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
   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
   be included in routing update packets, to allow sets of prefixes to
   be associated with a particular VPN.

   D. Link Reachability Protocol

   Given a full mesh topology, each edge router could run a link
   reachability protocol - for instance, some variation of the MPLS LDP
   - across the tunnel to each peer edge router in the VPRN, carrying
   the VPN ID and the reachability information of each VPRN running
   across the tunnel between the two edge routers. The specification of
   such a protocol would need to include aspects of current routing
   protocols such as hello protocols, and re-transmit timers and/or
   positive acknowledgements.  However, such an approach may reduce the
   processing burden of running routing protocol instantiations 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
   on IBGP. The problem that needs to be solved by a link reachability
   protocol is very similar to that solved by IBGP - conveying address
   prefixes reliably between edge routers.

   Using a link reachability protocol it is straightforward to support a
   full mesh topology - each edge router conveys its own local
   reachability information to all other routers, but does not
   redistribute information received from any other router. However once
   an arbitrary topology needs to be supported, the link reachability
   protocol in effect develops into a full routing protocol, due to the
   need to implement mechanisms to avoid loops, and the issues discussed
   in section 6.1.4C above, apply.

   E. Piggybacking in IP Backbone Routing Protocols:



Gleeson et al.                                                 [Page 25]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   As with VPRN membership, the set of address prefixes associated with
   each stub interface could also be piggybacked into the routing
   advertisements from each edge router and propagated through the
   network.  Other edge routers would extract this information from
   received route advertisements in the same way as they would obtain
   the VPRN membership information (which, in this case, is implicit in
   the identification of the source of each route advertisement). Note
   that this scheme may require, depending upon the nature of the
   routing protocols involved, that intermediate routers, e.g. border
   routers, cache intra-VPRN routing information in order to propagate
   it further.  This also has implications for the trust model, and for
   the level of security possible for intra-VPRN routing information.

   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
   permit tunneling from remote edge routers directly to the egress stub
   links.  Alternatively, it could disseminate the information so as to
   associate all such prefixes with the edge router, rather than with
   specific stub links.  In this case, the edge router would need to
   implement a VPN specific forwarding mechanism for egress traffic, to
   determine the correct egress stub link.  The advantage of this is
   that it may significantly reduce the number of distinct tunnels or
   tunnel label information which need to be constructed and maintained.
   Note that this choice is purely a local manner and is not visible to
   remote edge routers.


6.1.5 Tunneling Mechanisms

   Once VPRN membership information has been disseminated, the tunnels
   comprising the VPRN can be constructed.

   One approach to setting up the tunnel mesh is to use point-to-point
   IP tunnels, and the requirements and issues for such tunnels are
   discussed in section 5.0, on VLLs. For example while tunnel
   establishment can be done through manual configuration, this is
   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
   of signaling protocol which would allow two nodes to construct a
   tunnel to each other knowing only each other's identity.

   Another approach is to use the multipoint to point 'tunnels' provided
   by MPLS.  As noted in [Heinanen1], MPLS can be considered to be a
   form of IP tunneling, since the labels of MPLS packets allow for
   routing decisions to be decoupled from the addressing information of
   the packets themselves. MPLS label distribution mechanisms can be
   used to associate specific sets of MPLS labels with particular VPRN
   address prefixes supported on particular egress points (i.e. stub



Gleeson et al.                                                 [Page 26]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   links of edge routers) and hence allow other edge routers to
   explicitly label and route traffic to particular VPRN stub links.

   One attraction of MPLS as a tunneling mechanism is that it may

   require less processing within each edge router than alternative
   tunneling mechanisms.  This is a function of the fact that data
   security within a MPLS network is implicit in the explicit label
   binding, much as with a connection oriented network, such as Frame
   Relay.  This may hence lessen customer concerns about data security
   and hence require less processor intensive security mechanisms (e.g.
   IPSec).  However there are other potential security concerns with
   MPLS. There is no direct support for security features such as
   authentication, confidentiality, and non-repudiation and the trust
   model for MPLS means that intermediate routers, (which may belong to
   different administrative domains), through which membership and
   prefix reachability information is conveyed, must be trusted, not
   just the edge routers themselves.


6.2  Multihomed Stub Routers

   The discussion thus far has implicitly assumed that stub routers are
   connected to one and only one VPRN edge router. In general, this
   restriction should be capable of being relaxed without any change to
   VPRN operation, given general market interest in multihoming for
   reliability and other reasons.  In particular, in cases where the
   stub router supports multiple redundant links, with only one
   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,
   then the stub link reachability mechanisms will both discover the
   loss of an active link, and the activation of a backup link. In the
   former situation, the previously connected VPRN edge router will
   cease advertising reachability to the stub node, while the VPRN edge
   router with the now active link will begin advertising reachability,
   hence restoring connectivity.

   An alternative scenario is where the stub node supports multiple
   active links, using some form of load sharing algorithm.  In such a
   case, multiple VPRN edge routers may have active paths to the stub
   node, and may so advertise across the VPRN.  This scenario should not
   cause any problem with reachability across the VPRN providing that
   the intra-VPRN reachability mechanism can accommodate multiple paths
   to the same prefix, and has the appropriate mechanisms to preclude
   looping - for instance, distance vector metrics associated with each
   advertised prefixes.  This subject is for further study.






Gleeson et al.                                                 [Page 27]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


6.3 Multicast Support

   Multicast and broadcast traffic can be supported across VPRN either
   by edge replication or by native multicast support in the backbone.
   These two cases are discussed below.

6.3.1  Edge Replication

   This is where each VPRN edge router replicates multicast traffic for
   transmission across each link in the VPRN. Note that this is the same
   operation that would be performed by CPE routers terminating actual
   physical links or dedicated connections.  As with CPE routers,
   multicast routing protocols could also be run on each VPRN edge
   router to determine the distribution tree for multicast traffic and
   hence reduce unnecessary flood traffic. This could be done by running
   an instantiation of standard multicast routing protocols, e.g.
   Protocol Independent Multicast (PIM) [Estrin] or the Distance Vector
   Multicast Routing Protocol (DVMRP) [Waitzman], on and between each
   VPRN edge router, through the VPRN tunnels, in the same way that
   unicast routing protocols might be run at each VPRN edge router to
   determine intra-VPN unicast reachability, as discussed in Section
   6.1.4. Alternatively, if a link reachability protocol was run across
   the VPRN tunnels for intra-VPRN reachability, then this could also be
   augmented to allow VPRN edge routers to indicate both the particular
   multicast groups requested for reception at each edge node, and also
   the multicast sources at each edge site.

   In either case, there would need to be some mechanism to allow for
   the VPRN edge routers to determine which particular multicast groups
   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
   capabilities of the CPE stub routers at each site. If these could
   also run multicast routing protocols, then these could interact
   directly with the equivalent protocols at each VPRN edge router, else
   they could forward the Internet Group Management Protocol (IGMP)
   [Fenner] packets to the VPRN edge router for appropriate processing.

6.3.2  Native Multicast Support

   This is where VPRN edge routers map intra-VPN multicast traffic onto
   a native IP multicast distribution mechanism across the backbone.
   Note that the latter is not synonymous with the use of native
   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
   traffic. Currently the only IP tunneling mechanism that has native
   support for multicast is MPLS.  On the other hand, while MPLS
   supports native transport of IP multicast packets, additional



Gleeson et al.                                                 [Page 28]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   mechanisms would be needed to leverage these mechanisms for the
   support of intra-VPN multicast.

   For instance, each VPRN router could prefix multicast group addresses
   within each VPRN with the VPN ID of that VPRN and then redistribute
   these, essentially treating this VPN ID/intra-VPRN multicast address
   tuple as a normal multicast address, within the backbone multicast
   routing protocols, as with the case of unicast reachability, as
   discussed previously.  The MPLS multicast label distribution
   mechanisms could then be used to set up the appropriate multicast
   LSPs to interconnect those sites within each VPRN supporting
   particular multicast group addresses.  Note, however, that this would
   require each of the intermediate LSRs to not only be aware of each
   intra-VPRN multicast group, but also to have the capability of
   interpreting these modified advertisements.  Alternatively,
   mechanisms could be defined to map intra-VPRN multicast groups into
   backbone multicast groups. The details of such mechanisms are for
   further study.

   Other IP tunneling mechanisms do not have native multicast support.
   It may prove feasible to extend such tunneling mechanisms by
   allocating IP multicast group addresses to the VPRN as a whole and
   hence distributing intra-VPRN multicast traffic encapsulated within
   backbone multicast packets. Edge VPRN routers could filter out
   unwanted multicast groups. Alternatively, mechanisms could also be
   defined to allow for allocation of backbone multicast group addresses
   for particular intra-VPRN multicast groups, and to then utilize
   these, through backbone multicast protocols, as discussed above, to
   limit forwarding of intra-VPRN multicast traffic only to those nodes
   within the group. The details of such mechanisms are for further
   study.

   A particular issue with the use of native multicast support is the
   provision of security for such multicast traffic. Unlike the case of
   edge replication, which inherits the security characteristics of the
   underlying tunnel, native multicast mechanisms will need to use some
   form of secure multicast mechanism. At present, most aspects of such
   mechanisms, for instance using IPSec, are not wholly specified
   [Wallner] and further study will likely be needed before secure
   native multicast mechanisms can be generally deployed.


6.4 Specification Recommendations

   There have already been proposals for adapting routing protocols to
   carry VPN information to support the router piggybacking mechanisms
   [Heinanen1], particularly in MPLS networks. Some ISPs, however, may
   prefer schemes that do not couple VPN membership and reachability



Gleeson et al.                                                 [Page 29]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   mechanisms with the backbone routing protocols, hence a set of
   mechanisms that do not require piggybacking should also be
   standardized. In particular the following are needed

   - a standard format for a globally unique VPN identifier.

   - a membership distribution protocol based on a directory or MIB.

   Also for the constrained case of a full mesh topology, the usefulness
   of developing a link reachability protocol could be examined.
   Extending routing protocols to allow a VPN-ID to carried in routing
   update packets could also be examined, but is not necessary if VPN
   specific tunnels are used.

   Note also that the MPLS WG group is working on MPLS-specific
   mechanisms for VPRNs [Heinanen2].


7.0 VPN Types:  Virtual Private Dial Networks

   A virtual private dial network (VPDN) allows for remote users to
   connect on demand into remote sites through ad hoc tunnels.  The
   distinguishing characteristic of such ad hoc connections is their
   binding between a particular user and a central site.  As such, user
   authentication, through whatever means, is a prime requirement.

   Most such connections are made today through dial connections made
   through the PSTN, with users setting up PPP connections across an
   access network to a Network Access Server (NAS), at which point the
   PPP sessions are authenticated using AAAA systems running such
   standard protocols as RADIUS [Rigney].  Given the pervasive
   deployment of such systems, any VPDN system must practically allow
   for the near transparent re-use of such existing systems.

   There has been significant work completed on the Layer 2 Tunneling
   Protocol (L2TP) [Valencia1], building upon the earlier PPTP [Zorn]
   and L2F [Valencia2] protocols.  L2TP allows for the extension of user
   PPP sessions from a L2TP access concentrator (LAC) to a remote L2TP
   network server (LNS). Notwithstanding, however, the widespread
   industry support for L2TP, there are two quite different VPDN
   scenarios, which may call for different solutions.


7.1 Compulsory Tunneling

   Compulsory tunneling refers to a case in which a network node - 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.



Gleeson et al.                                                 [Page 30]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   This operation is transparent to the user initiating the PPP session
   to the LAC.  Support of this scenario was the original intent of the
   L2F specification, upon which the L2TP specification was based.

   Compulsory tunneling was originally intended for deployment on dial
   access servers supporting VPDN or wholesale dial services, allowing
   for remote dial access through common facilities to an enterprise
   site, while precluding the need for the enterprise to deploy its own
   dial servers.  More recently, compulsory tunneling mechanisms have
   also been proposed for evolving xDSL services [ADSL1], [ADSL2], which
   also seek to leverage the existing AAAA infrastructure.


7.1.1 Call Routing

   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
   identity of the LNS.  As noted in [Aboba1], these aspects can include
   the user identity, as determined through some aspect of the access
   network, including calling party number, or some attribute of the
   called party, such as the fully qualified domain name (FQDN) of the
   CHAP/PAP user name.

7.1.2 Security Mechanisms

   By allowing for the transparent extension of PPP from the user,
   through the LAC to the LNS, L2TP allows for the use of whatever
   security mechanisms, with respect to both connection set up, and data
   transfer, may be used with normal PPP connections. However this does
   not provide security for the L2TP control protocol itself. In this
   case L2TP could be further secured by running it over IPSec through
   IP backbones [Patel], or related mechanisms on non-IP backbones
   [Calhoun2].

   The interaction of L2TP with AAAA systems for user authentication and
   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.
   These issues are discussed in depth in [Aboba1].

   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
   tunnel, and the LNS parameters associated with each user, are outside
   the scope of the operation of VPDN, but may be addressed, by for
   instance, evolving Internet roaming specifications [Aboba2].







Gleeson et al.                                                 [Page 31]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


7.1.3 Traffic Management

   L2TP support a complex flow control scheme that can be requested by
   either party in order to minimize packet loss due to receiver
   congestion. Furthermore, L2TP, by transparently extending PPP, has
   inherent support for such PPP mechanisms as multi-link PPP [Sklower]
   and its associated control protocols [Richard], which allow for
   bandwidth on demand to meet user requirements.  Beyond these
   capabilities, L2TP itself does not have any specific traffic
   management mechanisms.  As noted also for VLLs, however, L2TP calls
   could be mapped into whatever underlying traffic management
   mechanisms may exist in the network, and there are proposals to allow
   for requests through L2TP signaling for specific differentiated
   services behaviors [Calhoun1].

7.1.4 Call Multiplexing

   L2TP has inherent support for the multiplexing of multiple calls from
   different users over a single link.  Between the same two IP
   endpoints, there can be multiple L2TP tunnels, as identified by a
   tunnel-id, and multiple calls within a tunnel, as identified by a
   call-id.

7.1.5 Address Management

   Since L2TP is designed to transparently extend PPP, it does not
   attempt to supplant the normal address assignment mechanisms
   associated with PPP. Hence, in general terms the host initiating the
   PPP session will be assigned addressing by the LNS using PPP
   procedures.  This addressing may have no relation to the addressing
   used for communication between the LAC and LNS. The LNS will also
   need to support whatever forwarding mechanisms are needed to route
   traffic to and from the remote host.

7.1.6 Support for Large MTUs

   As with VLLs, it cannot be assumed that the MTU of the VPDN tunnel is
   necessarily less than or equal to that of the underling IP route,
   though the host may adjust the PPP payload MTU to preclude
   fragmentation. To this end, there are proposals to allow the use of
   MTU discovery for cases where the L2TP tunnel transports IP frames
   [Shea].


7.2 Voluntary Tunnels

   A voluntary tunneling refers to cases where an individual host
   connects to a remote site using a tunnel originating on the host,



Gleeson et al.                                                 [Page 32]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   with no involvement from intermediate network nodes.  The PPTP
   specification, parts of which have been incorporated into L2TP, was
   based upon a voluntary tunneling model.

   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.

   There has also been discussion, however, that PPP, and hence either
   L2TP or PPTP, may be unnecessary and excessively burdensome for
   voluntary tunnels, particularly when they need to be paired with
   IPSec for security purposes. It is proposed in [Gupta] that IPSec
   alone be used for voluntary tunnels, with the tunnels terminating on
   IPSec edge devices at the enterprise site. In this case IPSec will be
   used in tunnel mode, and the host will have two IP addresses, in a
   similar manner to the L2TP case. (Alternatively the host could use
   one IP address as the source IP address in both the inner and outer
   IP headers, with the gateway performing NAT before forwarding the
   inner header, after IPSec processing).  The IPSec WG is currently
   examining this area, with the intent of developing authentication
   schemes tailored towards remote hosts, and to allow certain
   configuration parameters, such as the host's IP address and DNS
   server, to be configured via IKE.

   Using IPSec as the basis of a voluntary tunnel mechanism may yield a
   much lower overhead solution than the use of PPP and L2TP, but it
   does require either changes to host protocol stacks, or the use of
   host 'shims' to intercept and forward packets to VPDNs through IPSec.
   A number of proprietary solutions of the latter sort are currently
   commercially available, hence a standard mechanism may well be
   desirable.


7.3 Networked Host Support

   The current PPP based dial model assumes a host directly connected to
   a connection oriented dial access network.  Recent work on new access
   technologies such a xDSL have attempted to replicate this model
   [ADSL], so as to allow for the re-use of existing AAAA systems. The
   proliferation of personal computers, printers and other network
   appliances in homes and small businesses, and the ever lowering costs
   of networks, however, are increasingly challenging the directly
   connected host model.  Increasingly, most hosts will access the
   Internet through small, typically Ethernet, local area networks
   (LANs).




Gleeson et al.                                                 [Page 33]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   There is hence interest in means of accommodating the existing AAAA
   infrastructure within service providers, whilst also supporting
   multiple networked hosts at each customer site.  The principal
   complication with this scenario is the need to support the login
   dialogue, through which the appropriate AAAA information is
   exchanged.  A number of proposals have been made to address this
   scenario:

   A. Extension of PPP to Hosts Through L2TP:

   A number of proposals (e.g. [ADSL1]) have been made to extend L2TP
   over Ethernet so that PPP sessions can run from networked hosts out
   to the network, in much the same manner as a directly attached host.

   B. Extension of PPP Directly to Hosts:

   There are also proposals to map PPP directly onto Ethernet ([Evarts],
   [Shieh1], [Shieh2]), and to use a broadcast mechanism to allow hosts
   to find appropriate access servers with which to connect. Presumably
   such servers could then further tunnel, if needed, the PPP sessions
   using L2TP or similar mechanism.

   C. Use of IPSec:

   The IPSec based voluntary tunneling mechanism discussed above is
   independent of either access method or PPP and hence could as easily
   be used with networked or directly connected hosts.

   All of these methods require either host protocol changes, but the
   former two do allow the continued use of the various ancillary
   mechanisms of PPP, including address allocation, autoconfiguration,
   etc, albeit at the cost of greater overhead.


7.4  Specification Recommendations

   The L2TP specifications are currently near finalization and hence are
   the clear choice for VPDNs using compulsory tunneling.  Further study
   needs to be done, however, to determine the most appropriate solution
   for voluntary tunneling. On approach is a PPP based solution, running
   over L2TP or some other form of link emulation protocol for the
   networked host scenario. Another approach is an IPSec based
   mechanism, with extensions to IKE for necessary host configuration.
   In the latter case, it may be desirable to maximize commonality with
   any IPSec based VLL tunneling mechanism.






Gleeson et al.                                                 [Page 34]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


8.0 VPN Types:  Virtual Private LAN Segment


   8.0  VPN Types:  Virtual Private LAN Segment

   A virtual private LAN segment (VPLS) is the emulation of a LAN
   segment using Internet facilities. A VPLS can be used to provide what
   is sometimes known also as a transparent LAN service (TLS), which can
   be used to interconnect multiple stub CPE nodes, either bridges or
   routers, in a protocol transparent manner. A VPLS emulates a LAN
   segment over IP, in the same way as protocols such as LANE [ATMF1]
   emulate a LAN segment over ATM.  The primary benefits of a VPLS are
   complete protocol transparency, which may be important both for
   multiprotocol transport and for regulatory reasons in particular
   service provider contexts.

   8.1 VPLS Requirements

   Topologically and operationally a VPLS can be most easily modelled as
   being essentially equivalent to a VPRN, except that each VPLS edge
   node implements link layer bridging rather than network layer
   forwarding. As such, most of the VPRN tunneling and configuration
   mechanisms discussed previously can also be used for a VPLS, with the
   appropriate changes to accommodate link layer, rather than network
   layer, packets and addressing information.  The following sections
   discuss the primary changes needed in VPRN operation to support
   VPLSs.

   8.1.1 Tunneling Protocols

   The tunneling protocols employed within a VPLS could be exactly the
   same as those used within a VPRN, if the tunneling protocol permitted
   the transport of multiprotocol traffic.  Since the primary tunneling
   protocols discussed thus far have this capability, this will be
   assumed below.

   8.1.2 Multicast and Broadcast Support

   A VPLS needs to have a broadcast capability. This is needed both for
   broadcast frames, and for link layer packet flooding, where a unicast
   frame is flooded because the path to the destination link layer
   address is unknown. The address resolution protocols that run over a
   bridged network typically use broadcast frames (e.g. ARP). The same
   set of possible multicast tunneling mechanisms discussed earlier for
   VPRNs apply also to a VPLS, though the generally more frequent use of
   broadcast in VPLSs may increase the pressure for native multicast
   support that reduces, for instance, the burden of replication on VPLS
   edge nodes.



Gleeson et al.                                                 [Page 35]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   8.1.3 VPLS Membership Configuration and Topology

   The configuration of VPLS membership is analogous to that of VPRNs
   since this generally requires only knowledge of the local VPN link
   assignments at any given VPLS edge node, and the identity of, or
   route to, the other edge nodes in the VPLS; in particular, such
   configuration is independent of the nature of the forwarding at each
   VPN edge node.  As such, any of the mechanisms for VPN member
   configuration and dissemination discussed for VPRN configuration can
   also be applied to VPLS configuration. Also as with VPRNs, the
   topology of the VPLS could be easily manipulated by controlling the
   configuration of peer nodes at each VPLS edge node, assuming that the
   membership dissemination mechanism was such as to permit this. It is
   likely that typical VPLSs will be fully meshed, however, in order to
   preclude the need for traffic between two VPLS nodes to transit
   through another VPLS node, which would then require the use of the
   spanning tree protocol [IEEE] for loop prevention.

   8.1.4 CPE Stub Node Types

   Unlike a VPLS in which the CPE nodes are assumed to be routers, a
   VPLS can support either bridges or routers as a CPE device.

   CPE routers would peer transparently across a VPLS with each other
   without requiring any router peering with any nodes within the VPLS.
   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
   routers is potentially greater, since the ISP edge device is no
   longer acting as an aggregation point.

   With CPE bridge devices the broadcast domain encompasses all the CPE
   sites as well as the VPLS itself. There are severe scalability
   constraints in this case, due to the need for packet flooding, and
   the fact that any topology change in the bridged domain is not
   localized, but is visible throughout the domain. As such this
   scenario is generally only suited for non-routable protocols.

   The nature of the CPE impacts the nature of the encapsulation,
   addressing, forwarding and reachability protocols within the VPLS,
   and are discussed separately below.

   8.1.5 Stub Link Packet Encapsulation

   A. Bridge CPE:

   In this case, packets sent to and from the VPLS across stub links are
   link layer frames, with a suitable access link encapsulation. The
   most common case is likely to be ethernet frames, using an



Gleeson et al.                                                 [Page 36]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   encapsulation appropriate to the particular access technology, 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.
   As noted previously, this does mandate the use of an IP tunneling
   protocol which can transport such link layer frames. Note that this
   does not necessarily mandate, however, the use of a protocol
   identification field in each tunnel packet, since the nature of the
   encapsulated traffic (e.g. ethernet frames) could be indicated at
   tunnel setup.

   B. Router CPE:

   In this case, typically, CPE routers send link layer packets to and
   from the VPLS across stub links, destined to the link layer addresses
   of their peer CPE routers. Other types of encapsulations may also
   prove feasible in such a case, however, since the relatively
   constrained addressing space needed for a VPLS to which only router
   CPE are connected, could allow for alternative encapsulations, as
   discussed further below.

   8.1.6  CPE Addressing and Address Resolution

   A. Bridge CPE:

   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
   network layer subnet.  (Multinetting, whereby multiple subnets
   operate over the same LAN segment, is possible, but much less
   common).  Frames are forwarded across and within the VPLS based upon
   the link layer addresses - e.g. IEEE MAC addresses - associated with
   the individual hosts. The VPLS needs to support broadcast traffic,
   such as that typically used for the address resolution mechanism used
   to map the host network addresses to their respective link addresses.
   The VPLS forwarding and reachability algorithms also need to be able
   to accommodate flooded traffic.

   B. Router CPE:

   A single network layer subnet is generally used to interconnect
   router CPE devices, across a VPLS. Behind each CPE router are hosts
   in different network layer subnets. CPE routers transfer packets
   across the VPLS by mapping next hop network layer addresses to the
   link layer addresses of a router peer. A link layer encapsulation is
   used, most commonly ethernet, as for the bridge case.

   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
   the constrained addressing space of the VPLS, to use encapsulations



Gleeson et al.                                                 [Page 37]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   that use a different address space than normal MAC addressing. See,
   for instance, [Jamieson], for a proposed mechanism for VPLSs over
   MPLS networks, leveraging earlier work on VPRN support over MPLS
   [Heinanen1], which proposes MPLS as the tunneling mechanism, and
   locally assigned MPLS labels as the link layer addressing scheme to
   identify the CPE LSR routers connected to the VPLS.

   8.1.7  VPLS Edge Node Forwarding and Reachability Mechanisms

   A. Bridge CPE:

   The only practical VPLS edge node forwarding mechanism in this case
   is likely to be standard link layer packet flooding and MAC address
   learning, as per [IEEE]. As such, no explicit intra-VPLS reachability
   protocol will be needed, though there will be a need for broadcast
   mechanisms to flood traffic, as discussed above. In general, it may
   not prove necessary to also implement the spanning tree protocol
   [IEEE] between VPLS edge nodes, if the VPLS topology is such that no
   VPLS edge node is used for transit traffic between any other VPLS
   edge nodes - in other words, where there is both full mesh
   connectivity and transit is explicitly precluded. On the other hand,
   the CPE bridges may well implement the spanning tree protocol in
   order to safeguard against 'backdoor' paths that bypass connectivity
   through the VPLS.

   B. Router CPE:

   Standard bridging techniques can also be used in this case. In
   addition, the smaller link layer address address space of such a VPLS
   may also permit other techniques, with explicit link layer routes
   between CPE routers. [Jamieson], for instance, proposes that MPLS
   LSPs be set up, at the insertion of any new CPE router into the VPLS,
   between all CPE LSRs. This then precludes the need for packet
   flooding. In the more general case, if stub link reachability
   mechanisms were used to configure VPLS edge nodes with the link layer
   addresses of the CPE routers connected to them, then modifications of
   any of the intra-VPN reachability mechanisms discussed for VPRNs
   could be used to propagate this information to each other VPLS edge
   node. This would then allow for packet forwarding across the VPLS
   without flooding.

   Mechanisms could also be developed to further propagate the link
   layer addresses of peer CPE routers and their corresponding network
   layer addresses across the stub links to the CPE routers, where such
   information could be inserted into the CPE router's address
   resolution tables. This would then also preclude the need for
   broadcast address resolution protocols across the VPLS.




Gleeson et al.                                                 [Page 38]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   Clearly there would be no need for the support of spanning tree
   protocols if explicit link layer routes were determined across the
   VPLS. If normal flooding mechanisms were used then spanning tree
   would only be required again only if full mesh connectivity was not
   available and hence VPLS nodes had to carry transit traffic.


   8.2 Specification Recommendations

   There is significant commonality between VPRNs and VPLSs, and, where
   possible, this similarity should be exploited in order to reduce
   development and configuration complexity. In particular, VPLSs should
   utilize the same tunneling and membership configuration mechanisms,
   with changes only to reflect the specific characteristics of VPLSs.
   Since one of the primary advantages of VPLSs is protocol
   transparency, it is likely that any general VPLS specification will
   need to support bridge CPE. As such, development of VPLS
   encapsulation, forwarding and reachability protocol mechanisms should
   prioritize support of bridge CPE through the support of ethernet
   encapsulations and standard link layer flooding and address learning
   mechanisms.

   As with VPRNs, there may be a need for specific mechanisms (e.g.
   [Jamieson]) for MPLS networks, and more generic mechanisms for non-
   MPLS networks.


9.0  Summary of Recommendations

   In this Draft different types of VPNs have been discussed
   individually, but there are many common requirements and mechanisms
   that apply to all types of VPNs, and many networks will contain a mix
   of different types of VPNs. It is useful to have as much commonality
   as possible across these different VPN types. In particular, by
   standardizing a relatively small number of mechanisms, it is possible
   to allow a wide variety of VPNs to be implemented. To this end
   serious consideration should be given to standardization efforts in
   the following areas

   - defining a generic VPN tunneling protocol (section 5.1)

   - defining a globally unique VPN identifier (section 6.1.1)

   - defining a VPN membership information configuration and
   dissemination mechanism, that uses some form of directory or MIB
   (section 6.1.2 A,B)

   Also the usefulness of defining a VPN link reachability protocol for



Gleeson et al.                                                 [Page 39]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   the constrained case of a full mesh topology (section 6.1.4 D), could
   be examined.

   This is in addition to the work being done on MPLS-specific
   mechanisms in the MPLS WG.


10.0 Security considerations

   Security considerations are an integral part of any VPN mechanisms,
   and these are discussed in the sections describing those mechanisms.


11.0  Acknowledgements

   Thanks to Anthony Alles, of Shasta Networks, for his invaluable
   assistance in the generation of this Draft, and to Joel Halpern, of
   Newbridge Networks, for his helpful review comments.


12.0  References

   [Aboba1] Aboba, B. and Zorn, G. - "Implementation of PPTP/L2TP
   Compulsory Tunneling via RADIUS", draft-ietf-radius-tunnel-imp-
   03.txt.

   [Aboba2] Aboba, B. and Zorn, G. - "Requirements for Internet
   Roaming", draft- ietf-roamops-roamreq-10.txt.

   [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-00.txt.

   [Calhoun1] Calhoun, P. and Peirce, K. - "Layer Two Tunneling Protocol
   "L2TP" IP Differential Services Extension", draft-ietf-pppext-l2tp-



Gleeson et al.                                                 [Page 40]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   ds-02.txt.

   [Calhoun2] Calhoun, P., et al - "Layer Two Tunneling Protocol "L2TP"
   Security Extensions for Non-IP networks", draft-ietf-pppext-l2tp-
   sec-04.txt.

   [Calhoun3] Calhoun, P. et al - "Tunnel Establishment Protocol",
   draft-ietf-mobileip-calhoun-tep-01.txt.

   [Callon] Callon, R., et al  "Multiprotocol Label Switching
   Architecture", draft-ietf-mpls-arch-02.txt.

   [Chandra] Chandra, R. and Traina, P.  "BGP Communities Attribute",
   RFC 1998.

   [Coltun] Coltun, R.  "The OSPF Opaque LSA Option", RFC 2370.

   [Davie] Davie, B., et al - "Use of Label Switching with RSVP",
   draft-ietf-mpls-rsvp-00.txt

   [Estrin] Estrin, D., et al - "Protocol Independent Multicast-Sparse
   Mode (PIM-SM) Protocol Specification", RFC 2362.

   [Evarts]  Evarts, J., et al - "PPP Over Ethernet "PPPOE"", draft-
   carrel-info- pppoe-00.txt.

   [Fenner] Fenner, W. - "Internet Group Management Protocol, Version
   2", RFC 2236.

   [Ferguson]  Ferguson, P. and Huston, G. - "What is a VPN?", Revision,
   April 1 1998; http://www.employees.org:80/~ferguson/vpn.pdf.

   [Gupta] Gupta, V. - "Secure, Remote Access over the Internet using
   IPSec", draft-gupta-ipsec-remote-access-00.txt.

   [Hanks]  Hanks, S., et al  "Generic Routing Encapsulation over Ipv4
   Networks", RFC 1702.

   [Harkins]  Harkins, D. and Carrel, D.  "The Internet Key Exchange
   (IKE)", draft-ietf-ipsec-isakmp-oakley-08.txt.

   [Heinanen1]  Heinanen, J. and Rosen, E.  "VPN Support with MPLS"
   draft-heinanen-mpls-vpn-01.txt.

   [Heinanen2]  Heinanen, J., et al - "MPLS Mappings of Generic VPN
   Mechanisms", draft-heinanen-generic-vpn-mpls-00.txt.

   [IEEE]  ANSI/IEEE - 10038: 1993 (ISO/IEC) Information technology --



Gleeson et al.                                                 [Page 41]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   Telecommunications and information exchange between systems -- Local
   area networks -- Media access control (MAC) bridges, ANSI/IEEE Std
   802.1D, 1993 Edition.

   [Jamieson] Jamieson, D., et al - "MPLS VPN Architecture", draft-
   jamieson-mpls-vpn-00.txt.

   [Kent]  Kent, S. and Atkinson, R.  "Security Architecture for the
   Internet Protocol", draft-ietf-ipsec-arch-sec-06.txt.

   [Li]  Li, T. and Rekhter, Y. - "Provider Architecture for
   Differentiated Services and Traffic Engineering (PASTE)", draft-li-
   paste-00.txt.

   [Malkin] Malkin, G.  "RIP Version 2  Carrying Additional
   Information", RFC 1723.

   [Moy] Moy, J.  "OSPF Version 2", RFC 2328.

   [Patel]  Patel, B. and Aboba, B. - "Securing L2TP using IPSEC",
   draft-ietf- pppext-l2tp-security-02.txt.

   [Rekhter1]  Rekhter, Y., et al  "Address Allocation for Private
   Internets", RFC 1918.

   [Rekhter2] Rekhter, Y. and Li, T.  "A Border Gateway Protocol 4
   (BGP-4)", RFC 1771.

   [Rekhter3] Rekhter, Y. and Rosen, E.  "Carrying Label Information in
   BGP-4", draft-ietf-mpls-bgp4-mpls-00.txt.

   [Rigney]  Rigney, C., et al - "Remote Authentication Dial In User
   Service (RADIUS)", RFC 2138.

   [Richard] Richard, C. and Smith, K. - "The PPP Bandwidth Allocation
   Protocol (BAP), The PPP Bandwidth Allocation Control Protocol (BACP)"
   RFC 2125.

   [Valencia1]  Valencia, A., et al - "Layer Two Tunneling Protocol
   'L2TP'", draft-ietf-pppext-l2tp-11.txt.

   [Shacham] Shacham, A., et al - "IP Payload Compression Protocol
   (IPComp)", draft-ietf-ippcp-protocol-06.txt.

   [Shea] Shea, R. - "L2TP-over-IP Path MTU Discovery (''L2TPMTU'')",
   draft- ietf-pppext-l2tpmtu-00.txt.

   [Shieh1] Shieh, P et al. "The Architecture for Extending PPP



Gleeson et al.                                                 [Page 42]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   Connections for Home Network Clients", ADSL Forum contribution 98-
   140.

   [Shieh2] Shieh, P et al. "The Requirement and Comparisons of
   Extending PPP over Ethernet", ADSL Forum contribution 98-141.

   [Simpson] Simpson, W.  "IP in IP Tunneling", RFC 1853.

   [Sklower] Sklower, K., et al - "The PPP Multilink Protocol (MP)", RFC
   1990.

   [Srisuresh] Srisuresh, P. and Holdrege, M. - "IP Network Address
   Translator (NAT) Terminology and Considerations", draft-ietf-nat-
   terminology-00.txt.

   [Thomas] Thomas, B., et al - "LDP Specification", draft-ietf-mpls-
   ldp-01.txt.

   [Valencia2] Valencia, A., et al  "Cisco Layer Two Forwarding
   (Protocol) "L2F"", RFC 2341.

   [Waitzman] Waitzman, D., et al - "Distance Vector Multicast Routing
   Protocol", RFC 1075.

   [Wallne] Wallner, D., et al - "Key Management for Multicast: Issues
   and Architectures", draft-wallner-key-arch-01.txt.

   [Zorn] Zorn, G., et al - "Point-to-Point Tunneling Protocol--PPTP",
   draft- ietf-pppext-pptp-04.txt.


   13.0  Author Information


        Bryan Gleeson
        Shasta Networks
        249 Humboldt Court
        Sunnyvale CA 94089-1300
        USA
        Tel: +1 (408) 548 3711
        Email: bgleeson@shastanets.com

        Juha Heinanen
        Telia Finland, Inc.
        Myyrmaentie 2
        01600 VANTAA
        Finland
        Tel: +358 303 944 808



Gleeson et al.                                                 [Page 43]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


        Email: jh@telia.fi

        Arthur Lin
        Shasta Networks
        249 Humboldt Court
        Sunnyvale CA 94089-1300
        USA
        Tel: +1 (408) 548 3788
        Email: alin@shastanets.com

        Grenville Armitage
        Bell Labs, Lucent Technologies
        101 Crawfords Corner Rd
        Holmdel, NJ 07733-3030
        USA
        Email: gja@lucent.com


14.0  Full Copyright Statement

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

   This document and translations of it may be copied and furnished to others,
   and derivative works that comment on or otherwise explain it or assist in its
   implementation may be prepared, copied, published and distributed, in whole
   or in part, without restriction of any kind, provided that the above
   copyright notice and this paragraph are included on all such copies and
   derivative works.  However, this document itself may not be modified in any
   way, such as by removing the copyright notice or references to the Internet
   Society or other Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for copyrights
   defined in the Internet Standards process must be followed, or as required to
   translate it into languages other than English.

   The limited permissions granted above are perpetual and will not be revoked
   by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an "AS IS"
   basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
   DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
   ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
   RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
   PARTICULAR PURPOSE.








Gleeson et al.                                                 [Page 44]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


Appendix A: Routing Protocol Piggybacking

   As noted above, routing protocol piggybacking could be used to carry VPN
   membership information alone, or also VPN reachability information.  The
   means by which this is done, and the nature of the piggyback information, is
   a function both of the particular routing protocol, and of the underlying
   network mechanism.  The particular cases of OSPF and BGP-4 are discussed
   below.


6.2.1 OSPF

   OSPF is often used as an intra-AS routing protocol, and hence may be a
   required candidate for routing protocol piggybacking.  One means by which VPN
   membership and reachability information could be piggybacked is through the
   use of the proposed OSPF opaque LSA [Coltun].  The exact details of how such
   a piggybacking advertisement might be coded are for further study.  In
   particular, it may prove to be the case that opaque LSAs could be well suited
   for piggybacking VPN membership information, but not VPN reachability
   information, since opaque LSAs, at least as currently defined, are attributes
   of, not indexes into, reachability information. Using them in the latter
   manner, which would be required to piggyback VPN reachability information,
   may break some existing OSPF implementations. Opaque LSAs do, however, have a
   well defined scoping mechanism, that, at least within an AS, allows for
   control over the extent of dissemination of a VPN advertisement.

   Note also that as a link state protocol OSPF advertisements always allow for
   the identification of the source of an advertisement.  However, each router
   in the OSPF network, and not only edge routers, will also need to examine
   received advertisements, and explicitly ignore piggybacked VPN
   advertisements, unless configured to be a VPN terminator (i.e. edge router).


6.2.2 BGP-4

   There are a number of potential mechanisms by which VPN information could be
   piggybacked into BGP-4, including the Multiprotocol Extensions attribute
   [Bates] or the BGP communities attribute.  In the case where VPN reachability
   information is piggybacked, each VPN address prefix could be encoded as
   Network Layer Reachability Information (NLRI) and bound to the VPN identifier
   as a community attribute, if the VPN ID has the format proposed previously.
   Note that in cases where it was desired only to advertise VPN membership
   information, then advertising each VPN prefix may be onerous and undesirable,
   but there is no specific mechanism in BGP-4, as yet, to advertise anything
   other than NLRI.

   In the case where this is done on an MPLS network, then the advertisement
   would carry each VPN prefix, together with the MPLS label(s) to be used to



Gleeson et al.                                                 [Page 45]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   send packets to that stub link.  As noted above, these labels, as a purely
   local matter, could identify either the route to each stub link, or only to
   the edge router itself, which would then use its own forwarding mechanisms
   for egress packets.  Since there is already defined a particular mechanism
   for carrying MPLS labels in BGP-4 using the Multiprotocol Extensions field
   [Rekhter3], this would suggest that this mechanism should be generalized for
   the purpose also of conveying VPN information; hence it is proposed that that
   Draft be amended for this purpose.

   The use of BGP-4 for VPN piggybacking is more complex in cases where this is
   done on non-MPLS networks.  In such a case, the piggybacked advertisements
   must allow for the explicit identification of the source of the
   advertisement.  This is important for tunnel set up in non-MPLS networks,
   where each edge router needs to know the identity (i.e. IP address) of each
   of the other edge routers, in order to initiate whatever signaling mechanism
   may be used for tunnel set-up.

   At present there is no means by which the original source of a BGP
   advertisement can be identified once that advertisement is redistributed
   (e.g. from an intra-AS protocol like OSPF into BGP at a border node, or from
   an edge router through a border router for distribution outside the original
   AS).  Since VPN support in non-MPLS networks is an important requirement, it
   is proposed that whatever BGP-4 mechanism is chosen for the purpose of VPN
   advertisements also be amended to allow for explicit tagging with the IP
   address of the original source of the advertisement.  One possible means by
   which this could be done may be to associate the VPN ID (coded as a Community
   Attribute) with the /32 prefix (i.e. IP address) of the edge router
   supporting the VPN.  This issue is for further study.

   Note that in the case where BGP advertisements are propagated across AS
   boundaries, then each border router must cache the full set of prefixes and
   associated label stacks of each advertised VPN.  In such a case, further work
   is also needed to control scoping of BGP piggybacked advertisements.  In
   particular, at AS boundaries, border routers would generally need to be
   manually configured with VPN route advertisement policies to determine
   whether such advertisements should be propagated, and, if so, to which peer
   ASs.  In general ASs will also likely automatically reject VPN advertisements
   received from peer ASs unless specifically configured to pass them.  Some
   administrative mechanism (e.g. manual procedures or some form of directory
   communication, for instance) would be needed for this purpose.

   Note also that such scoping policy configurations would be needed not only in
   each border router of each AS with one or more VPN termination points, but
   also in each AS in the transit path between them.  This last may pose
   problems if the trust system includes the terminating ASs, but excludes one
   or more of the transit ASs.  These problems expose a particular artifact of
   router piggybacking - while VPN membership and reachability information is
   relevant only to the particular edge routers concerned, router piggybacking



Gleeson et al.                                                 [Page 46]


INTERNET DRAFT       A Framework for IP Based VPNs       September, 1998


   necessarily requires also the active participation of all intermediate
   routers that need to process and propagate such advertisements.  This may
   impose significant burdens on the operation and administration of such
   intermediate routers, as well as compromising the integrity of the VPNs
   concerned.














































Gleeson et al.                                                 [Page 47]