Internet Engineering Task Force Bryan Gleeson, Arthur Lin INTERNET DRAFT Shasta Networks, Inc. Expires March 1999 Juha Heinanen Telia Finland, Inc. Grenville Armitage Bell Labs, Lucent Technologies A Framework for IP Based Virtual Private Networks 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 2.0 Abstract This document describes a framework for virtual private networks (VPN) running across IP backbones. It discusses the various different types of VPNs, their respective requirements, and proposes specific mechanisms that could be used to implement each type of VPN using existing or proposed specifications. The objective of this Draft is to serve as a framework for related protocol development in order to develop the full set of specifications required for widespread deployment of interoperable VPN solutions. 3.0 Introduction There is currently significant interest in the deployment of virtual private networks (VPN), across IP backbone facilities. The Gleeson et al. [Page 1] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 widespread deployment of VPNs has been hampered, however, by the lack of interoperable implementations, which, in turn, derive from the lack of general agreement on the definition and scope of VPNs and confusion over the wide variety of solutions that are all described by the term VPN. In the context of this Draft, a VPN is simply defined as the 'emulation of a private wide area network (WAN) facility using IP facilities' (including the public Internet, or private IP backbones). As such, there are as many types of VPNs as there are types of WANs, hence the confusion over what exactly constitutes a VPN. This framework Draft proposes a taxonomy of a specific set of VPN types, showing the specific applications of each, their specific requirements, and the specific types of mechanisms that may be most appropriate for their implementation. The intent of this Draft is to serve as a framework to guide a coherent discussion of the specific modifications that may be needed to existing IP mechanisms in order to develop a full range of interoperable VPN solutions. The Draft first discusses the likely expectations customers have of any type of VPN, and the implications of these for the ways in which VPNs can be implemented. It also discusses the distinctions between Customer Premises Equipment (CPE) based solutions, and network based solutions. Thereafter it presents a taxonomy of the various VPN types and their respective requirements. It also outlines suggested approaches to their implementation, hence also pointing to areas for future standardization. Note also that this Draft only discusses implementations of VPNs across IP backbones, be they private IP networks, or the public Internet. It specifically does not discuss means of constructing VPNs using native mappings onto switched backbones - e.g. VPNs constructed using, for instance, the LAN Emulation over ATM (LANE) [ATMF1] or Multiprotocol over ATM (MPOA) [ATMF2] protocols operating over ATM backbones. IP backbones may be constructed using such native protocols, interconnecting routers across the switched backbone. IP VPNs would then operate on top of this IP network, and hence would not directly utilize the native mechanisms of the underlying backbone. Native VPNs would be restricted to the scope of the underlying backbone, whereas IP based VPNs can extend to the extent of IP reachability. Native VPN protocols are clearly outside the scope of the IETF, and may be tackled by such bodies as the ATM Forum. 4.0 VPN Application and Implementation Requirements There is growing interest in the use of IP VPNs as a more cost effective means of building and deploying private communication Gleeson et al. [Page 2] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 networks for multi-site communication than with existing approaches. Existing private networks can be generally categorized into two types - dedicated WANs that permanently connect together multiple sites, and dial networks, that allow on-demand connections through the PSTN network to one or more sites in the private network. WANs are typically implemented using leased lines or dedicated circuits - for instance, Frame Relay or ATM connections - between the multiple sites. CPE routers or switches at the various sites connect these dedicated facilities together and allow for connectivity across the network. Given the cost and complexity of such dedicated facilities and the complexity of CPE device configuration, such networks are generally not fully meshed, but have a complex mix of tree and mesh topologies with remote offices, for instance, star wired to the nearest central site, with the latter then connected together in some form of full or partial mesh. Private dial networks are used to allow remote users to connect into an enterprise network using PSTN or ISDN links. Typically, this is done through the deployment of network access servers (NAS) at one or more central sites. Users dial into such NAS, which interact with AAAA ('Authentication, Authorization, Accounting and Administration') servers to verify the identity of the user, and the set of services that the user is authorized to receive. In recent times, as more businesses have found the need for high speed Internet connections, in addition to previous private networks, there has been significant interest in the deployment of CPE based VPNs running across the Internet. This has been driven typically by the ubiquity and distance insensitive pricing of current Internet services, that can result in significantly lower costs than typical dedicated or leased line services. The notion of using the Internet for private communications is not new, and many techniques, such as controlled route leaking, have been used for this purpose [Ferguson]. Only in recent times, however, have the appropriate IP mechanisms needed to meet customer requirements for VPNs all come together. These requirements include the following: A. Support for Opaque Packet Transport: The traffic carried within a VPN may have no relation to the traffic on the IP backbone, either because the traffic is multiprotocol, or because the customer's IP network may use IP addressing unrelated to that of the IP backbone on which the traffic is transported. In particular, the latter may also be non-unique, private IP addressing [Rekhter1]. Gleeson et al. [Page 3] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 B. Support for Data Security: In general, customers using VPNs require some form of data security, given the general perceptions of the lack of security of IP networks, and particularly that of the Internet. Whether or not this perception is correct, it is one that must be addressed by any VPN implementation. Note that some security concerns - e.g. snooping - may be alleviated in cases where all of the VPN traffic stays within a single service provider's closed IP backbone; on the other hand, this alone may not address other concerns such as packet misdirection, data integrity or ability of third parties to insert unauthorized packets. Most recent VPN implementations are converging on the use of standard IPSec facilities [Kent] for this purpose. C. Support for Quality of Service Guarantees: In addition to ensuring communication privacy, existing private networking techniques, building upon physical or link layer mechanisms, also offer various types of quality of service guarantees. In particular, leased and dial up lines offer both bandwidth and latency guarantees, while dedicated connection technologies like ATM and Frame Relay have extensive mechanisms for similar guarantees. As IP based VPNs become more widely deployed, there will be market demand for similar guarantees, in order to ensure end to end application transparency. While the ability of IP based VPNs to offer such guarantees will depend greatly upon the commensurate capabilities of the underlying IP backbones, a VPN framework must also address the means by which VPN systems can utilize such capabilities, as they evolve. Together, the first two of these requirements imply that VPNs must be implemented through some form of IP tunneling mechanism, where the packet formats and/or the addressing used within the VPN can be unrelated to that used to route the tunneled packets across the IP backbone. Such tunnels, depending upon their form, can provide some level of intrinsic data security, or this can also be enhanced using other mechanisms (e.g. IPSec). Furthermore, as discussed later, such tunneling mechanisms can also be mapped into evolving IP traffic management mechanisms. There are already defined a large number of IP tunneling mechanisms. Some of these are well suited to VPN applications, as discussed further below. Gleeson et al. [Page 4] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 4.1 CPE and Network Based VPNs Most current VPN implementations are based on CPE equipment. VPN capabilities are being integrated into a wide variety of CPE devices, ranging from Firewalls, to WAN edge routers and specialized VPN termination devices. Such equipment may be bought and deployed by customers, or may be deployed (and often remotely managed) by service providers in an outsourcing service. There is also significant interest in 'network based VPNs', where the operation of the VPN is outsourced to an Internet service provider (ISP), and is implemented on network as opposed to CPE equipment. There is significant interest in such solutions both by customers seeking to reduce support costs and by ISPs seeking new revenue sources. Supporting VPNs in the network allows the use of particular mechanisms which may lead to highly efficient and cost effective VPN solutions, with common equipment and operations support amortized across large numbers of customers. Most of the mechanisms discussed below can apply to either CPE based or network based VPNs. However particular mechanisms are likely to prove applicable only to the latter, since they leverage tools (e.g. piggybacking on routing protocols) which are accessible only to ISPs and which are unlikely to be made available to any customer, or even hosted on ISP owned and operated CPE, due to the problems of coordinating joint management of the CPE gear by both the ISP and the customer. The Draft will indicate which techniques are likely to apply only to network based VPNs. 5.0 VPN Types: 'Virtual Leased Lines' The simplest form of a VPN is a 'virtual leased line' (VLL) service. In this case, the two VPN endpoints are connected by an IP tunnel which seeks to emulate a physical leased line or dedicated connection. The IP tunnel operates as an overlay across the IP backbone, and the traffic sent through the tunnel is opaque to the underlying IP backbone. In effect the IP backbone is being used as a link layer technology, and the IP tunnel forms a point-to-point link. A device may terminate multiple such VLLs and route or bridge between them, but the manner in which the the VLLs are connected, i.e. at layer 3 or layer 2, is independent of the operation of the VLL itself. For example at layer 3 the VLL can be bound to an IP forwarding table, which views it as just another point-to-point IP interface. A simple example of forwarding at layer 2 is the operation of relaying frames between an ATM VCC and a VLL, in effect forming a point-to-point link. VLLs can also be used to interconnect bridging devices. Gleeson et al. [Page 5] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 More generally, a VLL can also be considered to be the building block of more complex VPN types and topologies. Specifically, as will be discussed in following sections, there are also VPN types in which the forwarding operation, be it at the link layer or the network layer, is also part of the operation of the VPN. In this case, the tunnels connecting each of the VPN nodes can be constructed using VLL tunneling mechanisms, since these have the same requirements. The following section, therefore, looks at the requirements of a generic IP tunneling protocol that can be used both for simple VLL applications, and also for more complex types of VPNs. 5.1 Tunneling Protocol Requirements for VLLs There are numerous IP tunneling mechanisms, including IP/IP [Simpson], GRE tunnels [Hanks], L2TP [Valencia1], MPLS [Callon] and IPSec [Kent]. Note that while some of these protocols are not often thought of as tunneling protocols, they do each allow for opaque transport of frames as packet payload, with forwarding disjoint from the address fields of the encapsulated packets. As such, any of these could be applied to the operation of a VLL, albeit with some modifications, as discussed below. Note, however, that there is one significant distinction between each of the IP tunneling protocols mentioned above, and MPLS. MPLS can be viewed as a specific link layer for IP, insofar as MPLS specific mechanisms apply only within the scope of an MPLS network, whereas IP based mechanisms extend to the extent of IP reachability. As such, VPN mechanisms built directly upon MPLS tunneling mechanisms (e.g. as described in [Heinanen1] or [Jamieson]) cannot, by definition, extend outside the scope of MPLS networks, any more so than, for instance, ATM based mechanisms such as LANE can extend outside of ATM networks. Note however, that an MPLS network can span many different link layer technologies, and so, like an IP network, its scope is not limited by the specific link layers used. Parallel work on defining a set of mechanisms to allow for interoperable VPNs specifically over MPLS networks is also underway, as addressed in [Heinanen2] and [Jamieson], and as will be discussed later. There are a number of desirable requirements for a VLL tunneling mechanism, however, that are not all met by the existing tunneling mechanisms. These include: Gleeson et al. [Page 6] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 5.1.1 Support for VLL Multiplexing: There are cases where multiple VLLs may be needed between the same two IP endpoints. This may be needed, for instance, in cases where the VLLs are network based, and each end point supports multiple customers. Traffic for different customers travels over separate VLLs between the same two physical devices. A multiplexing field is needed to distinguish which packets belong to which VLL. Sharing a tunnel in this manner may also reduce the latency and processing burden of tunnel set up. Of the existing IP tunneling mechanisms, L2TP (via the tunnel-id and call-id fields), MPLS (via the label) and IPSec (via the SPI field) have a multiplexing mechanism. Strictly speaking GRE does not have a multiplexing field. However the key field, which was intended to be used for authenticating the source of a packet, has sometimes been used as a multiplexing field. IP/IP does not have a multiplexing field. 5.1.2 Support for a Signalling Protocol For a VLL there is some configuration information that must be known by an end point in advance of tunnel establishment, such as the IP address of the remote end point, and any relevant tunnel attributes required (such as the level of security needed). Following this configuration the actual tunnel establishment can be completed in one of two ways - via a management operation, or via a signalling protocol that allows tunnels to be established dynamically. An example of a management operation would be to use an SNMP MIB to configure various tunneling parameters, e.g. MPLS labels, source addresses to use for IP/IP or GRE tunnels, L2TP tunnel-ids and call- ids, or security association parameters for IPSec. Using a signalling protocol can significantly reduce the management burden however and should be a requirement for any standard VLL tunneling mechanism. It reduces the amount of configuration needed, and reduces the management co-ordination needed if a VPN spans multiple administrative domains. For example, the value of the multiplexing field, described above, is local to the node assigning the value, and can be kept local if distributed via a signalling protocol, rather than being first configured into a management station and then distributed to the relevant nodes. A signalling protocol also allows nodes that are mobile or are only intermittently connected to establish tunnels on demand. Signalling is particularly useful for the VPRN scenario described later (section 6.0). A signalling protocol should allow for the transport of a VPN identifier (see 6.1.1) to allow the resulting tunnel to be associated with a particular VLL. It should also allow tunnel attributes to be Gleeson et al. [Page 7] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 exchanged or negotiated, for example the use of frame sequencing or the use of multiprotocol transport. Note that the role of the signalling protocol is solely to negotiate tunnel attributes, not to carry information about how the tunnel is used, for example whether the frames carried in the tunnel are to be forwarded at layer 2 or layer 3. (This is similar to Q.2931 ATM signalling - the same signalling protocol is used to set up Classical IP LISs as well as LANE ELANs). Of the various tunneling protocols, the following ones support a signaling protocol that could possibly be adapted for this purpose: MPLS (the various mechanisms for label distribution, including the label distribution protocol (LDP) [Thomas]), L2TP (the L2TP control channel) and IPSec (the Internet Key Exchange (IKE) protocol [Harkins]), and GRE (as used with mobile-ip tunneling [Calhoun3]). 5.1.3 Support for Data Security: A VLL tunneling mechanism must support mechanisms to allow for whatever level of security may be desired by customers, including authentication and/or encryption of various strengths. None of the tunneling mechanisms discussed, other than IPSec, have intrinsic security mechanisms, but rely upon the security characteristics of the underlying IP backbone. In particular, MPLS relies upon the explicit labeling of label switched paths (LSP) to ensure that packets cannot be misdirected, while the other tunneling mechanisms can all be secured through the use of IPSec. If some form of signalling mechanism is used by one VLL end point to dynamically establish a tunnel with another endpoint, then there is a requirement to be able to authenticate the party attempting the tunnel establishment. IPsec has an array of schemes for this purpose, allowing, for example, authentication to be based on pre-shared keys, or public/private key pairs with certificates. Other tunneling schemes have weaker forms of authentication. In some cases no authentication may be needed, for example if the tunnels are provisioned, rather than dynamically established, or if the trust model in use does not require it. 5.1.4 Support for Multiprotocol Transport In many applications of VLLs, the VLL may carry opaque, multiprotocol traffic. As such, the tunneling protocol must also support multiprotocol transport. The only tunneling mechanism which will preclude such transport is IP/IP. L2TP is designed to transport PPP packets, and thus can be used to carry multiprotocol traffic since PPP itself is multiprotocol. IPSec has been designed to transport IP packets, but may be readily generalized to carry multiprotocol Gleeson et al. [Page 8] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 traffic. The signalling component of IPSec (IKE) could be extended to indicate the type of traffic carried over the IP tunnel or the type of packet multiplexing header used (e.g. LLC/SNAP, GRE), if the traffic is not IP. 5.1.5 Support for Frame Sequencing: One quality of service attribute required by customers of a VLL, may be frame sequencing, matching the equivalent characteristic of physical leased lines or dedicated connections. Sequencing may be required for the efficient operation of particular end to end protocols or applications. In order to implement frame sequencing, a VLL tunneling mechanism should have the option of a sequencing field. At present, only the L2TP specification has such a field. IPSEC has a sequence number field, but it is used by a receiver to perform an anti-replay check, not to guarantee in-order delivery of packets. 5.1.6 Support for Tunnel Maintenance: The VLL end points must monitor the operation of the VLL tunnels to ensure that connectivity has not been lost. Note that this does not necessarily require inband verification, since IP backbone connectivity with the VLL end point is sufficient assurance, due to the fact the tunnel also runs across the same backbone. L2TP has an optional in-band keep-alive mechanism to detect non-operational tunnels. Other tunneling mechanisms will likely require some out of band mechanism to determine connectivity - for instance, regular ICMP pings. Note also that tunnel inactivity should be differentiated from tunnel deletion. A distinction needs to be made between the creation and deletion of a VLL tunnel, and the establishment and termination of a tunnel instance. The creation of a VLL tunnel is a configuration operation, whereby the information needed to dynamically establish a tunnel (e.g. the remote IP end point) is installed. Similarly the deletion of such a VLL tunnel is a configuration operation that removes this information. The establishment of a tunnel instance occurs as a result of a signalling exchange, with parameters being transferred (e.g. the value of the multiplexing field) and any needed resources being put in place. This may occur immediately the VLL tunnel is created, or a data-driven approach could be used, whereby the tunnel instance is only established when there is some data to be transferred. Also the tunnel instance could be maintained until VLL tunnel deletion, whether or not it was being used, or it could be terminated due to an idle timeout, and re-established whenever there was subsequently data ready for transfer. The latter approach may be useful if resources are being allocated for traffic management purposes, to avoid dedicating resources for inactive tunnel Gleeson et al. [Page 9] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 instances. 5.1.7 Support for Large MTUs Since the traffic sent through a VLL may often be opaque to the underlying IP backbone, it cannot also generally be assumed that the maximum transfer unit (MTU) of the VLL itself, is less than or equal to that of the MTU of the particular route of the VLL across the IP backbone. As such, the VLL tunneling mechanism may need mechanisms to allow for frame fragmentation, either within the tunnel, or at the IP level. If the frame to be transferred is mapped into one IP datagram, normal IP fragmentation mechanisms can be used. There may also be value in defining fragmentation techniques that operate at the tunnel level (using the tunnel sequence number and an end-of-message marker of some sort) in order to avoid IP level fragmentation. This subject is for further study. 5.1.8 Minimization of Tunnel Overhead There is clearly benefit in minimizing the overhead of VLL tunneling mechanisms. This is particularly important for the transport of small, jitter and latency sensitive traffic such as packetized voice and video. On the other hand, the use of security mechanisms, such as IPSec, do impose their own overhead, hence the objective should be to minimize overhead over and above that needed for security, and to not burden those VLLs in which security is not mandatory with unnecessary overhead. 5.1.9 Flow and congestion control issues Of the existing tunneling schemes only L2TP has procedures for flow and congestion control. These were necessitated in part due to the need to provide adequate performance over lossy networks when PPP compression (which, unlike the IP Payload Compression Protocol (IPComp) [Shacham], is stateful across packets) is being used, and to accommodate devices with very little buffering. The flow and congestion control mechanisms used with L2TP are largely specific to the use of PPP and devices that terminate low speed dial-up lines. More analysis is needed to see if any flow and congestion control mechanisms should be incorporated into a generic IP tunneling protocol. For TCP traffic, the end-to-end flow and congestion control provided by TCP itself will generally suffice. Good flow and congestion control schemes, that can adapt to a wide variety of network conditions and deployment scenarios are complex to develop and test, both in themselves and in understanding the interaction Gleeson et al. [Page 10] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 with other schemes (e.g. TCP's) that may be running in parallel. There may be some benefit, however, in having the capability whereby a sender can shape traffic to the capacity of a receiver in some manner, and in providing the protocol mechanisms to allow a receiver to signal its capabilities to a sender. This area is for further study. 5.1.10 Traffic Management issues As noted above, customers may require that VLLs yield similar behavior to physical leased lines or dedicated connections with respect to such traffic management parameters as loss rates and latency and bandwidth guarantees. How such guarantees could be delivered will, in general, be a function of the traffic management characteristics of the VPN termination devices, and the access and backbone networks across which they are connected. However, it is likely that the most general solution would be to model a VLL as a logical link which extends across the backbone between two terminating devices. As such, all of the capabilities currently being developed and deployed for traffic management, including link sharing, differentiated services [Bernet] and fair scheduling could also be applied to the VLL. The specific capabilities that may be needed from VLL tunneling mechanisms to support such requirements is for further study. It will be noted, however, that this proposed model of tunnel operation may not wholly consistent with the way in which specific tunneling protocols are currently modeled. In particular, it is unclear whether an IPSec tunnel is considered in the current IPSec architecture to be an interface, per se, or an attribute of a particular packet flow. 5.2 Specification Recommendations There is a need for a standard VLL tunneling mechanism, that addresses each of the requirements discussed above. Given the necessity for strong encryption and strong authentication capabilities it would appear that a modification of IKE/IPSec may well be the optimal choice, particularly for non-MPLS based networks, since in addition to addressing the need for secure tunnels, it already has well defined signaling and multiplexing capabilities which can be readily amended for the specific needs of VLLs. To minimize overhead, including the overhead of configuration, control state, and processing cycles, as well as extra header fields added to a data packet, it also seems advantageous to converge on the use of a single signalling protocol and associated data encapsulation, rather Gleeson et al. [Page 11] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 than use multiple protocols in parallel (e.g. IKE/IPSec and L2TP). However the use of IPSec as a VPN tunneling mechanism may require amendments to the envisaged model of IPSec usage implicit in the current IPSec architecture. A future draft will discuss these amendments in greater detail. Note that parallel work is also underway in the MPLS WG on MPLS-based tunneling mechanisms as discussed in [Heinanen2]. 6.0 VPN Types: Virtual Private Routed Networks A virtual private routed network (VPRN) is defined to be the emulation of a multi-site wide area routed network using IP facilities. This section looks at how a network-based VPRN service can be provided. CPE-based VPRNs are also possible, but are not specifically discussed here. With network-based VPRNs many of the issues that need to be addressed are concerned with configuration and operational issues, which must take into account the split in administrative responsibility between the service provider (ISP) and the service user (customer). A VPRN consists of a mesh of IP tunnels between ISP routers, together with the routing capabilities needed to forward traffic received at each VPRN site to the appropriate destination site. Attached to these ISP routers are CPE routers connected via one or more links, termed 'stub' links. This is illustrated in the following diagram, which shows 3 ISP edge routers connected via a full mesh of IP tunnels, used to interconnect 4 CPE routers. One of the CPE routers is multihomed to the ISP network. In the multihomed case, all stub links may be active, or, as shown, there may be one primary and one or more backup links to be used in case of failure of the primary. The term 'backdoor' link is used to refer to a link between two customer sites that does not traverse the ISP network. Gleeson et al. [Page 12] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 +--------+ +--------+ +---+ | ISP | | ISP | +---+ |CPE|-------| edge |-----------------------| edge |------|CPE| +---+ | router | IP tunnel | router | +---+ stub +--------+ +--------+ stub : link | | | link : | | | : | | IP BACKBONE | : | | | : | |IP tunnel IP tunnel| : | | +--------+ | : | | | ISP | | : | +-----------| edge |-----------+ : | | router | : backup| +--------+ backdoor: link | | | link : | stub link | | stub link : | | | : | +---+ +---+ : +-------------|CPE| |CPE|......................: +---+ +---+ The principal benefit of a VPRN is that the configuration of the CPE router is simplified. To a CPE router, the ISP edge router appears as a neighbour router in the customer's network, to which it sends all traffic for non-local VPRN destinations. The tunnel mesh that is set up to transfer traffic extends between the ISP edge routers, not the CPE routers. In effect the burden of tunnel establishment and maintenance and routing configuration is outsourced to the ISP. This is in contrast to the scenario where the tunnel mesh extends to the CPE routers. In this case the ISP network provides layer 2 connectivity alone. This can be implemented either as a set of VLLs between CPE routers, in which case the ISP network provides a set of layer 2 point-to-point links, or as a Virtual Private LAN Segment (VPLS) (see section 8.0), in which case the ISP network is used to emulate a multiaccess LAN segment. With these scenarios a customer may have more flexibility (e.g. any IGP or any protocol can be run across all customer sites) but this usually comes at the expense of a more complex configuration for the customer. Thus, depending on customer requirements, a VPRN or a VPLS may be the more appropriate solution. Because a VPRN carries out forwarding at the network layer, a single VPRN only directly supports a single network layer protocol. For multiprotocol support, a separate VPRN for each network layer Gleeson et al. [Page 13] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 protocol could be used, or one protocol could be tunneled over another (e.g. non-IP protocols tunneled over an IP VPRN) or alternatively the ISP network could be used to provide layer 2 connectivity only, such as with a VPLS as mentioned above. The issues to be addressed for VPRNs include initial configuration, determination of the set of routers that have members in a VPRN, determination by an ISP edge router of the set of IP address prefixes reachable via each stub link, determination by a CPE router of the set of IP address prefixes to be forwarded to an ISP edge router, the mechanism used to disseminate stub reachability information to the correct set of ISP routers, and the establishment and use of the tunnels used to carry the data traffic. Note also that, although discussed first for VPRNs, many of these issues also apply to the VPLS scenario described later, with the network layer addresses being replaced by link layer addresses. Note that VPRN operation is decoupled from the mechanisms used by the customer sites to access the Internet. A typical scenario would be for the ISP edge router to be used for both VPRN and Internet connectivity. In this case the CPE router would have a default route pointing to the ISP edge router. However a customer site could have Internet connectivity via an ISP router not involved in the VPRN, or even via a different ISP. In this case, for VPRN traffic, the CPE router would have a route (or set of routes) for all non-local VPRN destinations, pointing to the ISP edge router. This is termed a 'VPRN default route', and is used where necessary in contrast to 'default route' which refers to all non-local destinations (including both non-local VPRN destinations and external Internet destinations). VPRN requirements and mechanisms have been discussed previously in [Heinanen2], with a particular focus in that Draft showing how the same VPRN functionality can be implemented over both MPLS and non- MPLS networks. A. Topology The topology of a VPRN may consist of a full mesh of tunnels between each VPRN site, or may be an arbitrary topology, such as a set of remote offices connected to the nearest central site, with these central sites connected together via a full or partial mesh. With VPRNs there is much less cost assumed with full meshing than in cases where physical resources (e.g. Frame Relay DLCI or a leased line) must be allocated for each connected pair of sites. This yields optimal routing, since it precludes the need for traffic between two sites to traverse through a third. One attraction of a full mesh topology is that there is no need to configure topology information for the VPRN. Instead, given the member routers of a VPRN, the Gleeson et al. [Page 14] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 topology is implicit. If the number of ISP edge routers in a VPRN is very large, however, a full mesh topology may not be appropriate, due to the scaling issues involved, for example, the growth in the number of tunnels needed between sites, (which for n sites is n(n-1)/2), or the number of routing peers per router. Network policy may also lead to non full mesh topologies, for example an administrator may wish to set up the topology so that traffic between two remote sites passes through a central site, rather than go directly between the remote sites. It is also necessary to deal with the scenario where there is only partial connectivity across the IP backbone under certain error conditions (e.g. A can reach B, and B can reach C, but A cannot reach C directly), which can occur if policy routing is being used. For a network-based VPRN, it is assumed that each customer site CPE router connects to an ISP edge router through one or more dedicated point-to-point stub links (e.g. leased lines, ATM or Frame Relay connections). The ISP routers are responsible for learning and disseminating reachability information amongst themselves. The CPE routers must learn the set of destinations reachable via each stub link, though this may be as simple as a default route. B. Addressing The addressing used within a VPRN may have no relation to the addressing used on the IP backbone over which the VPRN is instantiated. In particular non-unique private IP addressing may be used [Rekhter1]. Multiple VPRNs may be instantiated over the same set of physical devices, and they may use the same or overlapping address spaces. C. Forwarding For a VPRN the tunnel mesh forms an overlay network operating over an IP backbone. Within each of the ISP edge routers there must be VPN specific forwarding mechanisms to forward packets received from stub links ('ingress traffic') to the appropriate next hop router, and to forward packets received from the core ('egress traffic') to the appropriate stub link. For cases where a ISP edge router supports multiple stub links belonging to the same VPRN, the tunnels can, as a local matter, either terminate on the edge router, or on a stub link. In the former case a VPN specific forwarding table is needed for egress traffic, in the latter case it is not. A VPN specific forwarding table is generally needed in the ingress direction, in order to direct traffic received on a stub link onto the correct IP tunnel towards the core. Also since a VPRN operates at the internetwork layer, the IP packets send over a tunnel will have their TTL field decremented in the Gleeson et al. [Page 15] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 normal manner, preventing packets circulating indefinitely in the event of a routing loop within the VPRN. D. Multiple concurrent VPRN connectivity Note also that a single customer site may belong concurrently to multiple VPRNs and may want to transmit traffic both onto one or more VPRNs and to the default Internet, over the same stub link. There are a number of possible approaches to this problem, but these are outside the scope of the current Draft. 6.1 VPRN Generic Requirements There are a number of common requirements which any network-based VPRN solution must address, and there are a number of different mechanisms that can be used to meet these requirements. These generic issues are - The use of a globally unique VPN identifier in order to be able to refer to a particular VPN. - VPRN membership determination. An edge router must learn of the other routers that have members in that VPRN. - Stub link reachability information. An edge router must learn the set of addresses and address prefixes reachable via each stub link. - Intra-VPRN reachability information. Once an edge router has determined the set of address prefixes associated with each of its stub links, then this information must be disseminated to each other edge router in the VPRN. - Tunneling mechanism. An edge router must construct the necessary tunnels to other routers that have members in the VPRN, and must perform the encapsulation and decapsulation necessary to send and receive packets over the tunnels. 6.1.1 VPN Identifier Network-based VPRNs may potentially span multiple autonomous systems (ASs) and multiple management domains. This implies the need for a VPN identifier than can be unique across multiple ASs. To that end, [Heinanen1] proposed a globally unique VPN identifier (note that such an identifier may be useful for VPN types other than VPRNs) made up of the concatenation of an AS number, and a label assigned by the AS administrator which is locally unique within the particular AS. This is one solution to the need for a globally unique VPN identifier used Gleeson et al. [Page 16] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 across public networks. Specifically a VPN ID could be coded as a four octet BGP Communities Attribute [Chandra], made up of a two octet AS number and a 2 octet, unstructured integer VPN number, to allow for sufficient numbers of VPNs per AS. Note that where a VPN crosses multiple ASs, then there must be some administrative mechanisms to coordinate VPN ID assignment e.g. through the notion of a 'home AS' for a particular VPN, which is used in the VPN ID of that VPN. A VPN ID coded as proposed could also be easily piggybacked in BGP, and could also be easily specified within BGP policy filters in AS border routers for scoping and administrative purposes. In other environments where VPRN functionality is required, but where using an AS number is not convenient (because the VPRN functionality is being provided on private IP backbone facilities, for example), an Organizationally Unique Identifier (OUI), could be used instead of an AS number. This is a 3 octet number, assigned by the IEEE. With the addition of a locally assigned 2 octet VPN number this would form a 5 octet VPN identifier. Note that the intent of the VPN ID is that it be used in configuration and control messages in order to refer to a particular VPN. There is a also a need to be able to associate a data packet received on a tunnel with a particular VPN, however the VPN ID is not intended to be used for this purpose, since including an extra 4 or 5 byte quantity with every data packet transmitted is neither efficient or necessary. Instead a tunnel specific multiplexing field is used for that purpose. For example an IPSec tunnel uses the SPI field, an L2TP tunnel uses the call-id field, and an MPLS tunnel uses the MPLS label. There is a need for a standard VPN identifier. This could use the OUI format described above, or could be a hybrid which allows both an AS or an OUI to be used, or perhaps some other method. The ATM Forum also have a similar problem to solve, and ideally a single mechanism should be used for both cases. For the remainder of this draft it is assumed that such a globally unique VPN identifier exists. 6.1.2. VPN Membership Information Configuration and Dissemination In order to establish a VPRN, or to insert new customer sites into an established VPRN, the stub links on each edge router from those sites in the particular VPRN must first be configured with the identity of the particular VPRN to which the stub links belong. Note that this first step of stub link configuration is unavoidable, since clearly the edge router cannot infer such bindings and hence must be Gleeson et al. [Page 17] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 configured with this information. A management information base (MIB) allowing for bindings between local stub links and VPN identities is one solution. Thereafter, each edge router must learn either the identity of, or, at least, the route to, each other edge router supporting other stub links in that particular VPRN. Implicit in the latter is the notion that there exists some mechanism by which the configured edge routers can then use this edge router and/or stub link identity information to subsequently set up the appropriate tunnels between them; this is discussed further below. In order to configure each stub link with the identity of the VPN to which it belongs, a VPN identifier is required (see 6.1.1); the scope of uniqueness of this identifier is a function of its usage, which is related to how VPRN membership is disseminated. This problem, of VPRN member dissemination between participating edge routers, can be solved in a variety of ways, discussed below. A. Directory Lookup: The members of a particular VPRN, that is, at a minimum, the identity of the edge routers supporting stub links in the VPRN, and possibly also the identity of each of the stub links, could be configured into a directory, which edge routers could query, using some defined mechanism (e.g. LDAP), upon configuration of their local stub interfaces and VPN identifier. Using a directory allows either a full mesh topology or an arbitrary topology to be configured. For a full mesh, the full list of member routers in a VPRN is distributed everywhere. For an arbitrary topology, different routers may receive different member lists. Using a directory allows for authorization checking prior to disseminating VPRN membership information, which may be desirable where VPRNs span multiple administrative domains. In such a case, directory to directory protocol mechanisms could also be used to propagate authorized VPRN membership information between the directory systems of the multiple administrative domains. There would also need to be some form of database synchronization mechanism (e.g. triggered or regular polling of the directory by edge routers, or active pushing of update information to the edge routers by the directory) in order for all edge routers to learn the identity of newly configured sites inserted into an active VPRN, and also to learn of sites removed from a VPRN. B. Explicit Management Configuration: Gleeson et al. [Page 18] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 A VPRN Management Information Base (MIB) could be defined which would allow a central management system to configure each edge router with the identities of each other participating edge router and possibly also the identity of each of the stub links. Similar mechanisms could also be used, as noted above, to configure the VPN bindings of the local stub links on the edge router. Like the use of a directory, this mechanism allows both full mesh and arbitrary topologies to be configured. Note that this mechanism allows the management station to impose strict authorization control; on the other hand, it may be more difficult to configure edge routers outside the scope of the management system. The management configuration model can also be considered a subset of the directory method, in that the (management) directories could use MIBs to push VPRN membership information to the participating edge routers, either subsequent to, or as part of, the local stub link configuration process. C. Piggybacking in Routing Protocols: VPRN membership information could be piggybacked into the routing protocols run by each edge router across the IP backbone, since this is an efficient means of automatically propagating information throughout the network to other participating edge routers. Specifically, each route advertisement by each edge router could include, at the minimum, the set of VPN identifiers associated with each edge router, and adequate information to allow other edge routers to determine the identity of, and/or, the route to, the particular edge router. Other edge routers would examine received route advertisements to determine if any contained information was relevant to a supported (i.e. configured) VPRN; this determination could be done by looking for a VPN identifier matching a locally configured VPN. The nature of the piggybacked information, and related issues, such as scoping, and the means by which the nodes advertising particular VPN memberships will be identified, will generally be a function both of the routing protocol and of the nature of the underlying transport, and is discussed further in Appendix A. Using this method all the routers in the network will have the same view of the VPRN membership information, and so a full mesh topology is easily supported. Supporting an arbitrary topology is more difficult, however, since some form of pruning would seem to be needed. The advantage of the piggybacking scheme is that it allows for very efficient information dissemination, particularly across multiple routing domains (e.g. across different autonomous systems/ISPs) but Gleeson et al. [Page 19] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 it does require that all nodes in the path, and not just the participating edge routers, be able to accept such modified route advertisements. On the other hand, significant administrative complexity may be required to configure scoping mechanisms so as to both permit and constrain the dissemination of the piggybacked advertisements, and in itself this may be quite a configuration burden. Furthermore, unless some security mechanism is used for routing updates so as to permit only all relevant edge routers to read the piggybacked advertisements, this scheme generally implies a trust model where all routers in the path must perforce be authorized to know this information. Depending upon the nature of the routing protocol, piggybacking may also require intermediate routers, particularly autonomous system (AS) border routers, to cache such advertisements and potentially also re-distribute them between multiple routing protocols. Each of the schemes described above have merit in particular situations. Note that, in practice, there will almost always be some directory or management system which will maintain VPRN membership information, since, as noted above, the binding of VPRNs to stub links must be configured, hence, presumably, such information would be obtained from, and stored within, some database. Hence the additional steps to facilitate the configuration of such information into edge routers, and/or, facilitate edge router access to such information, may not be excessively onerous. 6.1.3 Stub Link Reachability Information There are two aspects to stub site reachability - the means by which VPRN edge routers determine the set of VPRN addresses and address prefixes reachable at each stub site, and the means by which the CPE routers learn the destinations reachable via each stub link. A number of common scenarios are outlined below. In each case the information needed by the ISP edge router is the same - the set of VPRN addresses reachable at the customer site, but the information needed by the CPE router differs. 1. The CPE router is connected via one link to an ISP edge router, which provides both VPRN and Internet connectivity. This is the simplest case for the CPE router, as it just needs a default route pointing to the ISP edge router. 2. The CPE router is connected via one link to an ISP edge router, which provides VPRN, but not Internet, connectivity. Gleeson et al. [Page 20] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 The CPE router must know the set of non-local VPRN destinations reachable via that link - the VPRN default route. This may be a single prefix, or may be a number of disjoint prefixes. The CPE router may be either statically configured with this information, or may learn it dynamically by running an instance of an IGP. For simplicity it is assumed that the IGP used for this purpose is RIP, though it could be any IGP. The ISP edge router will inject into this instance of RIP the VPRN default route, which it learns by means of one of the intra-VPRN reachability mechanisms described in section 6.1.4. Note that the instance of RIP run to the CPE, and any instance of a routing protocol used to learn intra-VPRN reachability (even if also RIP) are separate, with the ISP edge router redistributing the routes from one instance to another. 3. The CPE router is multihomed to the ISP network, which provides VPRN connectivity. In this case all the ISP edge routers could advertise the same VPRN default route to the CPE router, which then sees all VPRN prefixes equally reachable via all links. More specific route redistribution is also possible, whereby each ISP edge router advertises specific prefixes (perhaps the ones locally connected) in addition to, or with more favoured metrics than, the VPRN default route. 4. The CPE router is connected to the ISP network, which provides VPRN connectivity, but also has a backdoor link to another customer site In this case the ISP edge router will advertise the VPRN default route as in case 2. However now the same destination is reachable via both the ISP edge router and via the backdoor link. If the CPE routers connected to the backdoor link are running the customer's IGP, then the backdoor link may always be the favoured link as it will appear an an 'internal' path, whereas the destination as injected via the ISP edge router will appear as an 'external' path (to the customer's IGP). To avoid this problem, assuming that the customer wants the traffic to traverse the ISP network, then a separate instance of RIP should be run between the CPE routers at both ends of the backdoor link, in the same manner as an instance of RIP is run on a stub or backup link between a CPE router and an ISP edge router. This will then also make the backdoor link appear as an external path, and by adjusting the link costs appropriately, the ISP path can always be favoured, unless it goes down, when the backdoor link is then used. The description of the above scenarios covers what reachability information is needed by the ISP edge routers and the CPE routers, and discusses some of the mechanisms used to convey this information. Gleeson et al. [Page 21] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 The sections below look at these mechanisms in more detail. A. Routing Protocol Instance: A routing protocol can be run between the CPE edge router and the ISP edge router to exchange reachability information. This allows an ISP edge router to learn the VPRN prefixes reachable at a customer site, and also allows a CPE router to learn the destinations reachable via its stub links. The extent of the routing domain for this protocol instance is generally just the ISP edge router and the CPE router although if the customer site is also running the same protocol as its IGP, then the domain may extend into customer site. If the customer site is running a different routing protocol then the CPE router redistributes the routes between the instance running to the ISP edge router, and the instance running into the customer site. Given the typically restricted scope of this routing instance, a simple protocol will generally suffice. RIPv2 [Malkin] is likely to be the most common protocol used, though any routing protocol, such as OSPF [Moy], or BGP-4 [Rekhter2] run in internal mode (IBGP), could also be used. Note that the instance of the stub link routing protocol is different from any instance of a routing protocol used for intra-VPRN reachability. For example, if the ISP edge router uses routing protocol piggybacking to disseminate VPRN membership and reachability information across the core, then it may redistribute suitably labeled routes from the CPE routing instantiation to the core routing instantiation. The routing protocols used for each instantiation are decoupled, and any suitable protocol can be used in each case. There is no requirement that the same protocol, or even the same stub link reachability information gathering mechanism, be run between each CPE router and associated ISP edge router in a particular VPRN, since this is a purely local matter. This decoupling allows ISPs to deploy a common (across all VPRNs) intra-VPRN reachability mechanism, and a common stub link reachability mechanism, with these mechanisms isolated both from each other, and from the particular IGP used in a customer network. In the first case, due to the IGP-IGP boundary implemented on the ISP edge router, the ISP can insulate the intra-VPRN reachability mechanism from misbehaving stub link protocol instances. In the second case the ISP is not required to be aware of the particular IGP running in a customer site. Other scenarios are possible, where the ISP edge routers are running a routing protocol in the same instance as the customer's IGP, but are unlikely to be practical, since it defeats Gleeson et al. [Page 22] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 the purpose of a VPRN simplifying CPE router configuration. In cases where a customer wishes to run an IGP across multiple sites, a VPLS solution is more suitable. Note that if a particular customer site concurrently belongs to multiple VPRNs (or wishes to concurrently communicate with both a VPRN and the Internet), then the ISP edge router must have some means of unambiguously mapping stub link address prefixes to particular VPRNs. A simple way is to have multiple stub links, one per VPRN. It is also possible to run multiple VPRNs over one stub link. This could be done either by ensuring (and appropriately configuring the ISP edge router to know) that particular disjoint address prefixes are mapped into separate VPRNs, or by tagging the routing advertisements from the CPE router with the appropriate VPN identifier. For example if MPLS was being used to convey stub link reachability information, different MPLS labels would be used to differentiate the disjoint prefixes assigned to particular VPRNs. In any case, some administrative procedure would be required for this coordination. B. Configuration: The reachability information across each stub link could be manually configured, which may be appropriate if the set of addresses or prefixes is small and static. C. ISP Administered Addresses: The set of addresses used by each stub site could be administered and allocated via the VPRN edge router, which may be appropriate for small customer sites. In such a case the ISP edge router could determine these addresses by proxying for the particular address administration mechanism (e.g. DHCP). Note that in this case it would be the responsibility of the address allocation mechanism to ensure that each site in the VPN received a disjoint address space. Note also that an ISP would typically only use this mechanism for small stub sites, which are unlikely to have backdoor links. D. MPLS Label Distribution Protocol: In cases where the CPE router runs MPLS, the MPLS LDP could be extended to convey the set of prefixes at each stub site, together with the appropriate labeling information. While LDP is not generally considered a routing protocol per se, it may be useful to extend it for this particular constrained scenario. This is for further study. Gleeson et al. [Page 23] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 6.1.4 Intra-VPN Reachability Information Once an edge router has determined the set of prefixes associated with each of its stub links, then this information must be disseminated to each other edge router in the VPRN. Note also that there is an implicit requirement that the set of reachable addresses within the VPRN be locally unique that is, each VPRN stub link (not performing load sharing) maintain an address space disjoint from any other, so as to permit unambiguous routing. In practical terms, it is also generally desirable, though not required, that this address space be well partitioned i.e. specific, disjoint address prefixes per stub link, so as to preclude the need to maintain and disseminate large numbers of host routes. The intra-VPN reachability information dissemination can be solved in a number of ways, some of which include the following: A. Directory Lookup: Along with VPRN membership information, a central directory could maintain a listing of the address prefixes associated with each end point. Such information could be obtained by the server through protocol interactions with each edge router. Note that the same directory synchronization issues discussed above would apply in this case. B. Explicit Configuration: The address spaces associated with each edge router could be explicitly configured into each other router. This is clearly a non- scalable solution, particularly when arbitrary topologies are used, and also raises the question of how the management system learns such information in the first place. C. Local Intra-VPRN Routing Instantiations: In this approach, each edge router runs an instantiation of a routing protocol (a 'virtual router') per VPRN, running across the VPRN tunnels to each peer edge router, to disseminate intra-VPRN reachability information. Both full-mesh and arbitrary VPRN topologies can be easily supported, since the routing protocol itself can run over any topology. The intra-VPRN routing advertisements could be distinguished from normal tunnel data packets either by being addressed directly to the peer edge router, or by a tunnel specific mechanism. Note that this intra-VPRN routing protocol need have no relationship either with the IGP of each customer site or with the routing Gleeson et al. [Page 24] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 protocols operated by the ISPs in the IP backbone. Specifically, the intra-VPRN routing protocol operates as an overlay over the IP backbone, and could be a simple protocol, such as RIPv2 [Malkin], at least unless the VPRN spans a very large number of edge routers. Since the intra-VPN routing protocol runs as an overlay, it is also wholly transparent to any intermediate routers, and to any edge routers not within the VPRN. This also implies that such routing information can also remain opaque to such routers, which may be a necessary security requirements in some cases. If the tunnels over which an intra-VPRN routing protocol runs are dedicated to a specific VPN (e.g. a different multiplexing field is used for each VPN) then no changes are needed to the routing protocol itself. On the other hand if shared tunnels are used, then it is necessary to extend the routing protocol to allow a VPN-ID field to be included in routing update packets, to allow sets of prefixes to be associated with a particular VPN. D. Link Reachability Protocol Given a full mesh topology, each edge router could run a link reachability protocol - for instance, some variation of the MPLS LDP - across the tunnel to each peer edge router in the VPRN, carrying the VPN ID and the reachability information of each VPRN running across the tunnel between the two edge routers. The specification of such a protocol would need to include aspects of current routing protocols such as hello protocols, and re-transmit timers and/or positive acknowledgements. However, such an approach may reduce the processing burden of running routing protocol instantiations per VPRN, and may be of particular benefit where a shared tunnel mechanism is used to connect a set of edge routers supporting multiple VPRNs. Another approach to a link reachability protocol would be to base it on IBGP. The problem that needs to be solved by a link reachability protocol is very similar to that solved by IBGP - conveying address prefixes reliably between edge routers. Using a link reachability protocol it is straightforward to support a full mesh topology - each edge router conveys its own local reachability information to all other routers, but does not redistribute information received from any other router. However once an arbitrary topology needs to be supported, the link reachability protocol in effect develops into a full routing protocol, due to the need to implement mechanisms to avoid loops, and the issues discussed in section 6.1.4C above, apply. E. Piggybacking in IP Backbone Routing Protocols: Gleeson et al. [Page 25] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 As with VPRN membership, the set of address prefixes associated with each stub interface could also be piggybacked into the routing advertisements from each edge router and propagated through the network. Other edge routers would extract this information from received route advertisements in the same way as they would obtain the VPRN membership information (which, in this case, is implicit in the identification of the source of each route advertisement). Note that this scheme may require, depending upon the nature of the routing protocols involved, that intermediate routers, e.g. border routers, cache intra-VPRN routing information in order to propagate it further. This also has implications for the trust model, and for the level of security possible for intra-VPRN routing information. Note that in any of the cases discussed above, an edge router has the option of disseminating its stub link prefixes in a manner so as to permit tunneling from remote edge routers directly to the egress stub links. Alternatively, it could disseminate the information so as to associate all such prefixes with the edge router, rather than with specific stub links. In this case, the edge router would need to implement a VPN specific forwarding mechanism for egress traffic, to determine the correct egress stub link. The advantage of this is that it may significantly reduce the number of distinct tunnels or tunnel label information which need to be constructed and maintained. Note that this choice is purely a local manner and is not visible to remote edge routers. 6.1.5 Tunneling Mechanisms Once VPRN membership information has been disseminated, the tunnels comprising the VPRN can be constructed. One approach to setting up the tunnel mesh is to use point-to-point IP tunnels, and the requirements and issues for such tunnels are discussed in section 5.0, on VLLs. For example while tunnel establishment can be done through manual configuration, this is clearly not likely to be a scalable solution, given the o(n^2) problem of meshed links. As such, tunnel set up should use some form of signaling protocol which would allow two nodes to construct a tunnel to each other knowing only each other's identity. Another approach is to use the multipoint to point 'tunnels' provided by MPLS. As noted in [Heinanen1], MPLS can be considered to be a form of IP tunneling, since the labels of MPLS packets allow for routing decisions to be decoupled from the addressing information of the packets themselves. MPLS label distribution mechanisms can be used to associate specific sets of MPLS labels with particular VPRN address prefixes supported on particular egress points (i.e. stub Gleeson et al. [Page 26] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 links of edge routers) and hence allow other edge routers to explicitly label and route traffic to particular VPRN stub links. One attraction of MPLS as a tunneling mechanism is that it may require less processing within each edge router than alternative tunneling mechanisms. This is a function of the fact that data security within a MPLS network is implicit in the explicit label binding, much as with a connection oriented network, such as Frame Relay. This may hence lessen customer concerns about data security and hence require less processor intensive security mechanisms (e.g. IPSec). However there are other potential security concerns with MPLS. There is no direct support for security features such as authentication, confidentiality, and non-repudiation and the trust model for MPLS means that intermediate routers, (which may belong to different administrative domains), through which membership and prefix reachability information is conveyed, must be trusted, not just the edge routers themselves. 6.2 Multihomed Stub Routers The discussion thus far has implicitly assumed that stub routers are connected to one and only one VPRN edge router. In general, this restriction should be capable of being relaxed without any change to VPRN operation, given general market interest in multihoming for reliability and other reasons. In particular, in cases where the stub router supports multiple redundant links, with only one operational at any given time, with the links connected either to the same VPRN edge router, or to two or more different VPRN edge routers, then the stub link reachability mechanisms will both discover the loss of an active link, and the activation of a backup link. In the former situation, the previously connected VPRN edge router will cease advertising reachability to the stub node, while the VPRN edge router with the now active link will begin advertising reachability, hence restoring connectivity. An alternative scenario is where the stub node supports multiple active links, using some form of load sharing algorithm. In such a case, multiple VPRN edge routers may have active paths to the stub node, and may so advertise across the VPRN. This scenario should not cause any problem with reachability across the VPRN providing that the intra-VPRN reachability mechanism can accommodate multiple paths to the same prefix, and has the appropriate mechanisms to preclude looping - for instance, distance vector metrics associated with each advertised prefixes. This subject is for further study. Gleeson et al. [Page 27] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 6.3 Multicast Support Multicast and broadcast traffic can be supported across VPRN either by edge replication or by native multicast support in the backbone. These two cases are discussed below. 6.3.1 Edge Replication This is where each VPRN edge router replicates multicast traffic for transmission across each link in the VPRN. Note that this is the same operation that would be performed by CPE routers terminating actual physical links or dedicated connections. As with CPE routers, multicast routing protocols could also be run on each VPRN edge router to determine the distribution tree for multicast traffic and hence reduce unnecessary flood traffic. This could be done by running an instantiation of standard multicast routing protocols, e.g. Protocol Independent Multicast (PIM) [Estrin] or the Distance Vector Multicast Routing Protocol (DVMRP) [Waitzman], on and between each VPRN edge router, through the VPRN tunnels, in the same way that unicast routing protocols might be run at each VPRN edge router to determine intra-VPN unicast reachability, as discussed in Section 6.1.4. Alternatively, if a link reachability protocol was run across the VPRN tunnels for intra-VPRN reachability, then this could also be augmented to allow VPRN edge routers to indicate both the particular multicast groups requested for reception at each edge node, and also the multicast sources at each edge site. In either case, there would need to be some mechanism to allow for the VPRN edge routers to determine which particular multicast groups were requested at each site and which sources were present at each site. How this could be done would, in general, be a function of the capabilities of the CPE stub routers at each site. If these could also run multicast routing protocols, then these could interact directly with the equivalent protocols at each VPRN edge router, else they could forward the Internet Group Management Protocol (IGMP) [Fenner] packets to the VPRN edge router for appropriate processing. 6.3.2 Native Multicast Support This is where VPRN edge routers map intra-VPN multicast traffic onto a native IP multicast distribution mechanism across the backbone. Note that the latter is not synonymous with the use of native multicast mechanisms per se - e.g. the use of IP multicast across the backbone - since intra-VPN multicast has the same requirements for isolation from general backbone traffic as intra-VPRN unicast traffic. Currently the only IP tunneling mechanism that has native support for multicast is MPLS. On the other hand, while MPLS supports native transport of IP multicast packets, additional Gleeson et al. [Page 28] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 mechanisms would be needed to leverage these mechanisms for the support of intra-VPN multicast. For instance, each VPRN router could prefix multicast group addresses within each VPRN with the VPN ID of that VPRN and then redistribute these, essentially treating this VPN ID/intra-VPRN multicast address tuple as a normal multicast address, within the backbone multicast routing protocols, as with the case of unicast reachability, as discussed previously. The MPLS multicast label distribution mechanisms could then be used to set up the appropriate multicast LSPs to interconnect those sites within each VPRN supporting particular multicast group addresses. Note, however, that this would require each of the intermediate LSRs to not only be aware of each intra-VPRN multicast group, but also to have the capability of interpreting these modified advertisements. Alternatively, mechanisms could be defined to map intra-VPRN multicast groups into backbone multicast groups. The details of such mechanisms are for further study. Other IP tunneling mechanisms do not have native multicast support. It may prove feasible to extend such tunneling mechanisms by allocating IP multicast group addresses to the VPRN as a whole and hence distributing intra-VPRN multicast traffic encapsulated within backbone multicast packets. Edge VPRN routers could filter out unwanted multicast groups. Alternatively, mechanisms could also be defined to allow for allocation of backbone multicast group addresses for particular intra-VPRN multicast groups, and to then utilize these, through backbone multicast protocols, as discussed above, to limit forwarding of intra-VPRN multicast traffic only to those nodes within the group. The details of such mechanisms are for further study. A particular issue with the use of native multicast support is the provision of security for such multicast traffic. Unlike the case of edge replication, which inherits the security characteristics of the underlying tunnel, native multicast mechanisms will need to use some form of secure multicast mechanism. At present, most aspects of such mechanisms, for instance using IPSec, are not wholly specified [Wallner] and further study will likely be needed before secure native multicast mechanisms can be generally deployed. 6.4 Specification Recommendations There have already been proposals for adapting routing protocols to carry VPN information to support the router piggybacking mechanisms [Heinanen1], particularly in MPLS networks. Some ISPs, however, may prefer schemes that do not couple VPN membership and reachability Gleeson et al. [Page 29] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 mechanisms with the backbone routing protocols, hence a set of mechanisms that do not require piggybacking should also be standardized. In particular the following are needed - a standard format for a globally unique VPN identifier. - a membership distribution protocol based on a directory or MIB. Also for the constrained case of a full mesh topology, the usefulness of developing a link reachability protocol could be examined. Extending routing protocols to allow a VPN-ID to carried in routing update packets could also be examined, but is not necessary if VPN specific tunnels are used. Note also that the MPLS WG group is working on MPLS-specific mechanisms for VPRNs [Heinanen2]. 7.0 VPN Types: Virtual Private Dial Networks A virtual private dial network (VPDN) allows for remote users to connect on demand into remote sites through ad hoc tunnels. The distinguishing characteristic of such ad hoc connections is their binding between a particular user and a central site. As such, user authentication, through whatever means, is a prime requirement. Most such connections are made today through dial connections made through the PSTN, with users setting up PPP connections across an access network to a Network Access Server (NAS), at which point the PPP sessions are authenticated using AAAA systems running such standard protocols as RADIUS [Rigney]. Given the pervasive deployment of such systems, any VPDN system must practically allow for the near transparent re-use of such existing systems. There has been significant work completed on the Layer 2 Tunneling Protocol (L2TP) [Valencia1], building upon the earlier PPTP [Zorn] and L2F [Valencia2] protocols. L2TP allows for the extension of user PPP sessions from a L2TP access concentrator (LAC) to a remote L2TP network server (LNS). Notwithstanding, however, the widespread industry support for L2TP, there are two quite different VPDN scenarios, which may call for different solutions. 7.1 Compulsory Tunneling Compulsory tunneling refers to a case in which a network node - a dial or network access server, for instance - acting as a LAC, extends a PPP session across a backbone using L2TP to a remote LNS. Gleeson et al. [Page 30] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 This operation is transparent to the user initiating the PPP session to the LAC. Support of this scenario was the original intent of the L2F specification, upon which the L2TP specification was based. Compulsory tunneling was originally intended for deployment on dial access servers supporting VPDN or wholesale dial services, allowing for remote dial access through common facilities to an enterprise site, while precluding the need for the enterprise to deploy its own dial servers. More recently, compulsory tunneling mechanisms have also been proposed for evolving xDSL services [ADSL1], [ADSL2], which also seek to leverage the existing AAAA infrastructure. 7.1.1 Call Routing Call routing for compulsory tunnels requires that some aspect of the initial PPP call set up can be used to allow the LAC to determine the identity of the LNS. As noted in [Aboba1], these aspects can include the user identity, as determined through some aspect of the access network, including calling party number, or some attribute of the called party, such as the fully qualified domain name (FQDN) of the CHAP/PAP user name. 7.1.2 Security Mechanisms By allowing for the transparent extension of PPP from the user, through the LAC to the LNS, L2TP allows for the use of whatever security mechanisms, with respect to both connection set up, and data transfer, may be used with normal PPP connections. However this does not provide security for the L2TP control protocol itself. In this case L2TP could be further secured by running it over IPSec through IP backbones [Patel], or related mechanisms on non-IP backbones [Calhoun2]. The interaction of L2TP with AAAA systems for user authentication and authorization is a function of the specific means by which L2TP is used, and the nature of the devices supporting the LAC and the LNS. These issues are discussed in depth in [Aboba1]. The means by which the host determines the correct LAC to connect to, and the means by which the LAC determines which users to further tunnel, and the LNS parameters associated with each user, are outside the scope of the operation of VPDN, but may be addressed, by for instance, evolving Internet roaming specifications [Aboba2]. Gleeson et al. [Page 31] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 7.1.3 Traffic Management L2TP support a complex flow control scheme that can be requested by either party in order to minimize packet loss due to receiver congestion. Furthermore, L2TP, by transparently extending PPP, has inherent support for such PPP mechanisms as multi-link PPP [Sklower] and its associated control protocols [Richard], which allow for bandwidth on demand to meet user requirements. Beyond these capabilities, L2TP itself does not have any specific traffic management mechanisms. As noted also for VLLs, however, L2TP calls could be mapped into whatever underlying traffic management mechanisms may exist in the network, and there are proposals to allow for requests through L2TP signaling for specific differentiated services behaviors [Calhoun1]. 7.1.4 Call Multiplexing L2TP has inherent support for the multiplexing of multiple calls from different users over a single link. Between the same two IP endpoints, there can be multiple L2TP tunnels, as identified by a tunnel-id, and multiple calls within a tunnel, as identified by a call-id. 7.1.5 Address Management Since L2TP is designed to transparently extend PPP, it does not attempt to supplant the normal address assignment mechanisms associated with PPP. Hence, in general terms the host initiating the PPP session will be assigned addressing by the LNS using PPP procedures. This addressing may have no relation to the addressing used for communication between the LAC and LNS. The LNS will also need to support whatever forwarding mechanisms are needed to route traffic to and from the remote host. 7.1.6 Support for Large MTUs As with VLLs, it cannot be assumed that the MTU of the VPDN tunnel is necessarily less than or equal to that of the underling IP route, though the host may adjust the PPP payload MTU to preclude fragmentation. To this end, there are proposals to allow the use of MTU discovery for cases where the L2TP tunnel transports IP frames [Shea]. 7.2 Voluntary Tunnels A voluntary tunneling refers to cases where an individual host connects to a remote site using a tunnel originating on the host, Gleeson et al. [Page 32] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 with no involvement from intermediate network nodes. The PPTP specification, parts of which have been incorporated into L2TP, was based upon a voluntary tunneling model. The L2TP specification has support for voluntary tunneling, insofar as the LAC can be located on a host, not only on a network node. Note that such a host has two IP addresses - one for the LAC - LNS IP tunnel, and another, typically allocated via PPP, for the network to which the host is connecting. There has also been discussion, however, that PPP, and hence either L2TP or PPTP, may be unnecessary and excessively burdensome for voluntary tunnels, particularly when they need to be paired with IPSec for security purposes. It is proposed in [Gupta] that IPSec alone be used for voluntary tunnels, with the tunnels terminating on IPSec edge devices at the enterprise site. In this case IPSec will be used in tunnel mode, and the host will have two IP addresses, in a similar manner to the L2TP case. (Alternatively the host could use one IP address as the source IP address in both the inner and outer IP headers, with the gateway performing NAT before forwarding the inner header, after IPSec processing). The IPSec WG is currently examining this area, with the intent of developing authentication schemes tailored towards remote hosts, and to allow certain configuration parameters, such as the host's IP address and DNS server, to be configured via IKE. Using IPSec as the basis of a voluntary tunnel mechanism may yield a much lower overhead solution than the use of PPP and L2TP, but it does require either changes to host protocol stacks, or the use of host 'shims' to intercept and forward packets to VPDNs through IPSec. A number of proprietary solutions of the latter sort are currently commercially available, hence a standard mechanism may well be desirable. 7.3 Networked Host Support The current PPP based dial model assumes a host directly connected to a connection oriented dial access network. Recent work on new access technologies such a xDSL have attempted to replicate this model [ADSL], so as to allow for the re-use of existing AAAA systems. The proliferation of personal computers, printers and other network appliances in homes and small businesses, and the ever lowering costs of networks, however, are increasingly challenging the directly connected host model. Increasingly, most hosts will access the Internet through small, typically Ethernet, local area networks (LANs). Gleeson et al. [Page 33] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 There is hence interest in means of accommodating the existing AAAA infrastructure within service providers, whilst also supporting multiple networked hosts at each customer site. The principal complication with this scenario is the need to support the login dialogue, through which the appropriate AAAA information is exchanged. A number of proposals have been made to address this scenario: A. Extension of PPP to Hosts Through L2TP: A number of proposals (e.g. [ADSL1]) have been made to extend L2TP over Ethernet so that PPP sessions can run from networked hosts out to the network, in much the same manner as a directly attached host. B. Extension of PPP Directly to Hosts: There are also proposals to map PPP directly onto Ethernet ([Evarts], [Shieh1], [Shieh2]), and to use a broadcast mechanism to allow hosts to find appropriate access servers with which to connect. Presumably such servers could then further tunnel, if needed, the PPP sessions using L2TP or similar mechanism. C. Use of IPSec: The IPSec based voluntary tunneling mechanism discussed above is independent of either access method or PPP and hence could as easily be used with networked or directly connected hosts. All of these methods require either host protocol changes, but the former two do allow the continued use of the various ancillary mechanisms of PPP, including address allocation, autoconfiguration, etc, albeit at the cost of greater overhead. 7.4 Specification Recommendations The L2TP specifications are currently near finalization and hence are the clear choice for VPDNs using compulsory tunneling. Further study needs to be done, however, to determine the most appropriate solution for voluntary tunneling. On approach is a PPP based solution, running over L2TP or some other form of link emulation protocol for the networked host scenario. Another approach is an IPSec based mechanism, with extensions to IKE for necessary host configuration. In the latter case, it may be desirable to maximize commonality with any IPSec based VLL tunneling mechanism. Gleeson et al. [Page 34] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 8.0 VPN Types: Virtual Private LAN Segment 8.0 VPN Types: Virtual Private LAN Segment A virtual private LAN segment (VPLS) is the emulation of a LAN segment using Internet facilities. A VPLS can be used to provide what is sometimes known also as a transparent LAN service (TLS), which can be used to interconnect multiple stub CPE nodes, either bridges or routers, in a protocol transparent manner. A VPLS emulates a LAN segment over IP, in the same way as protocols such as LANE [ATMF1] emulate a LAN segment over ATM. The primary benefits of a VPLS are complete protocol transparency, which may be important both for multiprotocol transport and for regulatory reasons in particular service provider contexts. 8.1 VPLS Requirements Topologically and operationally a VPLS can be most easily modelled as being essentially equivalent to a VPRN, except that each VPLS edge node implements link layer bridging rather than network layer forwarding. As such, most of the VPRN tunneling and configuration mechanisms discussed previously can also be used for a VPLS, with the appropriate changes to accommodate link layer, rather than network layer, packets and addressing information. The following sections discuss the primary changes needed in VPRN operation to support VPLSs. 8.1.1 Tunneling Protocols The tunneling protocols employed within a VPLS could be exactly the same as those used within a VPRN, if the tunneling protocol permitted the transport of multiprotocol traffic. Since the primary tunneling protocols discussed thus far have this capability, this will be assumed below. 8.1.2 Multicast and Broadcast Support A VPLS needs to have a broadcast capability. This is needed both for broadcast frames, and for link layer packet flooding, where a unicast frame is flooded because the path to the destination link layer address is unknown. The address resolution protocols that run over a bridged network typically use broadcast frames (e.g. ARP). The same set of possible multicast tunneling mechanisms discussed earlier for VPRNs apply also to a VPLS, though the generally more frequent use of broadcast in VPLSs may increase the pressure for native multicast support that reduces, for instance, the burden of replication on VPLS edge nodes. Gleeson et al. [Page 35] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 8.1.3 VPLS Membership Configuration and Topology The configuration of VPLS membership is analogous to that of VPRNs since this generally requires only knowledge of the local VPN link assignments at any given VPLS edge node, and the identity of, or route to, the other edge nodes in the VPLS; in particular, such configuration is independent of the nature of the forwarding at each VPN edge node. As such, any of the mechanisms for VPN member configuration and dissemination discussed for VPRN configuration can also be applied to VPLS configuration. Also as with VPRNs, the topology of the VPLS could be easily manipulated by controlling the configuration of peer nodes at each VPLS edge node, assuming that the membership dissemination mechanism was such as to permit this. It is likely that typical VPLSs will be fully meshed, however, in order to preclude the need for traffic between two VPLS nodes to transit through another VPLS node, which would then require the use of the spanning tree protocol [IEEE] for loop prevention. 8.1.4 CPE Stub Node Types Unlike a VPLS in which the CPE nodes are assumed to be routers, a VPLS can support either bridges or routers as a CPE device. CPE routers would peer transparently across a VPLS with each other without requiring any router peering with any nodes within the VPLS. The same scalability issues that apply to a full mesh topology for VPRNs, apply also in this case, only that now the number of peering routers is potentially greater, since the ISP edge device is no longer acting as an aggregation point. With CPE bridge devices the broadcast domain encompasses all the CPE sites as well as the VPLS itself. There are severe scalability constraints in this case, due to the need for packet flooding, and the fact that any topology change in the bridged domain is not localized, but is visible throughout the domain. As such this scenario is generally only suited for non-routable protocols. The nature of the CPE impacts the nature of the encapsulation, addressing, forwarding and reachability protocols within the VPLS, and are discussed separately below. 8.1.5 Stub Link Packet Encapsulation A. Bridge CPE: In this case, packets sent to and from the VPLS across stub links are link layer frames, with a suitable access link encapsulation. The most common case is likely to be ethernet frames, using an Gleeson et al. [Page 36] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 encapsulation appropriate to the particular access technology, such as ATM, connecting the CPE bridges to the VPLS edge nodes. Such frames are then forwarded at layer 2 onto a tunnel used in the VPLS. As noted previously, this does mandate the use of an IP tunneling protocol which can transport such link layer frames. Note that this does not necessarily mandate, however, the use of a protocol identification field in each tunnel packet, since the nature of the encapsulated traffic (e.g. ethernet frames) could be indicated at tunnel setup. B. Router CPE: In this case, typically, CPE routers send link layer packets to and from the VPLS across stub links, destined to the link layer addresses of their peer CPE routers. Other types of encapsulations may also prove feasible in such a case, however, since the relatively constrained addressing space needed for a VPLS to which only router CPE are connected, could allow for alternative encapsulations, as discussed further below. 8.1.6 CPE Addressing and Address Resolution A. Bridge CPE: Since a VPLS operates at the link layer, all hosts within all stub sites, in the case of bridge CPE, will typically be in the same network layer subnet. (Multinetting, whereby multiple subnets operate over the same LAN segment, is possible, but much less common). Frames are forwarded across and within the VPLS based upon the link layer addresses - e.g. IEEE MAC addresses - associated with the individual hosts. The VPLS needs to support broadcast traffic, such as that typically used for the address resolution mechanism used to map the host network addresses to their respective link addresses. The VPLS forwarding and reachability algorithms also need to be able to accommodate flooded traffic. B. Router CPE: A single network layer subnet is generally used to interconnect router CPE devices, across a VPLS. Behind each CPE router are hosts in different network layer subnets. CPE routers transfer packets across the VPLS by mapping next hop network layer addresses to the link layer addresses of a router peer. A link layer encapsulation is used, most commonly ethernet, as for the bridge case. As noted above, however, in cases where all of the CPE nodes connected to the VPLS are routers, then it may be possible, due to the constrained addressing space of the VPLS, to use encapsulations Gleeson et al. [Page 37] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 that use a different address space than normal MAC addressing. See, for instance, [Jamieson], for a proposed mechanism for VPLSs over MPLS networks, leveraging earlier work on VPRN support over MPLS [Heinanen1], which proposes MPLS as the tunneling mechanism, and locally assigned MPLS labels as the link layer addressing scheme to identify the CPE LSR routers connected to the VPLS. 8.1.7 VPLS Edge Node Forwarding and Reachability Mechanisms A. Bridge CPE: The only practical VPLS edge node forwarding mechanism in this case is likely to be standard link layer packet flooding and MAC address learning, as per [IEEE]. As such, no explicit intra-VPLS reachability protocol will be needed, though there will be a need for broadcast mechanisms to flood traffic, as discussed above. In general, it may not prove necessary to also implement the spanning tree protocol [IEEE] between VPLS edge nodes, if the VPLS topology is such that no VPLS edge node is used for transit traffic between any other VPLS edge nodes - in other words, where there is both full mesh connectivity and transit is explicitly precluded. On the other hand, the CPE bridges may well implement the spanning tree protocol in order to safeguard against 'backdoor' paths that bypass connectivity through the VPLS. B. Router CPE: Standard bridging techniques can also be used in this case. In addition, the smaller link layer address address space of such a VPLS may also permit other techniques, with explicit link layer routes between CPE routers. [Jamieson], for instance, proposes that MPLS LSPs be set up, at the insertion of any new CPE router into the VPLS, between all CPE LSRs. This then precludes the need for packet flooding. In the more general case, if stub link reachability mechanisms were used to configure VPLS edge nodes with the link layer addresses of the CPE routers connected to them, then modifications of any of the intra-VPN reachability mechanisms discussed for VPRNs could be used to propagate this information to each other VPLS edge node. This would then allow for packet forwarding across the VPLS without flooding. Mechanisms could also be developed to further propagate the link layer addresses of peer CPE routers and their corresponding network layer addresses across the stub links to the CPE routers, where such information could be inserted into the CPE router's address resolution tables. This would then also preclude the need for broadcast address resolution protocols across the VPLS. Gleeson et al. [Page 38] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 Clearly there would be no need for the support of spanning tree protocols if explicit link layer routes were determined across the VPLS. If normal flooding mechanisms were used then spanning tree would only be required again only if full mesh connectivity was not available and hence VPLS nodes had to carry transit traffic. 8.2 Specification Recommendations There is significant commonality between VPRNs and VPLSs, and, where possible, this similarity should be exploited in order to reduce development and configuration complexity. In particular, VPLSs should utilize the same tunneling and membership configuration mechanisms, with changes only to reflect the specific characteristics of VPLSs. Since one of the primary advantages of VPLSs is protocol transparency, it is likely that any general VPLS specification will need to support bridge CPE. As such, development of VPLS encapsulation, forwarding and reachability protocol mechanisms should prioritize support of bridge CPE through the support of ethernet encapsulations and standard link layer flooding and address learning mechanisms. As with VPRNs, there may be a need for specific mechanisms (e.g. [Jamieson]) for MPLS networks, and more generic mechanisms for non- MPLS networks. 9.0 Summary of Recommendations In this Draft different types of VPNs have been discussed individually, but there are many common requirements and mechanisms that apply to all types of VPNs, and many networks will contain a mix of different types of VPNs. It is useful to have as much commonality as possible across these different VPN types. In particular, by standardizing a relatively small number of mechanisms, it is possible to allow a wide variety of VPNs to be implemented. To this end serious consideration should be given to standardization efforts in the following areas - defining a generic VPN tunneling protocol (section 5.1) - defining a globally unique VPN identifier (section 6.1.1) - defining a VPN membership information configuration and dissemination mechanism, that uses some form of directory or MIB (section 6.1.2 A,B) Also the usefulness of defining a VPN link reachability protocol for Gleeson et al. [Page 39] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 the constrained case of a full mesh topology (section 6.1.4 D), could be examined. This is in addition to the work being done on MPLS-specific mechanisms in the MPLS WG. 10.0 Security considerations Security considerations are an integral part of any VPN mechanisms, and these are discussed in the sections describing those mechanisms. 11.0 Acknowledgements Thanks to Anthony Alles, of Shasta Networks, for his invaluable assistance in the generation of this Draft, and to Joel Halpern, of Newbridge Networks, for his helpful review comments. 12.0 References [Aboba1] Aboba, B. and Zorn, G. - "Implementation of PPTP/L2TP Compulsory Tunneling via RADIUS", draft-ietf-radius-tunnel-imp- 03.txt. [Aboba2] Aboba, B. and Zorn, G. - "Requirements for Internet Roaming", draft- ietf-roamops-roamreq-10.txt. [ADSL1] ADSL Forum - "An Interoperable End-to-end Broadband Service Architecture over ADSL Systems (Version 3.0)", ADSL Forum 97-215. [ADSL2] ADSL Forum - "Core Network Architectures for ADSL Access Systems (Version 1.01)", ADSL Forum 998-017. [ATMF1] ATM Forum - "LAN Emulation over ATM 1.0", af-lane-0021.000, January 1995. [ATMF2] ATM Forum - "Multi-Protocol Over ATM Specification v1.0", af-mpoa-0087.000, June 1997. [Bates] Bates, T. "Multiprotocol Extensions for BGP-4", RFC 2283. [Bernet] Bernet, Y., et al - "A Framework for Differentiated Services", draft-ietf-diffserv-framework-00.txt. [Calhoun1] Calhoun, P. and Peirce, K. - "Layer Two Tunneling Protocol "L2TP" IP Differential Services Extension", draft-ietf-pppext-l2tp- Gleeson et al. [Page 40] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 ds-02.txt. [Calhoun2] Calhoun, P., et al - "Layer Two Tunneling Protocol "L2TP" Security Extensions for Non-IP networks", draft-ietf-pppext-l2tp- sec-04.txt. [Calhoun3] Calhoun, P. et al - "Tunnel Establishment Protocol", draft-ietf-mobileip-calhoun-tep-01.txt. [Callon] Callon, R., et al "Multiprotocol Label Switching Architecture", draft-ietf-mpls-arch-02.txt. [Chandra] Chandra, R. and Traina, P. "BGP Communities Attribute", RFC 1998. [Coltun] Coltun, R. "The OSPF Opaque LSA Option", RFC 2370. [Davie] Davie, B., et al - "Use of Label Switching with RSVP", draft-ietf-mpls-rsvp-00.txt [Estrin] Estrin, D., et al - "Protocol Independent Multicast-Sparse Mode (PIM-SM) Protocol Specification", RFC 2362. [Evarts] Evarts, J., et al - "PPP Over Ethernet "PPPOE"", draft- carrel-info- pppoe-00.txt. [Fenner] Fenner, W. - "Internet Group Management Protocol, Version 2", RFC 2236. [Ferguson] Ferguson, P. and Huston, G. - "What is a VPN?", Revision, April 1 1998; http://www.employees.org:80/~ferguson/vpn.pdf. [Gupta] Gupta, V. - "Secure, Remote Access over the Internet using IPSec", draft-gupta-ipsec-remote-access-00.txt. [Hanks] Hanks, S., et al "Generic Routing Encapsulation over Ipv4 Networks", RFC 1702. [Harkins] Harkins, D. and Carrel, D. "The Internet Key Exchange (IKE)", draft-ietf-ipsec-isakmp-oakley-08.txt. [Heinanen1] Heinanen, J. and Rosen, E. "VPN Support with MPLS" draft-heinanen-mpls-vpn-01.txt. [Heinanen2] Heinanen, J., et al - "MPLS Mappings of Generic VPN Mechanisms", draft-heinanen-generic-vpn-mpls-00.txt. [IEEE] ANSI/IEEE - 10038: 1993 (ISO/IEC) Information technology -- Gleeson et al. [Page 41] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 Telecommunications and information exchange between systems -- Local area networks -- Media access control (MAC) bridges, ANSI/IEEE Std 802.1D, 1993 Edition. [Jamieson] Jamieson, D., et al - "MPLS VPN Architecture", draft- jamieson-mpls-vpn-00.txt. [Kent] Kent, S. and Atkinson, R. "Security Architecture for the Internet Protocol", draft-ietf-ipsec-arch-sec-06.txt. [Li] Li, T. and Rekhter, Y. - "Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)", draft-li- paste-00.txt. [Malkin] Malkin, G. "RIP Version 2 Carrying Additional Information", RFC 1723. [Moy] Moy, J. "OSPF Version 2", RFC 2328. [Patel] Patel, B. and Aboba, B. - "Securing L2TP using IPSEC", draft-ietf- pppext-l2tp-security-02.txt. [Rekhter1] Rekhter, Y., et al "Address Allocation for Private Internets", RFC 1918. [Rekhter2] Rekhter, Y. and Li, T. "A Border Gateway Protocol 4 (BGP-4)", RFC 1771. [Rekhter3] Rekhter, Y. and Rosen, E. "Carrying Label Information in BGP-4", draft-ietf-mpls-bgp4-mpls-00.txt. [Rigney] Rigney, C., et al - "Remote Authentication Dial In User Service (RADIUS)", RFC 2138. [Richard] Richard, C. and Smith, K. - "The PPP Bandwidth Allocation Protocol (BAP), The PPP Bandwidth Allocation Control Protocol (BACP)" RFC 2125. [Valencia1] Valencia, A., et al - "Layer Two Tunneling Protocol 'L2TP'", draft-ietf-pppext-l2tp-11.txt. [Shacham] Shacham, A., et al - "IP Payload Compression Protocol (IPComp)", draft-ietf-ippcp-protocol-06.txt. [Shea] Shea, R. - "L2TP-over-IP Path MTU Discovery (''L2TPMTU'')", draft- ietf-pppext-l2tpmtu-00.txt. [Shieh1] Shieh, P et al. "The Architecture for Extending PPP Gleeson et al. [Page 42] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 Connections for Home Network Clients", ADSL Forum contribution 98- 140. [Shieh2] Shieh, P et al. "The Requirement and Comparisons of Extending PPP over Ethernet", ADSL Forum contribution 98-141. [Simpson] Simpson, W. "IP in IP Tunneling", RFC 1853. [Sklower] Sklower, K., et al - "The PPP Multilink Protocol (MP)", RFC 1990. [Srisuresh] Srisuresh, P. and Holdrege, M. - "IP Network Address Translator (NAT) Terminology and Considerations", draft-ietf-nat- terminology-00.txt. [Thomas] Thomas, B., et al - "LDP Specification", draft-ietf-mpls- ldp-01.txt. [Valencia2] Valencia, A., et al "Cisco Layer Two Forwarding (Protocol) "L2F"", RFC 2341. [Waitzman] Waitzman, D., et al - "Distance Vector Multicast Routing Protocol", RFC 1075. [Wallne] Wallner, D., et al - "Key Management for Multicast: Issues and Architectures", draft-wallner-key-arch-01.txt. [Zorn] Zorn, G., et al - "Point-to-Point Tunneling Protocol--PPTP", draft- ietf-pppext-pptp-04.txt. 13.0 Author Information Bryan Gleeson Shasta Networks 249 Humboldt Court Sunnyvale CA 94089-1300 USA Tel: +1 (408) 548 3711 Email: bgleeson@shastanets.com Juha Heinanen Telia Finland, Inc. Myyrmaentie 2 01600 VANTAA Finland Tel: +358 303 944 808 Gleeson et al. [Page 43] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 Email: jh@telia.fi Arthur Lin Shasta Networks 249 Humboldt Court Sunnyvale CA 94089-1300 USA Tel: +1 (408) 548 3788 Email: alin@shastanets.com Grenville Armitage Bell Labs, Lucent Technologies 101 Crawfords Corner Rd Holmdel, NJ 07733-3030 USA Email: gja@lucent.com 14.0 Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Gleeson et al. [Page 44] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 Appendix A: Routing Protocol Piggybacking As noted above, routing protocol piggybacking could be used to carry VPN membership information alone, or also VPN reachability information. The means by which this is done, and the nature of the piggyback information, is a function both of the particular routing protocol, and of the underlying network mechanism. The particular cases of OSPF and BGP-4 are discussed below. 6.2.1 OSPF OSPF is often used as an intra-AS routing protocol, and hence may be a required candidate for routing protocol piggybacking. One means by which VPN membership and reachability information could be piggybacked is through the use of the proposed OSPF opaque LSA [Coltun]. The exact details of how such a piggybacking advertisement might be coded are for further study. In particular, it may prove to be the case that opaque LSAs could be well suited for piggybacking VPN membership information, but not VPN reachability information, since opaque LSAs, at least as currently defined, are attributes of, not indexes into, reachability information. Using them in the latter manner, which would be required to piggyback VPN reachability information, may break some existing OSPF implementations. Opaque LSAs do, however, have a well defined scoping mechanism, that, at least within an AS, allows for control over the extent of dissemination of a VPN advertisement. Note also that as a link state protocol OSPF advertisements always allow for the identification of the source of an advertisement. However, each router in the OSPF network, and not only edge routers, will also need to examine received advertisements, and explicitly ignore piggybacked VPN advertisements, unless configured to be a VPN terminator (i.e. edge router). 6.2.2 BGP-4 There are a number of potential mechanisms by which VPN information could be piggybacked into BGP-4, including the Multiprotocol Extensions attribute [Bates] or the BGP communities attribute. In the case where VPN reachability information is piggybacked, each VPN address prefix could be encoded as Network Layer Reachability Information (NLRI) and bound to the VPN identifier as a community attribute, if the VPN ID has the format proposed previously. Note that in cases where it was desired only to advertise VPN membership information, then advertising each VPN prefix may be onerous and undesirable, but there is no specific mechanism in BGP-4, as yet, to advertise anything other than NLRI. In the case where this is done on an MPLS network, then the advertisement would carry each VPN prefix, together with the MPLS label(s) to be used to Gleeson et al. [Page 45] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 send packets to that stub link. As noted above, these labels, as a purely local matter, could identify either the route to each stub link, or only to the edge router itself, which would then use its own forwarding mechanisms for egress packets. Since there is already defined a particular mechanism for carrying MPLS labels in BGP-4 using the Multiprotocol Extensions field [Rekhter3], this would suggest that this mechanism should be generalized for the purpose also of conveying VPN information; hence it is proposed that that Draft be amended for this purpose. The use of BGP-4 for VPN piggybacking is more complex in cases where this is done on non-MPLS networks. In such a case, the piggybacked advertisements must allow for the explicit identification of the source of the advertisement. This is important for tunnel set up in non-MPLS networks, where each edge router needs to know the identity (i.e. IP address) of each of the other edge routers, in order to initiate whatever signaling mechanism may be used for tunnel set-up. At present there is no means by which the original source of a BGP advertisement can be identified once that advertisement is redistributed (e.g. from an intra-AS protocol like OSPF into BGP at a border node, or from an edge router through a border router for distribution outside the original AS). Since VPN support in non-MPLS networks is an important requirement, it is proposed that whatever BGP-4 mechanism is chosen for the purpose of VPN advertisements also be amended to allow for explicit tagging with the IP address of the original source of the advertisement. One possible means by which this could be done may be to associate the VPN ID (coded as a Community Attribute) with the /32 prefix (i.e. IP address) of the edge router supporting the VPN. This issue is for further study. Note that in the case where BGP advertisements are propagated across AS boundaries, then each border router must cache the full set of prefixes and associated label stacks of each advertised VPN. In such a case, further work is also needed to control scoping of BGP piggybacked advertisements. In particular, at AS boundaries, border routers would generally need to be manually configured with VPN route advertisement policies to determine whether such advertisements should be propagated, and, if so, to which peer ASs. In general ASs will also likely automatically reject VPN advertisements received from peer ASs unless specifically configured to pass them. Some administrative mechanism (e.g. manual procedures or some form of directory communication, for instance) would be needed for this purpose. Note also that such scoping policy configurations would be needed not only in each border router of each AS with one or more VPN termination points, but also in each AS in the transit path between them. This last may pose problems if the trust system includes the terminating ASs, but excludes one or more of the transit ASs. These problems expose a particular artifact of router piggybacking - while VPN membership and reachability information is relevant only to the particular edge routers concerned, router piggybacking Gleeson et al. [Page 46] INTERNET DRAFT A Framework for IP Based VPNs September, 1998 necessarily requires also the active participation of all intermediate routers that need to process and propagate such advertisements. This may impose significant burdens on the operation and administration of such intermediate routers, as well as compromising the integrity of the VPNs concerned. Gleeson et al. [Page 47]