tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 2764


A Framework for IP Based Virtual Private Networks

Part 3 of 3, p. 41 to 62
Prev RFC Part


prevText      Top      Up      ToC       Page 41 
6.0  VPN Types:  Virtual Private Dial Networks

   A Virtual Private Dial Network (VPDN) allows for a remote user to
   connect on demand through an ad hoc tunnel into another site.  The
   user is connected to a public IP network via a dial-up PSTN or ISDN
   link, and user packets are tunneled across the public network to the
   desired site, giving the impression to the user of being 'directly'
   connected into that site.  A key characteristic of such ad hoc
   connections is the need for user authentication as a prime
   requirement, since anyone could potentially attempt to gain access to
   such a site using a switched dial network.

   Today many corporate networks allow access to remote users through
   dial connections made through the PSTN, with users setting up PPP
   connections across an access network to a network access server, at
   which point the PPP sessions are authenticated using AAA systems
   running such standard protocols as Radius [44].  Given the pervasive
   deployment of such systems, any VPDN system must in practice allow
   for the near transparent re-use of such existing systems.

   The IETF have developed the Layer 2 Tunneling Protocol (L2TP) [8]
   which allows for the extension of of user PPP sessions from an L2TP
   Access Concentrator (LAC) to a remote L2TP Network Server (LNS).  The
   L2TP protocol itself was based on two earlier protocols, the Layer 2
   Forwarding protocol (L2F) [45], and the Point-to-Point Tunneling
   Protocol (PPTP) [46], and this is reflected in the two quite
   different scenarios for which L2TP can be used - compulsory tunneling
   and voluntary tunneling, discussed further below in sections 6.2 and

   This document focuses on the use of L2TP over an IP network (using
   UDP), but L2TP may also be run directly over other protocols such as
   ATM or Frame Relay.  Issues specifically related to running L2TP over
   non-IP networks, such as how to secure such tunnels, are not
   addressed here.

6.1  L2TP protocol characteristics

   This section looks at the characteristics of the L2TP tunneling
   protocol using the categories outlined in section 3.0.

6.1.1 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 sessions within a tunnel, as identified by a

Top      Up      ToC       Page 42 
6.1.2 Signalling

   This is supported via the inbuilt control connection protocol,
   allowing both tunnels and sessions to be established dynamically.

6.1.3 Data Security

   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 in combination with
   IPSec through IP backbones [47], [48], or related mechanisms on non-
   IP backbones [49].

   The interaction of L2TP with AAA 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 [50].

   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 a VPDN, but may be addressed, for
   instance, by evolving Internet roaming specifications [51].

6.1.4 Multiprotocol Transport

   L2TP transports PPP packets (and only PPP packets) and thus can be
   used to carry multiprotocol traffic since PPP itself is

6.1.5 Sequencing

   L2TP supports sequenced delivery of packets.  This is a capability
   that can be negotiated at session establishment, and that can be
   turned on and off by an LNS during a session.  The sequence number
   field in L2TP can also be used to provide an indication of dropped
   packets, which is needed by various PPP compression algorithms to
   operate correctly.  If no compression is in use, and the LNS
   determines that the protocols in use (as evidenced by the PPP NCP
   negotiations) can deal with out of sequence packets (e.g. IP), then
   it may disable the use of sequencing.

Top      Up      ToC       Page 43 
6.1.6 Tunnel Maintenance

   A keepalive protocol is used by L2TP in order to allow it to
   distinguish between a tunnel outage and prolonged periods of tunnel

6.1.7 Large MTUs

   L2TP itself has no inbuilt support for a segmentation and reassembly
   capability, but when run over UDP/IP IP fragmentation will take place
   if necessary.  Note that a LAC or LNS may adjust the Maximum Receive
   Unit (MRU) negotiated via PPP in order to preclude fragmentation, if
   it has knowledge of the MTU used on the path between LAC and LNS.  To
   this end, there is a proposal to allow the use of MTU discovery for
   cases where the L2TP tunnel transports IP frames [52].

6.1.8 Tunnel Overhead

   L2TP as used over IP networks runs over UDP and must be used to carry
   PPP traffic.  This results in a significant amount of overhead, both
   in the data plane with UDP, L2TP and PPP headers, and also in the
   control plane, with the L2TP and PPP control protocols.  This is
   discussed further in section 6.3

6.1.9 Flow and Congestion Control

   L2TP supports flow and congestion control mechanisms for the control
   protocol, but not for data traffic.  See section 3.1.9 for more

6.1.10 QoS / Traffic Management

   An L2TP header contains a 1-bit priority field, which can be set for
   packets that may need preferential treatment (e.g. keepalives) during
   local queuing and transmission.  Also by transparently extending PPP,
   L2TP has inherent support for such PPP mechanisms as multi-link PPP
   [53] and its associated control protocols [54], which allow for
   bandwidth on demand to meet user requirements.

   In addition L2TP calls can be mapped into whatever underlying traffic
   management mechanisms may exist in the network, and there are
   proposals to allow for requests through L2TP signalling for specific
   differentiated services behaviors [55].

Top      Up      ToC       Page 44 
6.1.11 Miscellaneous

   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 an address 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.

6.2  Compulsory Tunneling

   Compulsory tunneling refers to the scenario 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,
   as illustrated below.  This operation is transparent to the user
   initiating the PPP session to the LAC.  This allows for the
   decoupling of the location and/or ownership of the modem pools used
   to terminate dial calls, from the site to which users are provided
   access.  Support for this scenario was the original intent of the L2F
   specification, upon which the L2TP specification was based.

   There are a number of different deployment scenarios possible. One
   example, shown in the diagram below, is where a subscriber host dials
   into a NAS acting as a LAC, and is tunneled across an IP network
   (e.g. the Internet) to a gateway acting as an LNS. The gateway
   provides access to a corporate network, and could either be a device
   in the corporate network itself, or could be an ISP edge router, in
   the case where a customer has outsourced the maintenance of LNS
   functionality to an ISP.  Another scenario is where an ISP uses L2TP
   to provide a subscriber with access to the Internet. The subscriber
   host dials into a NAS acting as a LAC, and is tunneled across an
   access network to an ISP edge router acting as an LNS. This ISP edge
   router then feeds the subscriber traffic into the Internet.  Yet
   other scenarios are where an ISP uses L2TP to provide a subscriber
   with access to a VPRN, or with concurrent access to both a VPRN and
   the Internet.

   A VPDN, whether using compulsory or voluntary tunneling, can be
   viewed as just another type of access method for subscriber traffic,
   and as such can be used to provide connectivity to different types of
   networks, e.g. a corporate network, the Internet, or a VPRN. The last
   scenario is also an example of how a VPN service as provided to a
   customer may be implemented using a combination of different types of

Top      Up      ToC       Page 45
   |Host|-----    LAC      -------------     LNS
   +----+   /   +-----+   (             )   +-----+     ---------
           /----| NAS |---( IP Backbone )---| GW  |----( Corp.   )
        dial    +-----+   (             )   +-----+    ( Network )
        connection         -------------                ---------

                   <------- L2TP Tunnel ------->

     <--------------------- PPP Session ------->

                 Figure 6.1: Compulsory Tunneling Example

   Compulsory tunneling was originally intended for deployment on
   network access servers supporting 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.  Another example of this is where an ISP outsources its
   own dial connectivity to an access network provider (such as a Local
   Exchange Carrier (LEC) in the USA) removing the need for an ISP to
   maintain its own dial servers and allowing the LEC to serve multiple
   ISPs.  More recently, compulsory tunneling mechanisms have also been
   proposed for evolving Digital Subscriber Line (DSL) services [56],
   [57], which also seek to leverage the existing AAA infrastructure.

   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 [50], 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
   identity claimed during PPP authentication.

   It is also possible to chain two L2TP tunnels together, whereby a LAC
   initiates a tunnel to an intermediate relay device, which acts as an
   LNS to this first LAC, and acts as a LAC to the final LNS.  This may
   be needed in some cases due to administrative, organizational or
   regulatory issues pertaining to the split between access network
   provider, IP backbone provider and enterprise customer.

Top      Up      ToC       Page 46 
6.3  Voluntary Tunnels

   Voluntary tunneling refers to the case where an individual host
   connects to a remote site using a tunnel originating on the host,
   with no involvement from intermediate network nodes, as illustrated
   below.  The PPTP specification, parts of which have been incorporated
   into L2TP, was based upon a voluntary tunneling model.

   As with compulsory tunneling there are different deployment scenarios
   possible. The diagram below shows a subscriber host accessing a
   corporate network with either L2TP or IPSec being used as the
   voluntary tunneling mechanism. Another scenario is where voluntary
   tunneling is used to provide a subscriber with access to a VPRN.

6.3.1  Issues with Use of L2TP for Voluntary Tunnels

   The L2TP specification has support for voluntary tunneling, insofar
   as the LAC can be located on a host, not only on a network node.
   Note that such a host has two IP addresses - one for the LAC-LNS IP
   tunnel, and another, typically allocated via PPP, for the network to
   which the host is connecting.  The benefits of using L2TP for
   voluntary tunneling are that the existing authentication and address
   assignment mechanisms used by PPP can be reused without modification.
   For example an LNS could also include a Radius client, and
   communicate with a Radius server to authenticate a PPP PAP or CHAP
   exchange, and to retrieve configuration information for the host such
   as its IP address and a list of DNS servers to use.  This information
   can then be passed to the host via the PPP IPCP protocol.
   |Host|-----             -------------      
   +----+   /   +-----+   (             )   +-----+     ---------
           /----| NAS |---( IP Backbone )---| GW  |----( Corp.   )
        dial    +-----+   (             )   +-----+    ( Network )
        connection         -------------                ---------

     <-------------- L2TP Tunnel -------------->
                        with                      LAC on host
     <-------------- PPP Session -------------->  LNS on gateway


     <-------------- IPSEC Tunnel -------------->

                  Figure 6.2: Voluntary Tunneling Example

Top      Up      ToC       Page 47 
   The above procedure is not without its costs, however.  There is
   considerable overhead with such a protocol stack, particularly when
   IPSec is also needed for security purposes, and given that the host
   may be connected via a low-bandwidth dial up link.  The overhead
   consists of both extra headers in the data plane and extra control
   protocols needed in the control plane.  Using L2TP for voluntary
   tunneling, secured with IPSec, means a web application, for example,
   would run over the following stack


   It is proposed in [58] that IPSec alone be used for voluntary tunnels
   reducing overhead, using the following stack.


   In this case IPSec is used in tunnel mode, with the tunnel
   terminating either on an IPSec edge device at the enterprise site, or
   on the provider edge router connected to the enterprise site.  There
   are two possibilities for the IP addressing of the host.  Two IP
   addresses could be used, in a similar manner to the L2TP case.
   Alternatively the host can use a single public IP address as the
   source IP address in both inner and outer IP headers, with the
   gateway performing Network Address Translation (NAT) before
   forwarding the traffic to the enterprise network.  To other hosts in
   the enterprise network the host appears to have an 'internal' IP
   address.  Using NAT has some limitations and restrictions, also
   pointed out in [58].

   Another area of potential problems with PPP is due to the fact that
   the characteristics of a link layer implemented via an L2TP tunnel
   over an IP backbone are quite different to a link layer run over a
   serial line, as discussed in the L2TP specification itself.  For
   example, poorly chosen PPP parameters may lead to frequent resets and
   timeouts, particularly if compression is in use.  This is because an
   L2TP tunnel may misorder packets, and may silently drop packets,
   neither of which normally occurs on serial lines.  The general packet
   loss rate could also be significantly higher due to network
   congestion.  Using the sequence number field in an L2TP header
   addresses the misordering issue, and for cases where the LAC and LNS
   are coincident with the PPP endpoints, as in voluntary tunneling, the
   sequence number field can also be used to detect a dropped packet,
   and to pass a suitable indication to any compression entity in use,
   which typically requires such knowledge in order to keep the
   compression histories in synchronization at both ends. (In fact this
   is more of an issue with compulsory tunneling since the LAC may have
   to deliberately issue a corrupted frame to the PPP host, to give an
   indication of packet loss, and some hardware may not allow this).

Top      Up      ToC       Page 48 
6.3.2  Issues with Use of IPSec for Voluntary Tunnels

   If IPSec is used for voluntary tunneling, the functions of user
   authentication and host configuration, achieved by means of PPP when
   using L2TP, still need to be carried out.  A distinction needs to be
   drawn here between machine authentication and user authentication.  '
   Two factor' authentication is carried out on the basis of both
   something the user has, such as a machine or smartcard with a digital
   certificate, and something the user knows, such as a password.
   (Another example is getting money from an bank ATM machine - you need
   a card and a PIN number).  Many of the existing legacy schemes
   currently in use to perform user authentication are asymmetric in
   nature, and are not supported by IKE. For remote access the most
   common existing user authentication mechanism is to use PPP between
   the user and access server, and Radius between the access server and
   authentication server.  The authentication exchanges that occur in
   this case, e.g. a PAP or CHAP exchange, are asymmetric.  Also CHAP
   supports the ability for the network to reauthenticate the user at
   any time after the initial session has been established, to ensure
   that the current user is the same person that initiated the session.

   While IKE provides strong support for machine authentication, it has
   only limited support for any form of user authentication and has no
   support for asymmetric user authentication.  While a user password
   can be used to derive a key used as a preshared key, this cannot be
   used with IKE Main Mode in a remote access environment, as the user
   will not have a fixed IP address, and while Aggressive Mode can be
   used instead, this affords no identity protection.  To this end there
   have been a number of proposals to allow for support of legacy
   asymmetric user level authentication schemes with IPSec.  [59]
   defines a new IKE message exchange - the transaction exchange - which
   allows for both Request/Reply and Set/Acknowledge message sequences,
   and it also defines attributes that can be used for client IP stack
   configuration. [60] and [61] describe mechanisms that use the
   transaction message exchange, or a series of such exchanges, carried
   out between the IKE Phase 1 and Phase 2 exchanges, to perform user
   authentication. A different approach, that does not extend the IKE
   protocol itself, is described in [62]. With this approach a user
   establishes a Phase 1 SA with a security gateway and then sets up a
   Phase 2 SA to the gateway, over which an existing authentication
   protocol is run. The gateway acts as a proxy and relays the protocol
   messages to an authentication server.

   In addition there have also been proposals to allow the remote host
   to be configured with an IP address and other configuration
   information over IPSec.  For example [63] describes a method whereby
   a remote host first establishes a Phase 1 SA with a security gateway
   and then sets up a Phase 2 SA to the gateway, over which the DHCP

Top      Up      ToC       Page 49 
   protocol is run. The gateway acts as a proxy and relays the protocol
   messages to the DHCP server.  Again, like [62], this proposal does
   not involve extensions to the IKE protocol itself.

   Another aspect of PPP functionality that may need to supported is
   multiprotocol operation, as there may be a need to carry network
   layer protocols other than IP, and even to carry link layer protocols
   (e.g.  ethernet) as would be needed to support bridging over IPSec.
   This is discussed in section 3.1.4.

   The methods of supporting legacy user authentication and host
   configuration capabilities in a remote access environment are
   currently being discussed in the IPSec working group.

6.4  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 as DSL have attempted to replicate this model [57],
   so as to allow for the re-use of existing AAA 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.

   There is hence interest in means of accommodating the existing AAA
   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 AAA information is exchanged.
   A number of proposals have been made to address this scenario:

6.4.1  Extension of PPP to Hosts Through L2TP

   A number of proposals (e.g. [56]) 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.

6.4.2  Extension of PPP Directly to Hosts:

   There is also a specification for mapping PPP directly onto Ethernet
   (PPPOE) [64] which uses a broadcast mechanism to allow hosts to find
   appropriate access servers with which to connect. Such servers could
   then further tunnel, if needed, the PPP sessions using L2TP or a
   similar mechanism.

Top      Up      ToC       Page 50 
6.4.3  Use of IPSec

   The IPSec based voluntary tunneling mechanisms discussed above can be
   used either with networked or directly connected hosts.

   Note that all of these methods require additional host software to be
   used, which implements either LAC, PPPOE client or IPSec client

6.5  Recommendations

   The L2TP specification has been finalized and will be widely used for
   compulsory tunneling.  As discussed in section 3.2, defining specific
   modes of operation for IPSec when used to secure L2TP would be

   Also, for voluntary tunneling using IPSec, completing the work needed
   to provide support for the following areas would be useful

   -  asymmetric / legacy user authentication (6.3)

   -  host address assignment and configuration (6.3)

   along with any other issues specifically related to the support of
   remote hosts. Currently as there are many different non-interoperable
   proprietary solutions in this area.

7.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 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.

Top      Up      ToC       Page 51    +--------+                       +--------+
   +---+       | ISP    |     IP tunnel         | ISP    |       +---+
   |CPE|-------| edge   |-----------------------| edge   |-------|CPE|
   +---+ stub  | node   |                       | node   |  stub +---+
         link  +--------+                       +--------+  link
                    ^  |                         |   ^
                    |  |     ---------------     |   |
                    |  |    (               )    |   |
                    |  +----( IP BACKBONE   )----+   |
                    |       (               )        |
                    |        ---------------         |
                    |               |                |
                    |IP tunnel  +--------+  IP tunnel|
                    |           | ISP    |           |
                    +-----------| edge   |-----------+
                                | node   |
                                +--------+    subnet =
                          stub link |

                         Figure 7.1: VPLS Example

7.1  VPLS Requirements

   Topologically and operationally a VPLS can be most easily modeled 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

7.1.1  Tunneling Protocols

   The tunneling protocols employed within a VPLS can be exactly the
   same as those used within a VPRN, if the tunneling protocol permits
   the transport of multiprotocol traffic, and this is assumed below.

Top      Up      ToC       Page 52 
7.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.

7.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 [65] for loop prevention.

7.1.4  CPE Stub Node Types

   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 significant scalability
   constraints in this case, due to the need for packet flooding, and

Top      Up      ToC       Page 53 
   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 support of non-routable

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

7.1.5  Stub Link Packet Encapsulation  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
   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.  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.

7.1.6  CPE Addressing and Address Resolution  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

Top      Up      ToC       Page 54 
   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.  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
   that use a different address space than normal MAC addressing.  See,
   for instance, [11], for a proposed mechanism for VPLSs over MPLS
   networks, leveraging earlier work on VPRN support over MPLS [38],
   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.

7.1.7  VPLS Edge Node Forwarding and Reachability Mechanisms  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 [65].  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
   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.  Router CPE

   Standard bridging techniques can also be used in this case.  In
   addition, the smaller link layer address space of such a VPLS may
   also permit other techniques, with explicit link layer routes between
   CPE routers.  [11], for instance, proposes that MPLS LSPs be set up,
   at the insertion of any new CPE router into the VPLS, between all CPE

Top      Up      ToC       Page 55 
   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.

   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 if full mesh connectivity was not available
   and hence VPLS nodes had to carry transit traffic.

7.2  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.

8.0  Summary of Recommendations

   In this document 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.

   The benefits of adding support for the following mechanisms should be
   carefully examined.

   For IKE/IPSec:

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

   -  a null encryption and null authentication option (3.1.3)

Top      Up      ToC       Page 56 
   -  multiprotocol operation (3.1.4)

   -  frame sequencing (3.1.5)

   -  asymmetric / legacy user authentication (6.3)

   -  host address assignment and configuration (6.3)

   For L2TP:

   -  defining modes of operation of IPSec when used to support L2TP

   For VPNs generally:

   -  defining a VPN membership information configuration and
      dissemination mechanism, that uses some form of directory or MIB

   -  ensure that solutions developed, as far as possible, are
      applicable to different types of VPNs, rather than being specific
      to a single type of VPN.

9.0  Security Considerations

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

10.0  Acknowledgements

   Thanks to Anthony Alles, of Nortel Networks, for his invaluable
   assistance with the generation of this document, and who developed
   much of the material on which early versions of this document were
   based.  Thanks also to Joel Halpern for his helpful review comments.

11.0  References

   [1]  ATM Forum. "LAN Emulation over ATM 1.0", af-lane-0021.000,
        January 1995.

   [2]  ATM Forum. "Multi-Protocol Over ATM Specification v1.0", af-
        mpoa-0087.000, June 1997.

   [3]  Ferguson, P. and Huston, G. "What is a VPN?", Revision 1, April
        1 1998;

Top      Up      ToC       Page 57 
   [4]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E.
        Lear, "Address Allocation for Private Internets", BCP 5, RFC
        1918, February 1996.

   [5]  Kent, S. and R. Atkinson, "Security Architecture for the
        Internet Protocol", RFC 2401, November 1998.

   [6]  Perkins, C., "IP Encapsulation within IP", RFC 2003, October

   [7]  Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing
        Encapsulation (GRE)", RFC 1701, October 1994.

   [8]  Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and
        B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661,
        August 1999.

   [9]  Rosen, E., et al., "Multiprotocol Label Switching Architecture",
        Work in Progress.

   [10] Heinanen, J., et al., "MPLS Mappings of Generic VPN Mechanisms",
        Work in Progress.

   [11] Jamieson, D., et al., "MPLS VPN Architecture", Work in Progress.

   [12] Casey, L., et al., "IP VPN Realization using MPLS Tunnels", Work
        in Progress.

   [13] Li, T. "CPE based VPNs using MPLS", Work in Progress.

   [14] Muthukrishnan, K. and A. Malis, "Core MPLS IP VPN Architecture",
        Work in Progress.

   [15] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999.

   [16] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier",
        RFC 2685, September 1999.

   [17] Petri, B. (editor) "MPOA v1.1 Addendum on VPN support", ATM
        Forum, af-mpoa-0129.000.

   [18] Harkins, D. and C. Carrel, "The Internet Key Exchange (IKE)",
        RFC 2409, November 1998.

   [19] Calhoun, P., et al., "Tunnel Establishment Protocol", Work in

Top      Up      ToC       Page 58 
   [20] Andersson, L., et al., "LDP Specification", Work in Progress.

   [21] Jamoussi, B., et al., "Constraint-Based LSP Setup using LDP"
        Work in Progress.

   [22] Awduche, D., et al., "Extensions to RSVP for LSP Tunnels", Work
        in Progress.

   [23] Kent, S. and R. Atkinson, "IP Encapsulating Security Protocol
        (ESP)", RFC 2406, November 1998.

   [24] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
        51, RFC 1661, July 1994.

   [25] Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D. and
        A. Malis, "ATM Signalling Support for IP over ATM", RFC 1755,
        February 1995.

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

   [27] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [28] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP Payload
        Compression Protocol (IPComp)", RFC 2393, December 1998.

   [29] Duffield N., et al., "A Performance Oriented Service Interface
        for Virtual Private Networks", Work in Progress.

   [30] Jacobson, V., Nichols, K. and B. Poduri, "An Expedited
        Forwarding PHB", RFC 2598, June 1999.

   [31] Casey, L., "An extended IP VPN Architecture", Work in Progress.

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

   [33] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation over
        ATM Adaptation Layer 5", RFC 2684, September 1999.

   [34] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
        Protocol (v3)", RFC 2251, December 1997.

   [35] Boyle, J., et al., "The COPS (Common Open Policy Service)
        Protocol", RFC 2748, January 2000.

   [36] MacRae, M. and S. Ayandeh, "Using COPS for VPN Connectivity"
        Work in Progress.

Top      Up      ToC       Page 59 
   [37] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
        March 1997.

   [38] Heinanen, J. and E. Rosen, "VPN Support with MPLS", Work in

   [39] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S.,
        Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei,
        "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
        Specification", RFC 2362, June 1998.

   [40] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector
        Multicast Routing Protocol", RFC 1075, November 1988.

   [41] Fenner, W., "IGMP-based Multicast Forwarding (IGMP Proxying)",
        Work in Progress.

   [42] Wallner, D., Harder, E. and R. Agee, "Key Management for
        Multicast: Issues and Architectures", RFC 2627, June 1999.

   [43] Hardjono, T., et al., "Secure IP Multicast: Problem areas,
        Framework, and Building Blocks", Work in Progress.

   [44] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
        Authentication Dial In User Service (RADIUS)", RFC 2138, April

   [45] Valencia, A., Littlewood, M. and T. Kolar, "Cisco Layer Two
        Forwarding (Protocol) "L2F"", RFC 2341, May 1998.

   [46] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and
        G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637,
        July 1999.

   [47] Patel, B., et al., "Securing L2TP using IPSEC", Work in

   [48] Srisuresh, P., "Secure Remote Access with L2TP", Work in

   [49] Calhoun, P., et al., "Layer Two Tunneling Protocol "L2TP"
        Security Extensions for Non-IP networks", Work in Progress.

   [50] Aboba, B. and Zorn, G. "Implementation of PPTP/L2TP Compulsory
        Tunneling via RADIUS", Work in progress.

   [51] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming
        Protocols", RFC 2477, January 1999.

Top      Up      ToC       Page 60 
   [52] Shea, R., "L2TP-over-IP Path MTU Discovery (L2TPMTU)", Work in

   [53] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T.
        Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August

   [54] Richards, C. and K. Smith, "The PPP Bandwidth Allocation
        Protocol (BAP) The PPP Bandwidth Allocation Control Protocol
        (BACP)", RFC 2125, March 1997.

   [55] Calhoun, P. and K. Peirce, "Layer Two Tunneling Protocol "L2TP"
        IP Differential Services Extension", Work in Progress.

   [56] ADSL Forum. "An Interoperable End-to-end Broadband Service
        Architecture over ADSL Systems (Version 3.0)", ADSL Forum 97-

   [57] ADSL Forum. "Core Network Architectures for ADSL Access Systems
        (Version 1.01)", ADSL Forum 98-017.

   [58] Gupta, V., "Secure, Remote Access over the Internet using
        IPSec", Work in Progress.

   [59] Pereira, R., et al., "The ISAKMP Configuration Method", Work in

   [60] Pereira, R. and S. Beaulieu, "Extended Authentication Within
        ISAKMP/Oakley", Work in Progress.

   [61] Litvin, M., et al., "A Hybrid Authentication Mode for IKE", Work
        in Progress.

   [62] Kelly, S., et al., "User-level Authentication Mechanisms for
        IPsec", Work in Progress.

   [63] Patel, B., et al., "DHCP Configuration of IPSEC Tunnel Mode",
        Work in Progress.

   [64] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. and R.
        Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)",
        RFC 2516, February 1999.

   [65] ANSI/IEEE - 10038: 1993 (ISO/IEC) Information technology -
        Telecommunications and information exchange between systems -
        Local area networks - Media access control (MAC) bridges,
        ANSI/IEEE Std 802.1D, 1993 Edition.

Top      Up      ToC       Page 61 
12.0  Author Information

   Bryan Gleeson
   Nortel Networks
   4500 Great America Parkway
   Santa Clara CA 95054

   Phone: +1 (408) 548 3711

   Juha Heinanen
   Telia Finland, Inc.
   Myyrmaentie 2
   01600 VANTAA

   Phone: +358 303 944 808

   Arthur Lin
   Nortel Networks
   4500 Great America Parkway
   Santa Clara CA 95054

   Phone: +1 (408) 548 3788

   Grenville Armitage
   Bell Labs Research Silicon Valley
   Lucent Technologies
   3180 Porter Drive,
   Palo Alto, CA 94304


   Andrew G. Malis
   Lucent Technologies
   1 Robbins Road
   Westford, MA 01886

   Phone: +1 978 952 7414

Top      Up      ToC       Page 62 
13.0  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  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

   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


   Funding for the RFC Editor function is currently provided by the
   Internet Society.