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