Internet Engineering Task Force Bryan Gleeson, Arthur Lin
INTERNET DRAFT Shasta Networks, Inc.
Expires August 1999 Juha Heinanen
Telia Finland, Inc.
Grenville Armitage
Bell Labs, Lucent Technologies
Andrew Malis
Ascend Communications, Inc.
A Framework for IP Based Virtual Private Networks
<draft-gleeson-vpn-framework-01.txt>
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
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.
Gleeson et al. [Page 1]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
3.0 Introduction
There is currently significant interest in the deployment of virtual
private networks (VPN), across IP backbone facilities. The
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.
In this Draft a VPN is modelled as a connectivity object. Hosts may
be attached to a VPN, and VPNs may be interconnected together, in the
same manner as hosts today attach to physical networks, and physical
networks are interconnected together (e.g. via bridges or routers).
Many aspects of networking, such as addressing, forwarding mechanism,
learning and advertising reachability, QoS, security, and
firewalling, have common solutions across both physical and virtual
networks, and many issues that arise in the discussion of VPNs have
direct analogues with those issues as implemented in physical
networks. The introduction of VPNs does not create the need to
reinvent networking, or to introduce entirely new paradigms that have
no direct analogue with existing physical networks. Instead it is
often useful to first examine how a particular issue is handled in a
physical network environment, and then apply the same principle to an
environment which contains virtual as well as physical networks, and
to develop appropriate extensions and enhancements when necessary.
Clearly having mechanisms that are common across both physical and
virtual networks facilitates the introduction of VPNs into existing
networks, and also reduces the effort needed for both standards and
product development, since existing solutions can be leveraged.
This framework 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
Gleeson et al. [Page 2]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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
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
Gleeson et al. [Page 3]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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].
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
Gleeson et al. [Page 4]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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.
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
Gleeson et al. [Page 5]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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.
4.2 VPNs and Extranets
The term 'extranet' is commonly used to refer to a scenario whereby
two or more companies have networked access to a limited amount of
each other's corporate data. For example a manufacturing company
might use an extranet for its suppliers to allow it to query
databases for the pricing and availability of components, and then to
order and track the status of outstanding orders. Another example is
joint software development, for instance, company A allows one
development group within company B to access its operating system
source code, and company B allows one development group in company A
to access its security software. Note that the access policies can
get arbitrarily complex. For example company B may internally
restrict access to its security software to groups in certain
geographic locations to comply with export control laws, for example.
A key feature of an extranet is thus the control of who can access
what data, and this is essentially a policy decision. Policy
decisions are typically enforced today at the interconnection points
between different domains, for example between a private network and
the Internet, or between a software test lab and the rest of the
company network. The enforcement may done via a firewall, router with
access list functionality, application gateway, or any similar device
capable of applying policy to transit traffic. Policy controls may be
implemented within a corporate network, in addition to between
corporate networks. Also the interconnections between networks could
be a set of bilateral links, or could be a separate network, perhaps
maintained by an industry consortium. This separate network could
itself be a VPN or a physical network.
Introducing VPNs into a network does not require any change to this
model. Policy can be enforced between two VPNs, or between a VPN and
the Internet, in exactly the same manner as is done today without
VPNs. For example two VPNs could be interconnected, which each
administration locally imposing its own policy controls, via a
firewall, on all traffic that enters its VPN from the outside,
whether from another VPN or from the Internet.
This model of a VPN provides for a separation of policy from the
underlying mode of packet transport used. For example, a router may
direct voice traffic to ATM VCCs for guaranteed QoS, non-local
internal company traffic to secure tunnels, and other traffic to a
link to the Internet. In the past the secure tunnels may have been
frame relay circuits, now they may also be secure IP tunnels or MPLS
Gleeson et al. [Page 6]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
LSPs.
Other models of a VPN are also possible. For example there is a model
whereby a set of application flows is mapped into a VPN. As the
policy rules imposed by a network administrator can get quite
complex, the number of distinct sets of application flows that are
used in the policy rulebase, and hence the number of VPNs, can thus
grow quite large, and there can be multiple overlapping VPNs. However
there is little to be gained by introducing such new complexity into
a network. Instead a VPN should be viewed as a direct analogue to a
physical network, as this allows the leveraging of existing protocols
and procedures, and the current expertise and skillsets of network
administrators and customers.
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.
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.
Gleeson et al. [Page 7]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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 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] [Jamieson] [Casey1] [Li2] and [Rosen], 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:
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.
Gleeson et al. [Page 8]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
Work is currently underway [Fox] in the IETF and the ATM Forum to
standardize a common VPN identifier (VPN-ID) format and encapsulation
header. A VPN-ID can be used in the control plane, to bind a tunnel
to a VPN at tunnel establishment time, or in the data plane, to
identify the VPN associated with a packet, on a per-packet basis. In
the data plane a VPN encapsulation header could be used by MPLS, MPOA
and other tunneling mechanisms to aggregate packets for different
VPNs over a single tunnel. In this case an explicit indication of
VPN-ID is included with every packet, and no use is made of any
tunnel specific multiplexing field. In the control plane a VPN-ID
field can be included in any tunnel establishment signalling protocol
(e.g. IKE) to allow for the association of a tunnel (e.g. as
identified by the SPI field) with a VPN. In this case there is no
need for a VPN-ID to be included with every data packet. This is
discussed further in section 6.1.1.
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
exchanged or negotiated, for example the use of frame sequencing or
Gleeson et al. [Page 9]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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. For VPNs implemented
over non-IP backbones (e.g. MPOA, Frame Relay or ATM virtual
circuits), data security is implicitly provided by the layer two
switch infrastructure.
Overall VPN security is not just a capability of the tunnels alone,
but has to be viewed in the broader context of how packets are
forwarded onto those tunnels. For example with VPRNs implemented with
virtual routers, the use of separate routing and forwarding table
instances ensures the isolation of traffic between VPNs. Packets on
one VPN cannot be misrouted to a tunnel on a second VPN since those
tunnels are not visible to the forwarding table of the first VPN.
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.
Gleeson et al. [Page 10]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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
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.
IPSEC could be extended to use the existing sequence field 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
Gleeson et al. [Page 11]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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
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.
In particular efforts should be made to standardize a protocol stack
that can be used for voluntary tunneling for dial-up remote clients
connecting to a VPN, that minimizes overhead. In this scenario the
amount of overhead is a significant issue given the low bandwidth of
dial-up links. This is discussed further in section 7.2.
Gleeson et al. [Page 12]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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
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. See also [Duffield]
for a discussion of QoS and VPNs.
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
Gleeson et al. [Page 13]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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
than use multiple protocols in parallel (e.g. IKE/IPSec and L2TP).
Extra considerations apply to the specific case of voluntary tunnels
used for remote access to VPNs. This is discussed further in section
7.2. 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], [Casey1],
[Jamieson], [Li2], [Muthukrishnan], and [Rosen].
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
Gleeson et al. [Page 14]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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.
+--------+ +--------+
+---+ | 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
Gleeson et al. [Page 15]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
(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
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).
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
Gleeson et al. [Page 16]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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
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
Gleeson et al. [Page 17]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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
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.0.1 VPRN related work
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.
There are two main variants as regards the mechanisms used to provide
VPRN membership and reachability functionality, - overlay and
piggybacking. These are discussed in greater detail in 6.1.2, 6.1.3
and 6.1.4 below. An example of the overlay model is described in
[Muthukrishnan], which discusses the provision of VPRN functionality
by means of a separate per-VPN routing protocol instance and route
and forwarding table instantiation, otherwise known as virtual
routing. Each VPN routing instance is isolated from any other VPN
routing instance, and from the routing used across the backbone. As a
result any routing protocol (e.g. OSPF, RIP2, IS-IS) can be run with
any VPRN, independently of the routing protocols used in other VPRNs,
or in the backbone itself. The VPN model described in [Casey1] is
also an overlay VPRN model using virtual routing. This draft is
specifically geared towards the provision of VPRN functionality over
MPLS backbones, and it describes how VPRN membership dissemination
can be automated over an MPLS backbone, by performing VPN neighbour
discovery over the base MPLS tunnel mesh. [Casey2] extends the
virtual routing model to include VPN areas, and VPN border routers
which route between VPN areas. VPN areas may be defined for
administrative or technical reasons, such as different underlying
network infrastructures (e.g. ATM, MPLS, IP).
In contrast [Rosen] describes the provision of VPN functionality
using a piggybacking approach for membership and reachability
Gleeson et al. [Page 18]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
dissemination, with this information being piggybacked in BGP. VPNs
are constructed using BGP policies, which are used to control which
sites can communicate with each other. [Li2] also uses BGP for
piggybacking membership information, and piggybacks reachability
information on the protocol used to establish MPLS LSPs (LDP or
RSVP). Unlike the other proposals, however, this proposal requires
the participation on the CPE router to implement the VPN
functionality.
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
Most of the VPN schemes developed (e.g. [Muthukrishnan], [Jamieson],
[Casey1], [Li2]) require the use of a VPN-ID that is carried in
control and/or data packets, which is used to associate the packet
with a particular VPN. This can be used for a variety of purposes. A
VPN-ID can be included in a MIB to to identify a VPN for management
purposes. A VPN-ID can be used in the control plane, for example to
bind a tunnel to a VPN at tunnel establishment time. All packets that
traverse the tunnel are then implicitly associated with the
identified VPN. A VPN-ID can be used in a data plane encapsulation,
Gleeson et al. [Page 19]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
to allow for an explicit per-packet identification of the VPN
associated with the packet. In general a VPN may span multiple
administrative domains (e.g. multiple autonomous (ASs) systems), thus
any VPN-ID needs to be a globally unique identifier.
Although the use of a VPN-ID in this manner is very common, it is not
universal. [Rosen] describes a scheme where there is no protocol
field used to identify a VPN in this manner. In this scheme the VPNs
as understood by a user, are administrative constructs, built using
BGP policies. There are a number of attributes associated with VPN
routes, such as a route distinguisher, and origin and target "VPN",
that are used by the underlying protocol mechanisms for
disambiguation and scoping, and these are also used by the BGP policy
mechanism in the construction of VPNs, but there is nothing
corresponding with the VPN-ID as used in the other Drafts.
Although the use of VPN-ID in protocol packets to identify what a
user would intuitively understand as a VPN is thus not universal,
there is sufficient commonality among many of the proposals to
warrant the standardization of such an attribute. Having a standard
way of representing a VPN-ID across MIBs, extensions to control plane
protocols, and in data encapsulations used over different media types
(e.g. IP, ATM) facilitates multi-vendor interoperability, and avoids
the need for translation between formats, with possible problems
regarding the size of the number space or the length of the globally
unique organizational identifier.
To this end [Fox] proposes a rationale and format for a globally
unique VPN-ID. Similar work is also in progress in the ATM Forum. As
described in [Fox] a VPN-ID contains a globally unique organization
identifier, followed by a VPN index. Although some previous proposals
(e.g.[Heinanen1]) proposed the use of AS number as a globally unique
organizational identifier, an Organizationally Unique Identifier
(OUI), is a more general solution. This is because there may not
always be an AS number that can be used (e.g. the VPN functionality
is being provided on private IP backbone facilities). The assignment
of the VPN index space is under control of the organization
identified by the OUI.
[Grossman] defines the format of a VPN-ID to be used for
encapsulations over ATM AAL5. This draft is an update to [Heinanen3]
(RFC1483). The VPN-ID format used is the same as that defined in
[Fox].
This Draft proposes that a standard VPN-ID be defined to be used as
described above, and for the remainder of this Draft it assumes that
such a globally unique VPN identifier exists.
Gleeson et al. [Page 20]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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
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.
Gleeson et al. [Page 21]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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:
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.
Gleeson et al. [Page 22]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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
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.
Gleeson et al. [Page 23]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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.
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
Gleeson et al. [Page 24]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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.
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
Gleeson et al. [Page 25]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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
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:
Gleeson et al. [Page 26]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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.
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
Gleeson et al. [Page 27]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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
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
Gleeson et al. [Page 28]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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:
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
Gleeson et al. [Page 29]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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
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
Gleeson et al. [Page 30]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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.
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.
Gleeson et al. [Page 31]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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
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
Gleeson et al. [Page 32]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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 are proposals that utilize the router piggybacking approach for
distributing VPN membership and/or reachability information ([Rosen],
[Li2]) and also proposals that use the virtual routing approach
([Muthukrishnan], [Casey1]). In some cases the mechanisms described
rely on the characteristics of a particular infrastructure (e.g.
MPLS) rather than just IP. However to allow for interoperable VPRNs
that span multiple administrations, a set of protocols and procedures
that only assumes IP connectivity between all sites, is desirable. In
particular the virtual routing approach looks suitable for this
environment, since transit ISPs can be totally VPN-unaware. Within
the context of the virtual routing approach, it seems useful to
standardize on
- 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, however
the limitations and scalability issues associated with this topology
may not make it worthwhile to develop something specific for this
case, as standard routing will just work.
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.
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
Gleeson et al. [Page 33]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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.
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
Gleeson et al. [Page 34]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
[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].
7.1.3 Traffic Management
L2TP supports, as an optional capability, 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.
Gleeson et al. [Page 35]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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
Voluntary tunneling refers to cases where an individual host connects
to a remote site using a tunnel originating on the host, 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).
There is also a set of drafts that together extend IKE to include
user authentication and IP stack configuration. In effect functions
currently carried out by PPP, specifically user authentication and
the configuration of client IP address and DNS server addresses
carried out by IPCP, have been added as extensions to IKE. [Pereira1]
defines a new ISAKMP message exchange - the "transaction exchange"
which allows for both Request/Reply and Set/Acknowledge message
sequences. This draft also defines attributes that can be used for
client IP stack configuration. [Pereira2] and [Litvin] 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.
Gleeson et al. [Page 36]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
A distinction needs to be drawn here between "machine" authentication
and "user" authentication. "Two factor" authentication is carried out
on the basis of 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). For this reason the
authentication provided by means of a Phase 1 IKE exchange is not
always sufficient. It is also necessary to be able to support legacy
authentication schemes currently used over PPP and validated with a
RADIUS server or equivalent, either in addition to, or instead of,
IKE authentication.
The main benefit of incorporating the user authentication and IP
stack configuration elements of PPP into IKE, is to minimize the
protocol overhead. Given the low bandwidth of dial-up links, and the
overhead generated as a result of IPSec AH or ESP, any steps to
minimize the total amount of overhead are beneficial. Using L2TP for
voluntary tunneling, secured with IPSec, means a web application, for
example, may run over the following stack
(1) HTTP/TCP/IP/PPP/L2TP/UDP/ESP/IP/PPP/AHDLC
Using IPSec tunneling as a voluntary tunneling scheme, extended to
include user authentication and IP stack configuration, can reduce
this to
(2) HTTP/TCP/IP/ESP/IP/PPP/AHDLC
In case (1), the value of the L2TP/UDP layers, is minimal, since
there is already a tunneling protocol underneath (IPSec) that can
perform the same functions as L2TP (e.g. multiplexing). So another
approach would be to examine putting PPP directly on top of IPSec.
This may combine the preservation of all the useful features of PPP
with a lower overhead than (1).
(3) HTTP/TCP/IP/PPP/ESP/IP/PPP/AHDLC
For an approach that does not use PPP, but just uses IPSec, the
method of support for multiprotocol traffic needs to be specified. In
the general case there is a requirement to carry not just different
types of network layer protocols (e.g. IPX) but also different types
of link layer protocols (e.g ethernet), as would be needed to support
bridging over IPSec.
One way is to use GRE inside an IPSec tunnel. The only function that
is required of GRE in this case is protocol identification, so the
other optional fields in a GRE header could be omitted. The GRE
sequence number field could be used to guarantee in-order delivery,
Gleeson et al. [Page 37]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
but IPSec also contains a sequence number field, which could be
pressed into service for the same purpose (see 5.1.5).
Another way is to use LLC inside an IPSec tunnel. The set of code
points that already exists for LLC is more comprehensive than those
for GRE (e.g. all the layer 2 encapsulations such as 802.3 with FCS,
802.3 without FCS, 802.5 etc), although extra code points could
easily be added to GRE. Using LLC would allow all the encapsulations
used in [Grossman] to be reused, in effect treating an IP tunnel as
another "MAC" sublayer, like ethernet or AAL5, over which LLC is
used.
Yet another approach is to negotiate, via IKE extensions, the
protocol that will be carried on an SA, and not to carry any per-
packet identification of the protocol with packets used on the SA (a
'VC-muxed' approach). This could be used in addition to a scheme that
carried per-packet protocol identification.
A number of proprietary solutions that use IPSec tunneling alone as a
voluntary tunneling scheme are currently commercially available.
There are also solutions that use L2TP and IPSec together. The IETF
should examine this area and work towards picking a single approach
to be used for voluntary tunneling.
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).
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
Gleeson et al. [Page 38]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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 specification is currently near finalization and is the
clear choice for VPDNs using compulsory tunneling.
For voluntary tunneling different approaches are possible, as
outlined above. One approach is a PPP based solution, running over
L2TP, secured by IPSec. The advantage of this is that the user
authentication, network layer configuration, and multiprotocol
support capabilities of PPP are available for reuse. The disadvantage
is the high overhead, particularly on low-bandwidth dial-up lines
where voluntary tunneling will frequently be used, and the complex
protocol stack that needs to be implemented on hosts, often without
the benefit of access to the OS networking stack source code. A
modification to this approach is to use PPP with a lower overhead
underlying stack, such as running PPP directly over IPSec.
Another approach is to use IPSec tunneling alone, along with
extensions to IKE to incorporate the functions of PPP listed above.
This requires more standards development, and in effect reinvents
portions of PPP, but leads to a lower overhead solution. In this
latter case it is also desirable to maximize commonality with any
IPSec based VLL tunneling mechanism.
Gleeson et al. [Page 39]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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 40]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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 41]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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 42]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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 43]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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)
- defining the protocol stack to be used for voluntary tunneling. If
Gleeson et al. [Page 44]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
an IPSec based approach is used without PPP, this implies defining
the IKE extensions to allow user authentication, network layer
configuration, and multiprotocol support. If PPP is used, methods
that reduce the overhead compared to that of a full underlying
L2TP/UDP stack should be examined. (section 7.2)
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, 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-
04.txt.
[Aboba2] Aboba, B. and Zorn, G. - "Criteria for Evaluating Roaming
Protocols", RFC 2477.
[ADSL1] ADSL Forum - "An Interoperable End-to-end Broadband Service
Architecture over ADSL Systems (Version 3.0)", ADSL Forum 97-215.
[ADSL2] ADSL Forum - "Core Network Architectures for ADSL Access
Systems (Version 1.01)", ADSL Forum 998-017.
[ATMF1] ATM Forum - "LAN Emulation over ATM 1.0", af-lane-0021.000,
January 1995.
[ATMF2] ATM Forum - "Multi-Protocol Over ATM Specification v1.0",
af-mpoa-0087.000, June 1997.
[Bates] Bates, T. "Multiprotocol Extensions for BGP-4", RFC 2283.
[Bernet] Bernet, Y., et al - "A Framework for Differentiated
Services", draft-ietf-diffserv-framework-01.txt.
Gleeson et al. [Page 45]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
[Calhoun1] Calhoun, P. and Peirce, K. - "Layer Two Tunneling Protocol
"L2TP" IP Differential Services Extension", draft-ietf-pppext-l2tp-
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-04.txt.
[Casey1] Casey, L. et al - "IP VPN Realization using MPLS Tunnels",
draft-casey-vpn-mpls-00.txt.
[Casey2] Casey, L. "An extended IP VPN Architecture", draft-casey-
vpn-extns-00.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
[Duffield] Duffield N, et al - "A Performance Oriented Service
Interface for Virtual Private Networks", draft-duffield-vpn-qos-
framework-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-02.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.
[Fox] Fox, B. and Gleeson, B. "Virtual Private Networks Identifier",
draft-fox-vpn-id-00.txt.
[Grossman] Grossman, D. and Heinanen, J. - "Multiprotocol
Gleeson et al. [Page 46]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
Encapsulation over ATM Adaptation Layer 5", draft-ietf-ion-
multiprotocol-atm-01.txt.
[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)", RFC 2409.
[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.
[Heinanen3] Heinanen, J. - "Multiprotocol Encapsulation over ATM
Adaptation Layer 5", RFC1483.
[IEEE] 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.
[Jamieson] Jamieson, D., et al - "MPLS VPN Architecture", draft-
jamieson-mpls-vpn-00.txt.
[Jamieson2] Jamieson, D and Wang, R. - "Solicitation Extensions for
BGP-4" draft-jamieson-bgp-solicit-00.txt.
[Kent] Kent, S. and Atkinson, R. "Security Architecture for the
Internet Protocol", RFC 2401.
[Li] Li, T. and Rekhter, Y. - "Provider Architecture for
Differentiated Services and Traffic Engineering (PASTE)", RFC 2430.
[Li2] Li, T. - "CPE based VPNs using MPLS", draft-li-mpls-vpn-00.txt.
[Litvin] Litvin, M. et al - "A Hybrid Authentication Mode for IKE",
draft-ietf-ipsec-isakmp-hybrid-auth-01.txt.
[Malkin] Malkin, G. "RIP Version 2 Carrying Additional
Information", RFC 1723.
[Moy] Moy, J. "OSPF Version 2", RFC 2328.
Gleeson et al. [Page 47]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
[Muthukrishnan] Muthukrishnan, K. and Malis A. - "Core IP VPN
Architecture", draft-muthukrishnan-corevpn-arch-00.txt.
[Patel] Patel, B. and Aboba, B. - "Securing L2TP using IPSEC",
draft-ietf- pppext-l2tp-security-03.txt.
[Pegrum] Pegrum, S. - "VPN Point to Multipoint Tunnel Protocol
(VPMT)", draft-pegrum-vmmt-01.txt.
[Pereira1] Pereira, R. et al - "The ISAKMP Configuration Method",
draft-ietf-ipsec-isakmp-mode-cfg-04.txt.
[Pereira2] Pereira, R. - "Extended Authentication Within
ISAKMP/Oakley", draft-ietf-ipsec-isakmp-xauth-03.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-02.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.
[Rosen] Rosen, E. and Rekhter, Y. - "BGP/MPLS VPNs", draft-rosen-
vpn-mpls-01.txt.
[Valencia1] Valencia, A., et al - "Layer Two Tunneling Protocol
'L2TP'", draft-ietf-pppext-l2tp-13.txt.
[Shacham] Shacham, A., et al - "IP Payload Compression Protocol
(IPComp)", RFC 2393.
[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
Connections for Home Network Clients", ADSL Forum contribution 98-
140.
[Shieh2] Shieh, P et al. "The Requirement and Comparisons of
Gleeson et al. [Page 48]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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-01.txt.
[Thomas] Thomas, B., et al - "LDP Specification", draft-ietf-mpls-
ldp-03.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-08.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
Email: jh@telia.fi
Arthur Lin
Shasta Networks
Gleeson et al. [Page 49]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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
Andrew G. Malis
Ascend Communications, Inc.
1 Robbins Road
Westford, MA 01886
USA
Tel: +1 978 952 7414
Email: malis@ascend.com
14.0 Full Copyright Statement
Copyright (C) The Internet Society (1999). 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 50]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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 51]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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 52]
INTERNET DRAFT A Framework for IP Based VPNs February, 1999
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 53]