idnits 2.17.1 draft-gleeson-vpn-framework-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 46 longer pages, the longest (page 27) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 85 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Wallner' is mentioned on line 1349, but not defined == Missing Reference: 'ADSL' is mentioned on line 1535, but not defined == Unused Reference: 'Davie' is defined on line 1888, but no explicit reference was found in the text == Unused Reference: 'Li' is defined on line 1929, but no explicit reference was found in the text == Unused Reference: 'Srisuresh' is defined on line 1978, but no explicit reference was found in the text == Unused Reference: 'Wallne' is defined on line 1991, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-radius-tunnel-imp-03 ** Downref: Normative reference to an Informational draft: draft-ietf-radius-tunnel-imp (ref. 'Aboba1') -- No information found for - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Aboba2' -- Possible downref: Non-RFC (?) normative reference: ref. 'ADSL1' -- Possible downref: Non-RFC (?) normative reference: ref. 'ADSL2' -- Possible downref: Non-RFC (?) normative reference: ref. 'ATMF1' -- Possible downref: Non-RFC (?) normative reference: ref. 'ATMF2' ** Obsolete normative reference: RFC 2283 (ref. 'Bates') (Obsoleted by RFC 2858) == Outdated reference: A later version (-02) exists of draft-ietf-diffserv-framework-00 -- Possible downref: Normative reference to a draft: ref. 'Bernet' -- No information found for draft-ietf-pppext-l2tp-ds - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Calhoun1' -- Possible downref: Normative reference to a draft: ref. 'Calhoun2' -- Possible downref: Normative reference to a draft: ref. 'Calhoun3' == Outdated reference: A later version (-07) exists of draft-ietf-mpls-arch-02 ** Downref: Normative reference to an Informational RFC: RFC 1998 (ref. 'Chandra') ** Obsolete normative reference: RFC 2370 (ref. 'Coltun') (Obsoleted by RFC 5250) -- Possible downref: Normative reference to a draft: ref. 'Davie' ** Obsolete normative reference: RFC 2362 (ref. 'Estrin') (Obsoleted by RFC 4601, RFC 5059) -- No information found for draft-carrel-info- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Evarts' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ferguson' == Outdated reference: A later version (-03) exists of draft-gupta-ipsec-remote-access-00 -- Possible downref: Normative reference to a draft: ref. 'Gupta' ** Downref: Normative reference to an Informational RFC: RFC 1702 (ref. 'Hanks') -- Unexpected draft version: The latest known version of draft-ietf-ipsec-isakmp-oakley is -07, but you're referring to -08. (However, the state information for draft-carrel-info- is not up-to-date. The last update was unsuccessful) ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp-oakley (ref. 'Harkins') -- Possible downref: Normative reference to a draft: ref. 'Heinanen1' -- Possible downref: Normative reference to a draft: ref. 'Heinanen2' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE' -- Possible downref: Normative reference to a draft: ref. 'Jamieson' ** Downref: Normative reference to an Informational draft: draft-li-paste (ref. 'Li') ** Obsolete normative reference: RFC 1723 (ref. 'Malkin') (Obsoleted by RFC 2453) -- No information found for draft-ietf- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Patel' ** Obsolete normative reference: RFC 1771 (ref. 'Rekhter2') (Obsoleted by RFC 4271) == Outdated reference: A later version (-05) exists of draft-ietf-mpls-bgp4-mpls-00 ** Obsolete normative reference: RFC 2138 (ref. 'Rigney') (Obsoleted by RFC 2865) == Outdated reference: A later version (-16) exists of draft-ietf-pppext-l2tp-11 -- Unexpected draft version: The latest known version of draft-ietf-ippcp-protocol is -05, but you're referring to -06. (However, the state information for draft-ietf- is not up-to-date. The last update was unsuccessful) -- No information found for - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Shea' -- Possible downref: Non-RFC (?) normative reference: ref. 'Shieh1' -- Possible downref: Non-RFC (?) normative reference: ref. 'Shieh2' ** Downref: Normative reference to an Informational RFC: RFC 1853 (ref. 'Simpson') == Outdated reference: A later version (-03) exists of draft-ietf-nat-terminology-00 ** Downref: Normative reference to an Informational draft: draft-ietf-nat-terminology (ref. 'Srisuresh') == Outdated reference: A later version (-11) exists of draft-ietf-mpls-ldp-01 ** Downref: Normative reference to an Historic RFC: RFC 2341 (ref. 'Valencia2') ** Downref: Normative reference to an Experimental RFC: RFC 1075 (ref. 'Waitzman') ** Downref: Normative reference to an Informational draft: draft-wallner-key-arch (ref. 'Wallne') -- No information found for - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Zorn' Summary: 27 errors (**), 0 flaws (~~), 17 warnings (==), 32 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Bryan Gleeson, Arthur Lin 3 INTERNET DRAFT Shasta Networks, Inc. 4 Expires March 1999 Juha Heinanen 5 Telia Finland, Inc. 6 Grenville Armitage 7 Bell Labs, Lucent Technologies 9 A Framework for IP Based Virtual Private Networks 10 12 1. Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 To view the entire list of current Internet-Drafts, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 27 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 28 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 30 2.0 Abstract 32 This document describes a framework for virtual private networks 33 (VPN) running across IP backbones. It discusses the various 34 different types of VPNs, their respective requirements, and proposes 35 specific mechanisms that could be used to implement each type of VPN 36 using existing or proposed specifications. The objective of this 37 Draft is to serve as a framework for related protocol development in 38 order to develop the full set of specifications required for 39 widespread deployment of interoperable VPN solutions. 41 3.0 Introduction 43 There is currently significant interest in the deployment of virtual 44 private networks (VPN), across IP backbone facilities. The 45 widespread deployment of VPNs has been hampered, however, by the lack 46 of interoperable implementations, which, in turn, derive from the 47 lack of general agreement on the definition and scope of VPNs and 48 confusion over the wide variety of solutions that are all described 49 by the term VPN. In the context of this Draft, a VPN is simply 50 defined as the 'emulation of a private wide area network (WAN) 51 facility using IP facilities' (including the public Internet, or 52 private IP backbones). As such, there are as many types of VPNs as 53 there are types of WANs, hence the confusion over what exactly 54 constitutes a VPN. 56 This framework Draft proposes a taxonomy of a specific set of VPN 57 types, showing the specific applications of each, their specific 58 requirements, and the specific types of mechanisms that may be most 59 appropriate for their implementation. The intent of this Draft is to 60 serve as a framework to guide a coherent discussion of the specific 61 modifications that may be needed to existing IP mechanisms in order 62 to develop a full range of interoperable VPN solutions. 64 The Draft first discusses the likely expectations customers have of 65 any type of VPN, and the implications of these for the ways in which 66 VPNs can be implemented. It also discusses the distinctions between 67 Customer Premises Equipment (CPE) based solutions, and network based 68 solutions. Thereafter it presents a taxonomy of the various VPN 69 types and their respective requirements. It also outlines suggested 70 approaches to their implementation, hence also pointing to areas for 71 future standardization. 73 Note also that this Draft only discusses implementations of VPNs 74 across IP backbones, be they private IP networks, or the public 75 Internet. It specifically does not discuss means of constructing 76 VPNs using native mappings onto switched backbones - e.g. VPNs 77 constructed using, for instance, the LAN Emulation over ATM (LANE) 78 [ATMF1] or Multiprotocol over ATM (MPOA) [ATMF2] protocols operating 79 over ATM backbones. IP backbones may be constructed using such 80 native protocols, interconnecting routers across the switched 81 backbone. IP VPNs would then operate on top of this IP network, and 82 hence would not directly utilize the native mechanisms of the 83 underlying backbone. Native VPNs would be restricted to the scope of 84 the underlying backbone, whereas IP based VPNs can extend to the 85 extent of IP reachability. Native VPN protocols are clearly outside 86 the scope of the IETF, and may be tackled by such bodies as the ATM 87 Forum. 89 4.0 VPN Application and Implementation Requirements 91 There is growing interest in the use of IP VPNs as a more cost 92 effective means of building and deploying private communication 93 networks for multi-site communication than with existing approaches. 94 Existing private networks can be generally categorized into two types 95 - dedicated WANs that permanently connect together multiple sites, 96 and dial networks, that allow on-demand connections through the PSTN 97 network to one or more sites in the private network. 99 WANs are typically implemented using leased lines or dedicated 100 circuits - for instance, Frame Relay or ATM connections - between the 101 multiple sites. CPE routers or switches at the various sites connect 102 these dedicated facilities together and allow for connectivity across 103 the network. Given the cost and complexity of such dedicated 104 facilities and the complexity of CPE device configuration, such 105 networks are generally not fully meshed, but have a complex mix of 106 tree and mesh topologies with remote offices, for instance, star 107 wired to the nearest central site, with the latter then connected 108 together in some form of full or partial mesh. 110 Private dial networks are used to allow remote users to connect into 111 an enterprise network using PSTN or ISDN links. Typically, this is 112 done through the deployment of network access servers (NAS) at one or 113 more central sites. Users dial into such NAS, which interact with 114 AAAA ('Authentication, Authorization, Accounting and Administration') 115 servers to verify the identity of the user, and the set of services 116 that the user is authorized to receive. 118 In recent times, as more businesses have found the need for high 119 speed Internet connections, in addition to previous private networks, 120 there has been significant interest in the deployment of CPE based 121 VPNs running across the Internet. This has been driven typically by 122 the ubiquity and distance insensitive pricing of current Internet 123 services, that can result in significantly lower costs than typical 124 dedicated or leased line services. 126 The notion of using the Internet for private communications is not 127 new, and many techniques, such as controlled route leaking, have been 128 used for this purpose [Ferguson]. Only in recent times, however, 129 have the appropriate IP mechanisms needed to meet customer 130 requirements for VPNs all come together. These requirements include 131 the following: 133 A. Support for Opaque Packet Transport: 135 The traffic carried within a VPN may have no relation to the traffic 136 on the IP backbone, either because the traffic is multiprotocol, or 137 because the customer's IP network may use IP addressing unrelated to 138 that of the IP backbone on which the traffic is transported. In 139 particular, the latter may also be non-unique, private IP addressing 140 [Rekhter1]. 142 B. Support for Data Security: 144 In general, customers using VPNs require some form of data security, 145 given the general perceptions of the lack of security of IP networks, 146 and particularly that of the Internet. Whether or not this 147 perception is correct, it is one that must be addressed by any VPN 148 implementation. Note that some security concerns - e.g. snooping - 149 may be alleviated in cases where all of the VPN traffic stays within 150 a single service provider's closed IP backbone; on the other hand, 151 this alone may not address other concerns such as packet 152 misdirection, data integrity or ability of third parties to insert 153 unauthorized packets. Most recent VPN implementations are converging 154 on the use of standard IPSec facilities [Kent] for this purpose. 156 C. Support for Quality of Service Guarantees: 158 In addition to ensuring communication privacy, existing private 159 networking techniques, building upon physical or link layer 160 mechanisms, also offer various types of quality of service 161 guarantees. In particular, leased and dial up lines offer both 162 bandwidth and latency guarantees, while dedicated connection 163 technologies like ATM and Frame Relay have extensive mechanisms for 164 similar guarantees. As IP based VPNs become more widely deployed, 165 there will be market demand for similar guarantees, in order to 166 ensure end to end application transparency. While the ability of IP 167 based VPNs to offer such guarantees will depend greatly upon the 168 commensurate capabilities of the underlying IP backbones, a VPN 169 framework must also address the means by which VPN systems can 170 utilize such capabilities, as they evolve. 172 Together, the first two of these requirements imply that VPNs must be 173 implemented through some form of IP tunneling mechanism, where the 174 packet formats and/or the addressing used within the VPN can be 175 unrelated to that used to route the tunneled packets across the IP 176 backbone. Such tunnels, depending upon their form, can provide some 177 level of intrinsic data security, or this can also be enhanced using 178 other mechanisms (e.g. IPSec). 180 Furthermore, as discussed later, such tunneling mechanisms can also 181 be mapped into evolving IP traffic management mechanisms. There are 182 already defined a large number of IP tunneling mechanisms. Some of 183 these are well suited to VPN applications, as discussed further 184 below. 186 4.1 CPE and Network Based VPNs 188 Most current VPN implementations are based on CPE equipment. VPN 189 capabilities are being integrated into a wide variety of CPE devices, 190 ranging from Firewalls, to WAN edge routers and specialized VPN 191 termination devices. Such equipment may be bought and deployed by 192 customers, or may be deployed (and often remotely managed) by service 193 providers in an outsourcing service. 195 There is also significant interest in 'network based VPNs', where the 196 operation of the VPN is outsourced to an Internet service provider 197 (ISP), and is implemented on network as opposed to CPE equipment. 198 There is significant interest in such solutions both by customers 199 seeking to reduce support costs and by ISPs seeking new revenue 200 sources. Supporting VPNs in the network allows the use of particular 201 mechanisms which may lead to highly efficient and cost effective VPN 202 solutions, with common equipment and operations support amortized 203 across large numbers of customers. 205 Most of the mechanisms discussed below can apply to either CPE based 206 or network based VPNs. However particular mechanisms are likely to 207 prove applicable only to the latter, since they leverage tools (e.g. 208 piggybacking on routing protocols) which are accessible only to ISPs 209 and which are unlikely to be made available to any customer, or even 210 hosted on ISP owned and operated CPE, due to the problems of 211 coordinating joint management of the CPE gear by both the ISP and the 212 customer. The Draft will indicate which techniques are likely to 213 apply only to network based VPNs. 215 5.0 VPN Types: 'Virtual Leased Lines' 217 The simplest form of a VPN is a 'virtual leased line' (VLL) service. 218 In this case, the two VPN endpoints are connected by an IP tunnel 219 which seeks to emulate a physical leased line or dedicated 220 connection. The IP tunnel operates as an overlay across the IP 221 backbone, and the traffic sent through the tunnel is opaque to the 222 underlying IP backbone. In effect the IP backbone is being used as a 223 link layer technology, and the IP tunnel forms a point-to-point link. 224 A device may terminate multiple such VLLs and route or bridge between 225 them, but the manner in which the the VLLs are connected, i.e. at 226 layer 3 or layer 2, is independent of the operation of the VLL 227 itself. For example at layer 3 the VLL can be bound to an IP 228 forwarding table, which views it as just another point-to-point IP 229 interface. A simple example of forwarding at layer 2 is the operation 230 of relaying frames between an ATM VCC and a VLL, in effect forming a 231 point-to-point link. VLLs can also be used to interconnect bridging 232 devices. 234 More generally, a VLL can also be considered to be the building block 235 of more complex VPN types and topologies. Specifically, as will be 236 discussed in following sections, there are also VPN types in which 237 the forwarding operation, be it at the link layer or the network 238 layer, is also part of the operation of the VPN. In this case, the 239 tunnels connecting each of the VPN nodes can be constructed using VLL 240 tunneling mechanisms, since these have the same requirements. 242 The following section, therefore, looks at the requirements of a 243 generic IP tunneling protocol that can be used both for simple VLL 244 applications, and also for more complex types of VPNs. 246 5.1 Tunneling Protocol Requirements for VLLs 248 There are numerous IP tunneling mechanisms, including IP/IP 249 [Simpson], GRE tunnels [Hanks], L2TP [Valencia1], MPLS [Callon] and 250 IPSec [Kent]. Note that while some of these protocols are not often 251 thought of as tunneling protocols, they do each allow for opaque 252 transport of frames as packet payload, with forwarding disjoint from 253 the address fields of the encapsulated packets. As such, any of 254 these could be applied to the operation of a VLL, albeit with some 255 modifications, as discussed below. 257 Note, however, that there is one significant distinction between each 258 of the IP tunneling protocols mentioned above, and MPLS. MPLS can be 259 viewed as a specific link layer for IP, insofar as MPLS specific 260 mechanisms apply only within the scope of an MPLS network, whereas IP 261 based mechanisms extend to the extent of IP reachability. As such, 262 VPN mechanisms built directly upon MPLS tunneling mechanisms (e.g. as 263 described in [Heinanen1] or [Jamieson]) cannot, by definition, extend 264 outside the scope of MPLS networks, any more so than, for instance, 265 ATM based mechanisms such as LANE can extend outside of ATM networks. 266 Note however, that an MPLS network can span many different link layer 267 technologies, and so, like an IP network, its scope is not limited by 268 the specific link layers used. Parallel work on defining a set of 269 mechanisms to allow for interoperable VPNs specifically over MPLS 270 networks is also underway, as addressed in [Heinanen2] and 271 [Jamieson], and as will be discussed later. 273 There are a number of desirable requirements for a VLL tunneling 274 mechanism, however, that are not all met by the existing tunneling 275 mechanisms. These include: 277 5.1.1 Support for VLL Multiplexing: 279 There are cases where multiple VLLs may be needed between the same 280 two IP endpoints. This may be needed, for instance, in cases where 281 the VLLs are network based, and each end point supports multiple 282 customers. Traffic for different customers travels over separate VLLs 283 between the same two physical devices. A multiplexing field is needed 284 to distinguish which packets belong to which VLL. Sharing a tunnel in 285 this manner may also reduce the latency and processing burden of 286 tunnel set up. Of the existing IP tunneling mechanisms, L2TP (via 287 the tunnel-id and call-id fields), MPLS (via the label) and IPSec 288 (via the SPI field) have a multiplexing mechanism. Strictly speaking 289 GRE does not have a multiplexing field. However the key field, which 290 was intended to be used for authenticating the source of a packet, 291 has sometimes been used as a multiplexing field. IP/IP does not have 292 a multiplexing field. 294 5.1.2 Support for a Signalling Protocol 296 For a VLL there is some configuration information that must be known 297 by an end point in advance of tunnel establishment, such as the IP 298 address of the remote end point, and any relevant tunnel attributes 299 required (such as the level of security needed). Following this 300 configuration the actual tunnel establishment can be completed in one 301 of two ways - via a management operation, or via a signalling 302 protocol that allows tunnels to be established dynamically. 304 An example of a management operation would be to use an SNMP MIB to 305 configure various tunneling parameters, e.g. MPLS labels, source 306 addresses to use for IP/IP or GRE tunnels, L2TP tunnel-ids and call- 307 ids, or security association parameters for IPSec. 309 Using a signalling protocol can significantly reduce the management 310 burden however and should be a requirement for any standard VLL 311 tunneling mechanism. It reduces the amount of configuration needed, 312 and reduces the management co-ordination needed if a VPN spans 313 multiple administrative domains. For example, the value of the 314 multiplexing field, described above, is local to the node assigning 315 the value, and can be kept local if distributed via a signalling 316 protocol, rather than being first configured into a management 317 station and then distributed to the relevant nodes. A signalling 318 protocol also allows nodes that are mobile or are only intermittently 319 connected to establish tunnels on demand. Signalling is particularly 320 useful for the VPRN scenario described later (section 6.0). 322 A signalling protocol should allow for the transport of a VPN 323 identifier (see 6.1.1) to allow the resulting tunnel to be associated 324 with a particular VLL. It should also allow tunnel attributes to be 325 exchanged or negotiated, for example the use of frame sequencing or 326 the use of multiprotocol transport. Note that the role of the 327 signalling protocol is solely to negotiate tunnel attributes, not to 328 carry information about how the tunnel is used, for example whether 329 the frames carried in the tunnel are to be forwarded at layer 2 or 330 layer 3. (This is similar to Q.2931 ATM signalling - the same 331 signalling protocol is used to set up Classical IP LISs as well as 332 LANE ELANs). 334 Of the various tunneling protocols, the following ones support a 335 signaling protocol that could possibly be adapted for this purpose: 336 MPLS (the various mechanisms for label distribution, including the 337 label distribution protocol (LDP) [Thomas]), L2TP (the L2TP control 338 channel) and IPSec (the Internet Key Exchange (IKE) protocol 339 [Harkins]), and GRE (as used with mobile-ip tunneling [Calhoun3]). 341 5.1.3 Support for Data Security: 343 A VLL tunneling mechanism must support mechanisms to allow for 344 whatever level of security may be desired by customers, including 345 authentication and/or encryption of various strengths. None of the 346 tunneling mechanisms discussed, other than IPSec, have intrinsic 347 security mechanisms, but rely upon the security characteristics of 348 the underlying IP backbone. In particular, MPLS relies upon the 349 explicit labeling of label switched paths (LSP) to ensure that 350 packets cannot be misdirected, while the other tunneling mechanisms 351 can all be secured through the use of IPSec. 353 If some form of signalling mechanism is used by one VLL end point to 354 dynamically establish a tunnel with another endpoint, then there is a 355 requirement to be able to authenticate the party attempting the 356 tunnel establishment. IPsec has an array of schemes for this purpose, 357 allowing, for example, authentication to be based on pre-shared keys, 358 or public/private key pairs with certificates. Other tunneling 359 schemes have weaker forms of authentication. In some cases no 360 authentication may be needed, for example if the tunnels are 361 provisioned, rather than dynamically established, or if the trust 362 model in use does not require it. 364 5.1.4 Support for Multiprotocol Transport 366 In many applications of VLLs, the VLL may carry opaque, multiprotocol 367 traffic. As such, the tunneling protocol must also support 368 multiprotocol transport. The only tunneling mechanism which will 369 preclude such transport is IP/IP. L2TP is designed to transport PPP 370 packets, and thus can be used to carry multiprotocol traffic since 371 PPP itself is multiprotocol. IPSec has been designed to transport IP 372 packets, but may be readily generalized to carry multiprotocol 373 traffic. The signalling component of IPSec (IKE) could be extended to 374 indicate the type of traffic carried over the IP tunnel or the type 375 of packet multiplexing header used (e.g. LLC/SNAP, GRE), if the 376 traffic is not IP. 378 5.1.5 Support for Frame Sequencing: 380 One quality of service attribute required by customers of a VLL, may 381 be frame sequencing, matching the equivalent characteristic of 382 physical leased lines or dedicated connections. Sequencing may be 383 required for the efficient operation of particular end to end 384 protocols or applications. In order to implement frame sequencing, a 385 VLL tunneling mechanism should have the option of a sequencing field. 386 At present, only the L2TP specification has such a field. IPSEC has a 387 sequence number field, but it is used by a receiver to perform an 388 anti-replay check, not to guarantee in-order delivery of packets. 390 5.1.6 Support for Tunnel Maintenance: 392 The VLL end points must monitor the operation of the VLL tunnels to 393 ensure that connectivity has not been lost. Note that this does not 394 necessarily require inband verification, since IP backbone 395 connectivity with the VLL end point is sufficient assurance, due to 396 the fact the tunnel also runs across the same backbone. L2TP has an 397 optional in-band keep-alive mechanism to detect non-operational 398 tunnels. Other tunneling mechanisms will likely require some out of 399 band mechanism to determine connectivity - for instance, regular ICMP 400 pings. 402 Note also that tunnel inactivity should be differentiated from tunnel 403 deletion. A distinction needs to be made between the creation and 404 deletion of a VLL tunnel, and the establishment and termination of a 405 tunnel instance. The creation of a VLL tunnel is a configuration 406 operation, whereby the information needed to dynamically establish a 407 tunnel (e.g. the remote IP end point) is installed. Similarly the 408 deletion of such a VLL tunnel is a configuration operation that 409 removes this information. The establishment of a tunnel instance 410 occurs as a result of a signalling exchange, with parameters being 411 transferred (e.g. the value of the multiplexing field) and any needed 412 resources being put in place. This may occur immediately the VLL 413 tunnel is created, or a data-driven approach could be used, whereby 414 the tunnel instance is only established when there is some data to be 415 transferred. Also the tunnel instance could be maintained until VLL 416 tunnel deletion, whether or not it was being used, or it could be 417 terminated due to an idle timeout, and re-established whenever there 418 was subsequently data ready for transfer. The latter approach may be 419 useful if resources are being allocated for traffic management 420 purposes, to avoid dedicating resources for inactive tunnel 421 instances. 423 5.1.7 Support for Large MTUs 425 Since the traffic sent through a VLL may often be opaque to the 426 underlying IP backbone, it cannot also generally be assumed that the 427 maximum transfer unit (MTU) of the VLL itself, is less than or equal 428 to that of the MTU of the particular route of the VLL across the IP 429 backbone. As such, the VLL tunneling mechanism may need mechanisms to 430 allow for frame fragmentation, either within the tunnel, or at the IP 431 level. 433 If the frame to be transferred is mapped into one IP datagram, normal 434 IP fragmentation mechanisms can be used. There may also be value in 435 defining fragmentation techniques that operate at the tunnel level 436 (using the tunnel sequence number and an end-of-message marker of 437 some sort) in order to avoid IP level fragmentation. This subject is 438 for further study. 440 5.1.8 Minimization of Tunnel Overhead 442 There is clearly benefit in minimizing the overhead of VLL tunneling 443 mechanisms. This is particularly important for the transport of 444 small, jitter and latency sensitive traffic such as packetized voice 445 and video. On the other hand, the use of security mechanisms, such 446 as IPSec, do impose their own overhead, hence the objective should be 447 to minimize overhead over and above that needed for security, and to 448 not burden those VLLs in which security is not mandatory with 449 unnecessary overhead. 451 5.1.9 Flow and congestion control issues 453 Of the existing tunneling schemes only L2TP has procedures for flow 454 and congestion control. These were necessitated in part due to the 455 need to provide adequate performance over lossy networks when PPP 456 compression (which, unlike the IP Payload Compression Protocol 457 (IPComp) [Shacham], is stateful across packets) is being used, and to 458 accommodate devices with very little buffering. The flow and 459 congestion control mechanisms used with L2TP are largely specific to 460 the use of PPP and devices that terminate low speed dial-up lines. 462 More analysis is needed to see if any flow and congestion control 463 mechanisms should be incorporated into a generic IP tunneling 464 protocol. For TCP traffic, the end-to-end flow and congestion control 465 provided by TCP itself will generally suffice. Good flow and 466 congestion control schemes, that can adapt to a wide variety of 467 network conditions and deployment scenarios are complex to develop 468 and test, both in themselves and in understanding the interaction 469 with other schemes (e.g. TCP's) that may be running in parallel. 470 There may be some benefit, however, in having the capability whereby 471 a sender can shape traffic to the capacity of a receiver in some 472 manner, and in providing the protocol mechanisms to allow a receiver 473 to signal its capabilities to a sender. This area is for further 474 study. 476 5.1.10 Traffic Management issues 478 As noted above, customers may require that VLLs yield similar 479 behavior to physical leased lines or dedicated connections with 480 respect to such traffic management parameters as loss rates and 481 latency and bandwidth guarantees. How such guarantees could be 482 delivered will, in general, be a function of the traffic management 483 characteristics of the VPN termination devices, and the access and 484 backbone networks across which they are connected. 486 However, it is likely that the most general solution would be to 487 model a VLL as a logical link which extends across the backbone 488 between two terminating devices. As such, all of the capabilities 489 currently being developed and deployed for traffic management, 490 including link sharing, differentiated services [Bernet] and fair 491 scheduling could also be applied to the VLL. The specific 492 capabilities that may be needed from VLL tunneling mechanisms to 493 support such requirements is for further study. 495 It will be noted, however, that this proposed model of tunnel 496 operation may not wholly consistent with the way in which specific 497 tunneling protocols are currently modeled. In particular, it is 498 unclear whether an IPSec tunnel is considered in the current IPSec 499 architecture to be an interface, per se, or an attribute of a 500 particular packet flow. 502 5.2 Specification Recommendations 504 There is a need for a standard VLL tunneling mechanism, that 505 addresses each of the requirements discussed above. Given the 506 necessity for strong encryption and strong authentication 507 capabilities it would appear that a modification of IKE/IPSec may 508 well be the optimal choice, particularly for non-MPLS based networks, 509 since in addition to addressing the need for secure tunnels, it 510 already has well defined signaling and multiplexing capabilities 511 which can be readily amended for the specific needs of VLLs. To 512 minimize overhead, including the overhead of configuration, control 513 state, and processing cycles, as well as extra header fields added to 514 a data packet, it also seems advantageous to converge on the use of a 515 single signalling protocol and associated data encapsulation, rather 516 than use multiple protocols in parallel (e.g. IKE/IPSec and L2TP). 517 However the use of IPSec as a VPN tunneling mechanism may require 518 amendments to the envisaged model of IPSec usage implicit in the 519 current IPSec architecture. A future draft will discuss these 520 amendments in greater detail. Note that parallel work is also 521 underway in the MPLS WG on MPLS-based tunneling mechanisms as 522 discussed in [Heinanen2]. 524 6.0 VPN Types: Virtual Private Routed Networks 526 A virtual private routed network (VPRN) is defined to be the 527 emulation of a multi-site wide area routed network using IP 528 facilities. This section looks at how a network-based VPRN service 529 can be provided. CPE-based VPRNs are also possible, but are not 530 specifically discussed here. With network-based VPRNs many of the 531 issues that need to be addressed are concerned with configuration and 532 operational issues, which must take into account the split in 533 administrative responsibility between the service provider (ISP) and 534 the service user (customer). 536 A VPRN consists of a mesh of IP tunnels between ISP routers, together 537 with the routing capabilities needed to forward traffic received at 538 each VPRN site to the appropriate destination site. Attached to these 539 ISP routers are CPE routers connected via one or more links, termed 540 'stub' links. This is illustrated in the following diagram, which 541 shows 3 ISP edge routers connected via a full mesh of IP tunnels, 542 used to interconnect 4 CPE routers. One of the CPE routers is 543 multihomed to the ISP network. In the multihomed case, all stub links 544 may be active, or, as shown, there may be one primary and one or more 545 backup links to be used in case of failure of the primary. The term 546 'backdoor' link is used to refer to a link between two customer sites 547 that does not traverse the ISP network. 549 +--------+ +--------+ 550 +---+ | ISP | | ISP | +---+ 551 |CPE|-------| edge |-----------------------| edge |------|CPE| 552 +---+ | router | IP tunnel | router | +---+ 553 stub +--------+ +--------+ stub : 554 link | | | link : 555 | | | : 556 | | IP BACKBONE | : 557 | | | : 558 | |IP tunnel IP tunnel| : 559 | | +--------+ | : 560 | | | ISP | | : 561 | +-----------| edge |-----------+ : 562 | | router | : 563 backup| +--------+ backdoor: 564 link | | | link : 565 | stub link | | stub link : 566 | | | : 567 | +---+ +---+ : 568 +-------------|CPE| |CPE|......................: 569 +---+ +---+ 571 The principal benefit of a VPRN is that the configuration of the CPE 572 router is simplified. To a CPE router, the ISP edge router appears as 573 a neighbour router in the customer's network, to which it sends all 574 traffic for non-local VPRN destinations. The tunnel mesh that is set 575 up to transfer traffic extends between the ISP edge routers, not the 576 CPE routers. In effect the burden of tunnel establishment and 577 maintenance and routing configuration is outsourced to the ISP. 579 This is in contrast to the scenario where the tunnel mesh extends to 580 the CPE routers. In this case the ISP network provides layer 2 581 connectivity alone. This can be implemented either as a set of VLLs 582 between CPE routers, in which case the ISP network provides a set of 583 layer 2 point-to-point links, or as a Virtual Private LAN Segment 584 (VPLS) (see section 8.0), in which case the ISP network is used to 585 emulate a multiaccess LAN segment. With these scenarios a customer 586 may have more flexibility (e.g. any IGP or any protocol can be run 587 across all customer sites) but this usually comes at the expense of a 588 more complex configuration for the customer. Thus, depending on 589 customer requirements, a VPRN or a VPLS may be the more appropriate 590 solution. 592 Because a VPRN carries out forwarding at the network layer, a single 593 VPRN only directly supports a single network layer protocol. For 594 multiprotocol support, a separate VPRN for each network layer 595 protocol could be used, or one protocol could be tunneled over 596 another (e.g. non-IP protocols tunneled over an IP VPRN) or 597 alternatively the ISP network could be used to provide layer 2 598 connectivity only, such as with a VPLS as mentioned above. 600 The issues to be addressed for VPRNs include initial configuration, 601 determination of the set of routers that have members in a VPRN, 602 determination by an ISP edge router of the set of IP address prefixes 603 reachable via each stub link, determination by a CPE router of the 604 set of IP address prefixes to be forwarded to an ISP edge router, the 605 mechanism used to disseminate stub reachability information to the 606 correct set of ISP routers, and the establishment and use of the 607 tunnels used to carry the data traffic. Note also that, although 608 discussed first for VPRNs, many of these issues also apply to the 609 VPLS scenario described later, with the network layer addresses being 610 replaced by link layer addresses. 612 Note that VPRN operation is decoupled from the mechanisms used by the 613 customer sites to access the Internet. A typical scenario would be 614 for the ISP edge router to be used for both VPRN and Internet 615 connectivity. In this case the CPE router would have a default route 616 pointing to the ISP edge router. However a customer site could have 617 Internet connectivity via an ISP router not involved in the VPRN, or 618 even via a different ISP. In this case, for VPRN traffic, the CPE 619 router would have a route (or set of routes) for all non-local VPRN 620 destinations, pointing to the ISP edge router. This is termed a 'VPRN 621 default route', and is used where necessary in contrast to 'default 622 route' which refers to all non-local destinations (including both 623 non-local VPRN destinations and external Internet destinations). 625 VPRN requirements and mechanisms have been discussed previously in 626 [Heinanen2], with a particular focus in that Draft showing how the 627 same VPRN functionality can be implemented over both MPLS and non- 628 MPLS networks. 630 A. Topology 632 The topology of a VPRN may consist of a full mesh of tunnels between 633 each VPRN site, or may be an arbitrary topology, such as a set of 634 remote offices connected to the nearest central site, with these 635 central sites connected together via a full or partial mesh. With 636 VPRNs there is much less cost assumed with full meshing than in cases 637 where physical resources (e.g. Frame Relay DLCI or a leased line) 638 must be allocated for each connected pair of sites. This yields 639 optimal routing, since it precludes the need for traffic between two 640 sites to traverse through a third. One attraction of a full mesh 641 topology is that there is no need to configure topology information 642 for the VPRN. Instead, given the member routers of a VPRN, the 643 topology is implicit. If the number of ISP edge routers in a VPRN is 644 very large, however, a full mesh topology may not be appropriate, due 645 to the scaling issues involved, for example, the growth in the number 646 of tunnels needed between sites, (which for n sites is n(n-1)/2), or 647 the number of routing peers per router. Network policy may also lead 648 to non full mesh topologies, for example an administrator may wish to 649 set up the topology so that traffic between two remote sites passes 650 through a central site, rather than go directly between the remote 651 sites. It is also necessary to deal with the scenario where there is 652 only partial connectivity across the IP backbone under certain error 653 conditions (e.g. A can reach B, and B can reach C, but A cannot reach 654 C directly), which can occur if policy routing is being used. 656 For a network-based VPRN, it is assumed that each customer site CPE 657 router connects to an ISP edge router through one or more dedicated 658 point-to-point stub links (e.g. leased lines, ATM or Frame Relay 659 connections). The ISP routers are responsible for learning and 660 disseminating reachability information amongst themselves. The CPE 661 routers must learn the set of destinations reachable via each stub 662 link, though this may be as simple as a default route. 664 B. Addressing 666 The addressing used within a VPRN may have no relation to the 667 addressing used on the IP backbone over which the VPRN is 668 instantiated. In particular non-unique private IP addressing may be 669 used [Rekhter1]. Multiple VPRNs may be instantiated over the same set 670 of physical devices, and they may use the same or overlapping address 671 spaces. 673 C. Forwarding 675 For a VPRN the tunnel mesh forms an overlay network operating over an 676 IP backbone. Within each of the ISP edge routers there must be VPN 677 specific forwarding mechanisms to forward packets received from stub 678 links ('ingress traffic') to the appropriate next hop router, and to 679 forward packets received from the core ('egress traffic') to the 680 appropriate stub link. For cases where a ISP edge router supports 681 multiple stub links belonging to the same VPRN, the tunnels can, as a 682 local matter, either terminate on the edge router, or on a stub link. 683 In the former case a VPN specific forwarding table is needed for 684 egress traffic, in the latter case it is not. A VPN specific 685 forwarding table is generally needed in the ingress direction, in 686 order to direct traffic received on a stub link onto the correct IP 687 tunnel towards the core. 689 Also since a VPRN operates at the internetwork layer, the IP packets 690 send over a tunnel will have their TTL field decremented in the 691 normal manner, preventing packets circulating indefinitely in the 692 event of a routing loop within the VPRN. 694 D. Multiple concurrent VPRN connectivity 696 Note also that a single customer site may belong concurrently to 697 multiple VPRNs and may want to transmit traffic both onto one or more 698 VPRNs and to the default Internet, over the same stub link. There are 699 a number of possible approaches to this problem, but these are 700 outside the scope of the current Draft. 702 6.1 VPRN Generic Requirements 704 There are a number of common requirements which any network-based 705 VPRN solution must address, and there are a number of different 706 mechanisms that can be used to meet these requirements. These generic 707 issues are 709 - The use of a globally unique VPN identifier in order to be able to 710 refer to a particular VPN. 712 - VPRN membership determination. An edge router must learn of the 713 other routers that have members in that VPRN. 715 - Stub link reachability information. An edge router must learn the 716 set of addresses and address prefixes reachable via each stub link. 718 - Intra-VPRN reachability information. Once an edge router has 719 determined the set of address prefixes associated with each of its 720 stub links, then this information must be disseminated to each other 721 edge router in the VPRN. 723 - Tunneling mechanism. An edge router must construct the necessary 724 tunnels to other routers that have members in the VPRN, and must 725 perform the encapsulation and decapsulation necessary to send and 726 receive packets over the tunnels. 728 6.1.1 VPN Identifier 730 Network-based VPRNs may potentially span multiple autonomous systems 731 (ASs) and multiple management domains. This implies the need for a 732 VPN identifier than can be unique across multiple ASs. To that end, 733 [Heinanen1] proposed a globally unique VPN identifier (note that such 734 an identifier may be useful for VPN types other than VPRNs) made up 735 of the concatenation of an AS number, and a label assigned by the AS 736 administrator which is locally unique within the particular AS. This 737 is one solution to the need for a globally unique VPN identifier used 738 across public networks. Specifically a VPN ID could be coded as a 739 four octet BGP Communities Attribute [Chandra], made up of a two 740 octet AS number and a 2 octet, unstructured integer VPN number, to 741 allow for sufficient numbers of VPNs per AS. 743 Note that where a VPN crosses multiple ASs, then there must be some 744 administrative mechanisms to coordinate VPN ID assignment e.g. 745 through the notion of a 'home AS' for a particular VPN, which is used 746 in the VPN ID of that VPN. A VPN ID coded as proposed could also be 747 easily piggybacked in BGP, and could also be easily specified within 748 BGP policy filters in AS border routers for scoping and 749 administrative purposes. 751 In other environments where VPRN functionality is required, but where 752 using an AS number is not convenient (because the VPRN functionality 753 is being provided on private IP backbone facilities, for example), an 754 Organizationally Unique Identifier (OUI), could be used instead of an 755 AS number. This is a 3 octet number, assigned by the IEEE. With the 756 addition of a locally assigned 2 octet VPN number this would form a 5 757 octet VPN identifier. 759 Note that the intent of the VPN ID is that it be used in 760 configuration and control messages in order to refer to a particular 761 VPN. There is a also a need to be able to associate a data packet 762 received on a tunnel with a particular VPN, however the VPN ID is not 763 intended to be used for this purpose, since including an extra 4 or 5 764 byte quantity with every data packet transmitted is neither efficient 765 or necessary. Instead a tunnel specific multiplexing field is used 766 for that purpose. For example an IPSec tunnel uses the SPI field, an 767 L2TP tunnel uses the call-id field, and an MPLS tunnel uses the MPLS 768 label. 770 There is a need for a standard VPN identifier. This could use the OUI 771 format described above, or could be a hybrid which allows both an AS 772 or an OUI to be used, or perhaps some other method. The ATM Forum 773 also have a similar problem to solve, and ideally a single mechanism 774 should be used for both cases. For the remainder of this draft it is 775 assumed that such a globally unique VPN identifier exists. 777 6.1.2. VPN Membership Information Configuration and Dissemination 779 In order to establish a VPRN, or to insert new customer sites into an 780 established VPRN, the stub links on each edge router from those sites 781 in the particular VPRN must first be configured with the identity of 782 the particular VPRN to which the stub links belong. Note that this 783 first step of stub link configuration is unavoidable, since clearly 784 the edge router cannot infer such bindings and hence must be 785 configured with this information. A management information base (MIB) 786 allowing for bindings between local stub links and VPN identities is 787 one solution. 789 Thereafter, each edge router must learn either the identity of, or, 790 at least, the route to, each other edge router supporting other stub 791 links in that particular VPRN. Implicit in the latter is the notion 792 that there exists some mechanism by which the configured edge routers 793 can then use this edge router and/or stub link identity information 794 to subsequently set up the appropriate tunnels between them; this is 795 discussed further below. 797 In order to configure each stub link with the identity of the VPN to 798 which it belongs, a VPN identifier is required (see 6.1.1); the scope 799 of uniqueness of this identifier is a function of its usage, which is 800 related to how VPRN membership is disseminated. This problem, of 801 VPRN member dissemination between participating edge routers, can be 802 solved in a variety of ways, discussed below. 804 A. Directory Lookup: 806 The members of a particular VPRN, that is, at a minimum, the identity 807 of the edge routers supporting stub links in the VPRN, and possibly 808 also the identity of each of the stub links, could be configured into 809 a directory, which edge routers could query, using some defined 810 mechanism (e.g. LDAP), upon configuration of their local stub 811 interfaces and VPN identifier. 813 Using a directory allows either a full mesh topology or an arbitrary 814 topology to be configured. For a full mesh, the full list of member 815 routers in a VPRN is distributed everywhere. For an arbitrary 816 topology, different routers may receive different member lists. 818 Using a directory allows for authorization checking prior to 819 disseminating VPRN membership information, which may be desirable 820 where VPRNs span multiple administrative domains. In such a case, 821 directory to directory protocol mechanisms could also be used to 822 propagate authorized VPRN membership information between the 823 directory systems of the multiple administrative domains. 825 There would also need to be some form of database synchronization 826 mechanism (e.g. triggered or regular polling of the directory by edge 827 routers, or active pushing of update information to the edge routers 828 by the directory) in order for all edge routers to learn the identity 829 of newly configured sites inserted into an active VPRN, and also to 830 learn of sites removed from a VPRN. 832 B. Explicit Management Configuration: 834 A VPRN Management Information Base (MIB) could be defined which would 835 allow a central management system to configure each edge router with 836 the identities of each other participating edge router and possibly 837 also the identity of each of the stub links. Similar mechanisms 838 could also be used, as noted above, to configure the VPN bindings of 839 the local stub links on the edge router. Like the use of a directory, 840 this mechanism allows both full mesh and arbitrary topologies to be 841 configured. 843 Note that this mechanism allows the management station to impose 844 strict authorization control; on the other hand, it may be more 845 difficult to configure edge routers outside the scope of the 846 management system. The management configuration model can also be 847 considered a subset of the directory method, in that the (management) 848 directories could use MIBs to push VPRN membership information to the 849 participating edge routers, either subsequent to, or as part of, the 850 local stub link configuration process. 852 C. Piggybacking in Routing Protocols: 854 VPRN membership information could be piggybacked into the routing 855 protocols run by each edge router across the IP backbone, since this 856 is an efficient means of automatically propagating information 857 throughout the network to other participating edge routers. 858 Specifically, each route advertisement by each edge router could 859 include, at the minimum, the set of VPN identifiers associated with 860 each edge router, and adequate information to allow other edge 861 routers to determine the identity of, and/or, the route to, the 862 particular edge router. Other edge routers would examine received 863 route advertisements to determine if any contained information was 864 relevant to a supported (i.e. configured) VPRN; this determination 865 could be done by looking for a VPN identifier matching a locally 866 configured VPN. The nature of the piggybacked information, and 867 related issues, such as scoping, and the means by which the nodes 868 advertising particular VPN memberships will be identified, will 869 generally be a function both of the routing protocol and of the 870 nature of the underlying transport, and is discussed further in 871 Appendix A. 873 Using this method all the routers in the network will have the same 874 view of the VPRN membership information, and so a full mesh topology 875 is easily supported. Supporting an arbitrary topology is more 876 difficult, however, since some form of pruning would seem to be 877 needed. 879 The advantage of the piggybacking scheme is that it allows for very 880 efficient information dissemination, particularly across multiple 881 routing domains (e.g. across different autonomous systems/ISPs) but 882 it does require that all nodes in the path, and not just the 883 participating edge routers, be able to accept such modified route 884 advertisements. On the other hand, significant administrative 885 complexity may be required to configure scoping mechanisms so as to 886 both permit and constrain the dissemination of the piggybacked 887 advertisements, and in itself this may be quite a configuration 888 burden. 890 Furthermore, unless some security mechanism is used for routing 891 updates so as to permit only all relevant edge routers to read the 892 piggybacked advertisements, this scheme generally implies a trust 893 model where all routers in the path must perforce be authorized to 894 know this information. Depending upon the nature of the routing 895 protocol, piggybacking may also require intermediate routers, 896 particularly autonomous system (AS) border routers, to cache such 897 advertisements and potentially also re-distribute them between 898 multiple routing protocols. 900 Each of the schemes described above have merit in particular 901 situations. Note that, in practice, there will almost always be some 902 directory or management system which will maintain VPRN membership 903 information, since, as noted above, the binding of VPRNs to stub 904 links must be configured, hence, presumably, such information would 905 be obtained from, and stored within, some database. Hence the 906 additional steps to facilitate the configuration of such information 907 into edge routers, and/or, facilitate edge router access to such 908 information, may not be excessively onerous. 910 6.1.3 Stub Link Reachability Information 912 There are two aspects to stub site reachability - the means by which 913 VPRN edge routers determine the set of VPRN addresses and address 914 prefixes reachable at each stub site, and the means by which the CPE 915 routers learn the destinations reachable via each stub link. A number 916 of common scenarios are outlined below. In each case the information 917 needed by the ISP edge router is the same - the set of VPRN addresses 918 reachable at the customer site, but the information needed by the CPE 919 router differs. 921 1. The CPE router is connected via one link to an ISP edge 922 router, which provides both VPRN and Internet connectivity. 924 This is the simplest case for the CPE router, as it just needs a 925 default route pointing to the ISP edge router. 927 2. The CPE router is connected via one link to an ISP edge 928 router, which provides VPRN, but not Internet, connectivity. 930 The CPE router must know the set of non-local VPRN destinations 931 reachable via that link - the VPRN default route. This may be a 932 single prefix, or may be a number of disjoint prefixes. The CPE 933 router may be either statically configured with this information, or 934 may learn it dynamically by running an instance of an IGP. For 935 simplicity it is assumed that the IGP used for this purpose is RIP, 936 though it could be any IGP. The ISP edge router will inject into this 937 instance of RIP the VPRN default route, which it learns by means of 938 one of the intra-VPRN reachability mechanisms described in section 939 6.1.4. Note that the instance of RIP run to the CPE, and any instance 940 of a routing protocol used to learn intra-VPRN reachability (even if 941 also RIP) are separate, with the ISP edge router redistributing the 942 routes from one instance to another. 944 3. The CPE router is multihomed to the ISP network, which 945 provides VPRN connectivity. 947 In this case all the ISP edge routers could advertise the same VPRN 948 default route to the CPE router, which then sees all VPRN prefixes 949 equally reachable via all links. More specific route redistribution 950 is also possible, whereby each ISP edge router advertises specific 951 prefixes (perhaps the ones locally connected) in addition to, or with 952 more favoured metrics than, the VPRN default route. 954 4. The CPE router is connected to the ISP network, which 955 provides VPRN connectivity, but also has a backdoor link 956 to another customer site 958 In this case the ISP edge router will advertise the VPRN default 959 route as in case 2. However now the same destination is reachable via 960 both the ISP edge router and via the backdoor link. If the CPE 961 routers connected to the backdoor link are running the customer's 962 IGP, then the backdoor link may always be the favoured link as it 963 will appear an an 'internal' path, whereas the destination as 964 injected via the ISP edge router will appear as an 'external' path 965 (to the customer's IGP). To avoid this problem, assuming that the 966 customer wants the traffic to traverse the ISP network, then a 967 separate instance of RIP should be run between the CPE routers at 968 both ends of the backdoor link, in the same manner as an instance of 969 RIP is run on a stub or backup link between a CPE router and an ISP 970 edge router. This will then also make the backdoor link appear as an 971 external path, and by adjusting the link costs appropriately, the ISP 972 path can always be favoured, unless it goes down, when the backdoor 973 link is then used. 975 The description of the above scenarios covers what reachability 976 information is needed by the ISP edge routers and the CPE routers, 977 and discusses some of the mechanisms used to convey this information. 979 The sections below look at these mechanisms in more detail. 981 A. Routing Protocol Instance: 983 A routing protocol can be run between the CPE edge router and the ISP 984 edge router to exchange reachability information. This allows an ISP 985 edge router to learn the VPRN prefixes reachable at a customer site, 986 and also allows a CPE router to learn the destinations reachable via 987 its stub links. 989 The extent of the routing domain for this protocol instance is 990 generally just the ISP edge router and the CPE router although if the 991 customer site is also running the same protocol as its IGP, then the 992 domain may extend into customer site. If the customer site is running 993 a different routing protocol then the CPE router redistributes the 994 routes between the instance running to the ISP edge router, and the 995 instance running into the customer site. 997 Given the typically restricted scope of this routing instance, a 998 simple protocol will generally suffice. RIPv2 [Malkin] is likely to 999 be the most common protocol used, though any routing protocol, such 1000 as OSPF [Moy], or BGP-4 [Rekhter2] run in internal mode (IBGP), could 1001 also be used. 1003 Note that the instance of the stub link routing protocol is different 1004 from any instance of a routing protocol used for intra-VPRN 1005 reachability. For example, if the ISP edge router uses routing 1006 protocol piggybacking to disseminate VPRN membership and reachability 1007 information across the core, then it may redistribute suitably 1008 labeled routes from the CPE routing instantiation to the core routing 1009 instantiation. The routing protocols used for each instantiation are 1010 decoupled, and any suitable protocol can be used in each case. There 1011 is no requirement that the same protocol, or even the same stub link 1012 reachability information gathering mechanism, be run between each CPE 1013 router and associated ISP edge router in a particular VPRN, since 1014 this is a purely local matter. 1016 This decoupling allows ISPs to deploy a common (across all VPRNs) 1017 intra-VPRN reachability mechanism, and a common stub link 1018 reachability mechanism, with these mechanisms isolated both from each 1019 other, and from the particular IGP used in a customer network. In the 1020 first case, due to the IGP-IGP boundary implemented on the ISP edge 1021 router, the ISP can insulate the intra-VPRN reachability mechanism 1022 from misbehaving stub link protocol instances. In the second case the 1023 ISP is not required to be aware of the particular IGP running in a 1024 customer site. Other scenarios are possible, where the ISP edge 1025 routers are running a routing protocol in the same instance as the 1026 customer's IGP, but are unlikely to be practical, since it defeats 1027 the purpose of a VPRN simplifying CPE router configuration. In cases 1028 where a customer wishes to run an IGP across multiple sites, a VPLS 1029 solution is more suitable. 1031 Note that if a particular customer site concurrently belongs to 1032 multiple VPRNs (or wishes to concurrently communicate with both a 1033 VPRN and the Internet), then the ISP edge router must have some means 1034 of unambiguously mapping stub link address prefixes to particular 1035 VPRNs. A simple way is to have multiple stub links, one per VPRN. It 1036 is also possible to run multiple VPRNs over one stub link. This could 1037 be done either by ensuring (and appropriately configuring the ISP 1038 edge router to know) that particular disjoint address prefixes are 1039 mapped into separate VPRNs, or by tagging the routing advertisements 1040 from the CPE router with the appropriate VPN identifier. For example 1041 if MPLS was being used to convey stub link reachability information, 1042 different MPLS labels would be used to differentiate the disjoint 1043 prefixes assigned to particular VPRNs. In any case, some 1044 administrative procedure would be required for this coordination. 1046 B. Configuration: 1048 The reachability information across each stub link could be manually 1049 configured, which may be appropriate if the set of addresses or 1050 prefixes is small and static. 1052 C. ISP Administered Addresses: 1054 The set of addresses used by each stub site could be administered and 1055 allocated via the VPRN edge router, which may be appropriate for 1056 small customer sites. In such a case the ISP edge router could 1057 determine these addresses by proxying for the particular address 1058 administration mechanism (e.g. DHCP). Note that in this case it 1059 would be the responsibility of the address allocation mechanism to 1060 ensure that each site in the VPN received a disjoint address space. 1061 Note also that an ISP would typically only use this mechanism for 1062 small stub sites, which are unlikely to have backdoor links. 1064 D. MPLS Label Distribution Protocol: 1066 In cases where the CPE router runs MPLS, the MPLS LDP could be 1067 extended to convey the set of prefixes at each stub site, together 1068 with the appropriate labeling information. While LDP is not 1069 generally considered a routing protocol per se, it may be useful to 1070 extend it for this particular constrained scenario. This is for 1071 further study. 1073 6.1.4 Intra-VPN Reachability Information 1075 Once an edge router has determined the set of prefixes associated 1076 with each of its stub links, then this information must be 1077 disseminated to each other edge router in the VPRN. Note also that 1078 there is an implicit requirement that the set of reachable addresses 1079 within the VPRN be locally unique that is, each VPRN stub link (not 1080 performing load sharing) maintain an address space disjoint from any 1081 other, so as to permit unambiguous routing. In practical terms, it 1082 is also generally desirable, though not required, that this address 1083 space be well partitioned i.e. specific, disjoint address prefixes 1084 per stub link, so as to preclude the need to maintain and disseminate 1085 large numbers of host routes. 1087 The intra-VPN reachability information dissemination can be solved in 1088 a number of ways, some of which include the following: 1090 A. Directory Lookup: 1092 Along with VPRN membership information, a central directory could 1093 maintain a listing of the address prefixes associated with each end 1094 point. Such information could be obtained by the server through 1095 protocol interactions with each edge router. Note that the same 1096 directory synchronization issues discussed above would apply in this 1097 case. 1099 B. Explicit Configuration: 1101 The address spaces associated with each edge router could be 1102 explicitly configured into each other router. This is clearly a non- 1103 scalable solution, particularly when arbitrary topologies are used, 1104 and also raises the question of how the management system learns such 1105 information in the first place. 1107 C. Local Intra-VPRN Routing Instantiations: 1109 In this approach, each edge router runs an instantiation of a routing 1110 protocol (a 'virtual router') per VPRN, running across the VPRN 1111 tunnels to each peer edge router, to disseminate intra-VPRN 1112 reachability information. Both full-mesh and arbitrary VPRN 1113 topologies can be easily supported, since the routing protocol itself 1114 can run over any topology. The intra-VPRN routing advertisements 1115 could be distinguished from normal tunnel data packets either by 1116 being addressed directly to the peer edge router, or by a tunnel 1117 specific mechanism. 1119 Note that this intra-VPRN routing protocol need have no relationship 1120 either with the IGP of each customer site or with the routing 1121 protocols operated by the ISPs in the IP backbone. Specifically, the 1122 intra-VPRN routing protocol operates as an overlay over the IP 1123 backbone, and could be a simple protocol, such as RIPv2 [Malkin], at 1124 least unless the VPRN spans a very large number of edge routers. 1125 Since the intra-VPN routing protocol runs as an overlay, it is also 1126 wholly transparent to any intermediate routers, and to any edge 1127 routers not within the VPRN. This also implies that such routing 1128 information can also remain opaque to such routers, which may be a 1129 necessary security requirements in some cases. 1131 If the tunnels over which an intra-VPRN routing protocol runs are 1132 dedicated to a specific VPN (e.g. a different multiplexing field is 1133 used for each VPN) then no changes are needed to the routing protocol 1134 itself. On the other hand if shared tunnels are used, then it is 1135 necessary to extend the routing protocol to allow a VPN-ID field to 1136 be included in routing update packets, to allow sets of prefixes to 1137 be associated with a particular VPN. 1139 D. Link Reachability Protocol 1141 Given a full mesh topology, each edge router could run a link 1142 reachability protocol - for instance, some variation of the MPLS LDP 1143 - across the tunnel to each peer edge router in the VPRN, carrying 1144 the VPN ID and the reachability information of each VPRN running 1145 across the tunnel between the two edge routers. The specification of 1146 such a protocol would need to include aspects of current routing 1147 protocols such as hello protocols, and re-transmit timers and/or 1148 positive acknowledgements. However, such an approach may reduce the 1149 processing burden of running routing protocol instantiations per 1150 VPRN, and may be of particular benefit where a shared tunnel 1151 mechanism is used to connect a set of edge routers supporting 1152 multiple VPRNs. 1154 Another approach to a link reachability protocol would be to base it 1155 on IBGP. The problem that needs to be solved by a link reachability 1156 protocol is very similar to that solved by IBGP - conveying address 1157 prefixes reliably between edge routers. 1159 Using a link reachability protocol it is straightforward to support a 1160 full mesh topology - each edge router conveys its own local 1161 reachability information to all other routers, but does not 1162 redistribute information received from any other router. However once 1163 an arbitrary topology needs to be supported, the link reachability 1164 protocol in effect develops into a full routing protocol, due to the 1165 need to implement mechanisms to avoid loops, and the issues discussed 1166 in section 6.1.4C above, apply. 1168 E. Piggybacking in IP Backbone Routing Protocols: 1170 As with VPRN membership, the set of address prefixes associated with 1171 each stub interface could also be piggybacked into the routing 1172 advertisements from each edge router and propagated through the 1173 network. Other edge routers would extract this information from 1174 received route advertisements in the same way as they would obtain 1175 the VPRN membership information (which, in this case, is implicit in 1176 the identification of the source of each route advertisement). Note 1177 that this scheme may require, depending upon the nature of the 1178 routing protocols involved, that intermediate routers, e.g. border 1179 routers, cache intra-VPRN routing information in order to propagate 1180 it further. This also has implications for the trust model, and for 1181 the level of security possible for intra-VPRN routing information. 1183 Note that in any of the cases discussed above, an edge router has the 1184 option of disseminating its stub link prefixes in a manner so as to 1185 permit tunneling from remote edge routers directly to the egress stub 1186 links. Alternatively, it could disseminate the information so as to 1187 associate all such prefixes with the edge router, rather than with 1188 specific stub links. In this case, the edge router would need to 1189 implement a VPN specific forwarding mechanism for egress traffic, to 1190 determine the correct egress stub link. The advantage of this is 1191 that it may significantly reduce the number of distinct tunnels or 1192 tunnel label information which need to be constructed and maintained. 1193 Note that this choice is purely a local manner and is not visible to 1194 remote edge routers. 1196 6.1.5 Tunneling Mechanisms 1198 Once VPRN membership information has been disseminated, the tunnels 1199 comprising the VPRN can be constructed. 1201 One approach to setting up the tunnel mesh is to use point-to-point 1202 IP tunnels, and the requirements and issues for such tunnels are 1203 discussed in section 5.0, on VLLs. For example while tunnel 1204 establishment can be done through manual configuration, this is 1205 clearly not likely to be a scalable solution, given the o(n^2) 1206 problem of meshed links. As such, tunnel set up should use some form 1207 of signaling protocol which would allow two nodes to construct a 1208 tunnel to each other knowing only each other's identity. 1210 Another approach is to use the multipoint to point 'tunnels' provided 1211 by MPLS. As noted in [Heinanen1], MPLS can be considered to be a 1212 form of IP tunneling, since the labels of MPLS packets allow for 1213 routing decisions to be decoupled from the addressing information of 1214 the packets themselves. MPLS label distribution mechanisms can be 1215 used to associate specific sets of MPLS labels with particular VPRN 1216 address prefixes supported on particular egress points (i.e. stub 1217 links of edge routers) and hence allow other edge routers to 1218 explicitly label and route traffic to particular VPRN stub links. 1220 One attraction of MPLS as a tunneling mechanism is that it may 1222 require less processing within each edge router than alternative 1223 tunneling mechanisms. This is a function of the fact that data 1224 security within a MPLS network is implicit in the explicit label 1225 binding, much as with a connection oriented network, such as Frame 1226 Relay. This may hence lessen customer concerns about data security 1227 and hence require less processor intensive security mechanisms (e.g. 1228 IPSec). However there are other potential security concerns with 1229 MPLS. There is no direct support for security features such as 1230 authentication, confidentiality, and non-repudiation and the trust 1231 model for MPLS means that intermediate routers, (which may belong to 1232 different administrative domains), through which membership and 1233 prefix reachability information is conveyed, must be trusted, not 1234 just the edge routers themselves. 1236 6.2 Multihomed Stub Routers 1238 The discussion thus far has implicitly assumed that stub routers are 1239 connected to one and only one VPRN edge router. In general, this 1240 restriction should be capable of being relaxed without any change to 1241 VPRN operation, given general market interest in multihoming for 1242 reliability and other reasons. In particular, in cases where the 1243 stub router supports multiple redundant links, with only one 1244 operational at any given time, with the links connected either to the 1245 same VPRN edge router, or to two or more different VPRN edge routers, 1246 then the stub link reachability mechanisms will both discover the 1247 loss of an active link, and the activation of a backup link. In the 1248 former situation, the previously connected VPRN edge router will 1249 cease advertising reachability to the stub node, while the VPRN edge 1250 router with the now active link will begin advertising reachability, 1251 hence restoring connectivity. 1253 An alternative scenario is where the stub node supports multiple 1254 active links, using some form of load sharing algorithm. In such a 1255 case, multiple VPRN edge routers may have active paths to the stub 1256 node, and may so advertise across the VPRN. This scenario should not 1257 cause any problem with reachability across the VPRN providing that 1258 the intra-VPRN reachability mechanism can accommodate multiple paths 1259 to the same prefix, and has the appropriate mechanisms to preclude 1260 looping - for instance, distance vector metrics associated with each 1261 advertised prefixes. This subject is for further study. 1263 6.3 Multicast Support 1265 Multicast and broadcast traffic can be supported across VPRN either 1266 by edge replication or by native multicast support in the backbone. 1267 These two cases are discussed below. 1269 6.3.1 Edge Replication 1271 This is where each VPRN edge router replicates multicast traffic for 1272 transmission across each link in the VPRN. Note that this is the same 1273 operation that would be performed by CPE routers terminating actual 1274 physical links or dedicated connections. As with CPE routers, 1275 multicast routing protocols could also be run on each VPRN edge 1276 router to determine the distribution tree for multicast traffic and 1277 hence reduce unnecessary flood traffic. This could be done by running 1278 an instantiation of standard multicast routing protocols, e.g. 1279 Protocol Independent Multicast (PIM) [Estrin] or the Distance Vector 1280 Multicast Routing Protocol (DVMRP) [Waitzman], on and between each 1281 VPRN edge router, through the VPRN tunnels, in the same way that 1282 unicast routing protocols might be run at each VPRN edge router to 1283 determine intra-VPN unicast reachability, as discussed in Section 1284 6.1.4. Alternatively, if a link reachability protocol was run across 1285 the VPRN tunnels for intra-VPRN reachability, then this could also be 1286 augmented to allow VPRN edge routers to indicate both the particular 1287 multicast groups requested for reception at each edge node, and also 1288 the multicast sources at each edge site. 1290 In either case, there would need to be some mechanism to allow for 1291 the VPRN edge routers to determine which particular multicast groups 1292 were requested at each site and which sources were present at each 1293 site. How this could be done would, in general, be a function of the 1294 capabilities of the CPE stub routers at each site. If these could 1295 also run multicast routing protocols, then these could interact 1296 directly with the equivalent protocols at each VPRN edge router, else 1297 they could forward the Internet Group Management Protocol (IGMP) 1298 [Fenner] packets to the VPRN edge router for appropriate processing. 1300 6.3.2 Native Multicast Support 1302 This is where VPRN edge routers map intra-VPN multicast traffic onto 1303 a native IP multicast distribution mechanism across the backbone. 1304 Note that the latter is not synonymous with the use of native 1305 multicast mechanisms per se - e.g. the use of IP multicast across the 1306 backbone - since intra-VPN multicast has the same requirements for 1307 isolation from general backbone traffic as intra-VPRN unicast 1308 traffic. Currently the only IP tunneling mechanism that has native 1309 support for multicast is MPLS. On the other hand, while MPLS 1310 supports native transport of IP multicast packets, additional 1311 mechanisms would be needed to leverage these mechanisms for the 1312 support of intra-VPN multicast. 1314 For instance, each VPRN router could prefix multicast group addresses 1315 within each VPRN with the VPN ID of that VPRN and then redistribute 1316 these, essentially treating this VPN ID/intra-VPRN multicast address 1317 tuple as a normal multicast address, within the backbone multicast 1318 routing protocols, as with the case of unicast reachability, as 1319 discussed previously. The MPLS multicast label distribution 1320 mechanisms could then be used to set up the appropriate multicast 1321 LSPs to interconnect those sites within each VPRN supporting 1322 particular multicast group addresses. Note, however, that this would 1323 require each of the intermediate LSRs to not only be aware of each 1324 intra-VPRN multicast group, but also to have the capability of 1325 interpreting these modified advertisements. Alternatively, 1326 mechanisms could be defined to map intra-VPRN multicast groups into 1327 backbone multicast groups. The details of such mechanisms are for 1328 further study. 1330 Other IP tunneling mechanisms do not have native multicast support. 1331 It may prove feasible to extend such tunneling mechanisms by 1332 allocating IP multicast group addresses to the VPRN as a whole and 1333 hence distributing intra-VPRN multicast traffic encapsulated within 1334 backbone multicast packets. Edge VPRN routers could filter out 1335 unwanted multicast groups. Alternatively, mechanisms could also be 1336 defined to allow for allocation of backbone multicast group addresses 1337 for particular intra-VPRN multicast groups, and to then utilize 1338 these, through backbone multicast protocols, as discussed above, to 1339 limit forwarding of intra-VPRN multicast traffic only to those nodes 1340 within the group. The details of such mechanisms are for further 1341 study. 1343 A particular issue with the use of native multicast support is the 1344 provision of security for such multicast traffic. Unlike the case of 1345 edge replication, which inherits the security characteristics of the 1346 underlying tunnel, native multicast mechanisms will need to use some 1347 form of secure multicast mechanism. At present, most aspects of such 1348 mechanisms, for instance using IPSec, are not wholly specified 1349 [Wallner] and further study will likely be needed before secure 1350 native multicast mechanisms can be generally deployed. 1352 6.4 Specification Recommendations 1354 There have already been proposals for adapting routing protocols to 1355 carry VPN information to support the router piggybacking mechanisms 1356 [Heinanen1], particularly in MPLS networks. Some ISPs, however, may 1357 prefer schemes that do not couple VPN membership and reachability 1358 mechanisms with the backbone routing protocols, hence a set of 1359 mechanisms that do not require piggybacking should also be 1360 standardized. In particular the following are needed 1362 - a standard format for a globally unique VPN identifier. 1364 - a membership distribution protocol based on a directory or MIB. 1366 Also for the constrained case of a full mesh topology, the usefulness 1367 of developing a link reachability protocol could be examined. 1368 Extending routing protocols to allow a VPN-ID to carried in routing 1369 update packets could also be examined, but is not necessary if VPN 1370 specific tunnels are used. 1372 Note also that the MPLS WG group is working on MPLS-specific 1373 mechanisms for VPRNs [Heinanen2]. 1375 7.0 VPN Types: Virtual Private Dial Networks 1377 A virtual private dial network (VPDN) allows for remote users to 1378 connect on demand into remote sites through ad hoc tunnels. The 1379 distinguishing characteristic of such ad hoc connections is their 1380 binding between a particular user and a central site. As such, user 1381 authentication, through whatever means, is a prime requirement. 1383 Most such connections are made today through dial connections made 1384 through the PSTN, with users setting up PPP connections across an 1385 access network to a Network Access Server (NAS), at which point the 1386 PPP sessions are authenticated using AAAA systems running such 1387 standard protocols as RADIUS [Rigney]. Given the pervasive 1388 deployment of such systems, any VPDN system must practically allow 1389 for the near transparent re-use of such existing systems. 1391 There has been significant work completed on the Layer 2 Tunneling 1392 Protocol (L2TP) [Valencia1], building upon the earlier PPTP [Zorn] 1393 and L2F [Valencia2] protocols. L2TP allows for the extension of user 1394 PPP sessions from a L2TP access concentrator (LAC) to a remote L2TP 1395 network server (LNS). Notwithstanding, however, the widespread 1396 industry support for L2TP, there are two quite different VPDN 1397 scenarios, which may call for different solutions. 1399 7.1 Compulsory Tunneling 1401 Compulsory tunneling refers to a case in which a network node - a 1402 dial or network access server, for instance - acting as a LAC, 1403 extends a PPP session across a backbone using L2TP to a remote LNS. 1405 This operation is transparent to the user initiating the PPP session 1406 to the LAC. Support of this scenario was the original intent of the 1407 L2F specification, upon which the L2TP specification was based. 1409 Compulsory tunneling was originally intended for deployment on dial 1410 access servers supporting VPDN or wholesale dial services, allowing 1411 for remote dial access through common facilities to an enterprise 1412 site, while precluding the need for the enterprise to deploy its own 1413 dial servers. More recently, compulsory tunneling mechanisms have 1414 also been proposed for evolving xDSL services [ADSL1], [ADSL2], which 1415 also seek to leverage the existing AAAA infrastructure. 1417 7.1.1 Call Routing 1419 Call routing for compulsory tunnels requires that some aspect of the 1420 initial PPP call set up can be used to allow the LAC to determine the 1421 identity of the LNS. As noted in [Aboba1], these aspects can include 1422 the user identity, as determined through some aspect of the access 1423 network, including calling party number, or some attribute of the 1424 called party, such as the fully qualified domain name (FQDN) of the 1425 CHAP/PAP user name. 1427 7.1.2 Security Mechanisms 1429 By allowing for the transparent extension of PPP from the user, 1430 through the LAC to the LNS, L2TP allows for the use of whatever 1431 security mechanisms, with respect to both connection set up, and data 1432 transfer, may be used with normal PPP connections. However this does 1433 not provide security for the L2TP control protocol itself. In this 1434 case L2TP could be further secured by running it over IPSec through 1435 IP backbones [Patel], or related mechanisms on non-IP backbones 1436 [Calhoun2]. 1438 The interaction of L2TP with AAAA systems for user authentication and 1439 authorization is a function of the specific means by which L2TP is 1440 used, and the nature of the devices supporting the LAC and the LNS. 1441 These issues are discussed in depth in [Aboba1]. 1443 The means by which the host determines the correct LAC to connect to, 1444 and the means by which the LAC determines which users to further 1445 tunnel, and the LNS parameters associated with each user, are outside 1446 the scope of the operation of VPDN, but may be addressed, by for 1447 instance, evolving Internet roaming specifications [Aboba2]. 1449 7.1.3 Traffic Management 1451 L2TP support a complex flow control scheme that can be requested by 1452 either party in order to minimize packet loss due to receiver 1453 congestion. Furthermore, L2TP, by transparently extending PPP, has 1454 inherent support for such PPP mechanisms as multi-link PPP [Sklower] 1455 and its associated control protocols [Richard], which allow for 1456 bandwidth on demand to meet user requirements. Beyond these 1457 capabilities, L2TP itself does not have any specific traffic 1458 management mechanisms. As noted also for VLLs, however, L2TP calls 1459 could be mapped into whatever underlying traffic management 1460 mechanisms may exist in the network, and there are proposals to allow 1461 for requests through L2TP signaling for specific differentiated 1462 services behaviors [Calhoun1]. 1464 7.1.4 Call Multiplexing 1466 L2TP has inherent support for the multiplexing of multiple calls from 1467 different users over a single link. Between the same two IP 1468 endpoints, there can be multiple L2TP tunnels, as identified by a 1469 tunnel-id, and multiple calls within a tunnel, as identified by a 1470 call-id. 1472 7.1.5 Address Management 1474 Since L2TP is designed to transparently extend PPP, it does not 1475 attempt to supplant the normal address assignment mechanisms 1476 associated with PPP. Hence, in general terms the host initiating the 1477 PPP session will be assigned addressing by the LNS using PPP 1478 procedures. This addressing may have no relation to the addressing 1479 used for communication between the LAC and LNS. The LNS will also 1480 need to support whatever forwarding mechanisms are needed to route 1481 traffic to and from the remote host. 1483 7.1.6 Support for Large MTUs 1485 As with VLLs, it cannot be assumed that the MTU of the VPDN tunnel is 1486 necessarily less than or equal to that of the underling IP route, 1487 though the host may adjust the PPP payload MTU to preclude 1488 fragmentation. To this end, there are proposals to allow the use of 1489 MTU discovery for cases where the L2TP tunnel transports IP frames 1490 [Shea]. 1492 7.2 Voluntary Tunnels 1494 A voluntary tunneling refers to cases where an individual host 1495 connects to a remote site using a tunnel originating on the host, 1496 with no involvement from intermediate network nodes. The PPTP 1497 specification, parts of which have been incorporated into L2TP, was 1498 based upon a voluntary tunneling model. 1500 The L2TP specification has support for voluntary tunneling, insofar 1501 as the LAC can be located on a host, not only on a network node. 1502 Note that such a host has two IP addresses - one for the LAC - LNS IP 1503 tunnel, and another, typically allocated via PPP, for the network to 1504 which the host is connecting. 1506 There has also been discussion, however, that PPP, and hence either 1507 L2TP or PPTP, may be unnecessary and excessively burdensome for 1508 voluntary tunnels, particularly when they need to be paired with 1509 IPSec for security purposes. It is proposed in [Gupta] that IPSec 1510 alone be used for voluntary tunnels, with the tunnels terminating on 1511 IPSec edge devices at the enterprise site. In this case IPSec will be 1512 used in tunnel mode, and the host will have two IP addresses, in a 1513 similar manner to the L2TP case. (Alternatively the host could use 1514 one IP address as the source IP address in both the inner and outer 1515 IP headers, with the gateway performing NAT before forwarding the 1516 inner header, after IPSec processing). The IPSec WG is currently 1517 examining this area, with the intent of developing authentication 1518 schemes tailored towards remote hosts, and to allow certain 1519 configuration parameters, such as the host's IP address and DNS 1520 server, to be configured via IKE. 1522 Using IPSec as the basis of a voluntary tunnel mechanism may yield a 1523 much lower overhead solution than the use of PPP and L2TP, but it 1524 does require either changes to host protocol stacks, or the use of 1525 host 'shims' to intercept and forward packets to VPDNs through IPSec. 1526 A number of proprietary solutions of the latter sort are currently 1527 commercially available, hence a standard mechanism may well be 1528 desirable. 1530 7.3 Networked Host Support 1532 The current PPP based dial model assumes a host directly connected to 1533 a connection oriented dial access network. Recent work on new access 1534 technologies such a xDSL have attempted to replicate this model 1535 [ADSL], so as to allow for the re-use of existing AAAA systems. The 1536 proliferation of personal computers, printers and other network 1537 appliances in homes and small businesses, and the ever lowering costs 1538 of networks, however, are increasingly challenging the directly 1539 connected host model. Increasingly, most hosts will access the 1540 Internet through small, typically Ethernet, local area networks 1541 (LANs). 1543 There is hence interest in means of accommodating the existing AAAA 1544 infrastructure within service providers, whilst also supporting 1545 multiple networked hosts at each customer site. The principal 1546 complication with this scenario is the need to support the login 1547 dialogue, through which the appropriate AAAA information is 1548 exchanged. A number of proposals have been made to address this 1549 scenario: 1551 A. Extension of PPP to Hosts Through L2TP: 1553 A number of proposals (e.g. [ADSL1]) have been made to extend L2TP 1554 over Ethernet so that PPP sessions can run from networked hosts out 1555 to the network, in much the same manner as a directly attached host. 1557 B. Extension of PPP Directly to Hosts: 1559 There are also proposals to map PPP directly onto Ethernet ([Evarts], 1560 [Shieh1], [Shieh2]), and to use a broadcast mechanism to allow hosts 1561 to find appropriate access servers with which to connect. Presumably 1562 such servers could then further tunnel, if needed, the PPP sessions 1563 using L2TP or similar mechanism. 1565 C. Use of IPSec: 1567 The IPSec based voluntary tunneling mechanism discussed above is 1568 independent of either access method or PPP and hence could as easily 1569 be used with networked or directly connected hosts. 1571 All of these methods require either host protocol changes, but the 1572 former two do allow the continued use of the various ancillary 1573 mechanisms of PPP, including address allocation, autoconfiguration, 1574 etc, albeit at the cost of greater overhead. 1576 7.4 Specification Recommendations 1578 The L2TP specifications are currently near finalization and hence are 1579 the clear choice for VPDNs using compulsory tunneling. Further study 1580 needs to be done, however, to determine the most appropriate solution 1581 for voluntary tunneling. On approach is a PPP based solution, running 1582 over L2TP or some other form of link emulation protocol for the 1583 networked host scenario. Another approach is an IPSec based 1584 mechanism, with extensions to IKE for necessary host configuration. 1585 In the latter case, it may be desirable to maximize commonality with 1586 any IPSec based VLL tunneling mechanism. 1588 8.0 VPN Types: Virtual Private LAN Segment 1590 8.0 VPN Types: Virtual Private LAN Segment 1592 A virtual private LAN segment (VPLS) is the emulation of a LAN 1593 segment using Internet facilities. A VPLS can be used to provide what 1594 is sometimes known also as a transparent LAN service (TLS), which can 1595 be used to interconnect multiple stub CPE nodes, either bridges or 1596 routers, in a protocol transparent manner. A VPLS emulates a LAN 1597 segment over IP, in the same way as protocols such as LANE [ATMF1] 1598 emulate a LAN segment over ATM. The primary benefits of a VPLS are 1599 complete protocol transparency, which may be important both for 1600 multiprotocol transport and for regulatory reasons in particular 1601 service provider contexts. 1603 8.1 VPLS Requirements 1605 Topologically and operationally a VPLS can be most easily modelled as 1606 being essentially equivalent to a VPRN, except that each VPLS edge 1607 node implements link layer bridging rather than network layer 1608 forwarding. As such, most of the VPRN tunneling and configuration 1609 mechanisms discussed previously can also be used for a VPLS, with the 1610 appropriate changes to accommodate link layer, rather than network 1611 layer, packets and addressing information. The following sections 1612 discuss the primary changes needed in VPRN operation to support 1613 VPLSs. 1615 8.1.1 Tunneling Protocols 1617 The tunneling protocols employed within a VPLS could be exactly the 1618 same as those used within a VPRN, if the tunneling protocol permitted 1619 the transport of multiprotocol traffic. Since the primary tunneling 1620 protocols discussed thus far have this capability, this will be 1621 assumed below. 1623 8.1.2 Multicast and Broadcast Support 1625 A VPLS needs to have a broadcast capability. This is needed both for 1626 broadcast frames, and for link layer packet flooding, where a unicast 1627 frame is flooded because the path to the destination link layer 1628 address is unknown. The address resolution protocols that run over a 1629 bridged network typically use broadcast frames (e.g. ARP). The same 1630 set of possible multicast tunneling mechanisms discussed earlier for 1631 VPRNs apply also to a VPLS, though the generally more frequent use of 1632 broadcast in VPLSs may increase the pressure for native multicast 1633 support that reduces, for instance, the burden of replication on VPLS 1634 edge nodes. 1636 8.1.3 VPLS Membership Configuration and Topology 1638 The configuration of VPLS membership is analogous to that of VPRNs 1639 since this generally requires only knowledge of the local VPN link 1640 assignments at any given VPLS edge node, and the identity of, or 1641 route to, the other edge nodes in the VPLS; in particular, such 1642 configuration is independent of the nature of the forwarding at each 1643 VPN edge node. As such, any of the mechanisms for VPN member 1644 configuration and dissemination discussed for VPRN configuration can 1645 also be applied to VPLS configuration. Also as with VPRNs, the 1646 topology of the VPLS could be easily manipulated by controlling the 1647 configuration of peer nodes at each VPLS edge node, assuming that the 1648 membership dissemination mechanism was such as to permit this. It is 1649 likely that typical VPLSs will be fully meshed, however, in order to 1650 preclude the need for traffic between two VPLS nodes to transit 1651 through another VPLS node, which would then require the use of the 1652 spanning tree protocol [IEEE] for loop prevention. 1654 8.1.4 CPE Stub Node Types 1656 Unlike a VPLS in which the CPE nodes are assumed to be routers, a 1657 VPLS can support either bridges or routers as a CPE device. 1659 CPE routers would peer transparently across a VPLS with each other 1660 without requiring any router peering with any nodes within the VPLS. 1661 The same scalability issues that apply to a full mesh topology for 1662 VPRNs, apply also in this case, only that now the number of peering 1663 routers is potentially greater, since the ISP edge device is no 1664 longer acting as an aggregation point. 1666 With CPE bridge devices the broadcast domain encompasses all the CPE 1667 sites as well as the VPLS itself. There are severe scalability 1668 constraints in this case, due to the need for packet flooding, and 1669 the fact that any topology change in the bridged domain is not 1670 localized, but is visible throughout the domain. As such this 1671 scenario is generally only suited for non-routable protocols. 1673 The nature of the CPE impacts the nature of the encapsulation, 1674 addressing, forwarding and reachability protocols within the VPLS, 1675 and are discussed separately below. 1677 8.1.5 Stub Link Packet Encapsulation 1679 A. Bridge CPE: 1681 In this case, packets sent to and from the VPLS across stub links are 1682 link layer frames, with a suitable access link encapsulation. The 1683 most common case is likely to be ethernet frames, using an 1684 encapsulation appropriate to the particular access technology, such 1685 as ATM, connecting the CPE bridges to the VPLS edge nodes. Such 1686 frames are then forwarded at layer 2 onto a tunnel used in the VPLS. 1687 As noted previously, this does mandate the use of an IP tunneling 1688 protocol which can transport such link layer frames. Note that this 1689 does not necessarily mandate, however, the use of a protocol 1690 identification field in each tunnel packet, since the nature of the 1691 encapsulated traffic (e.g. ethernet frames) could be indicated at 1692 tunnel setup. 1694 B. Router CPE: 1696 In this case, typically, CPE routers send link layer packets to and 1697 from the VPLS across stub links, destined to the link layer addresses 1698 of their peer CPE routers. Other types of encapsulations may also 1699 prove feasible in such a case, however, since the relatively 1700 constrained addressing space needed for a VPLS to which only router 1701 CPE are connected, could allow for alternative encapsulations, as 1702 discussed further below. 1704 8.1.6 CPE Addressing and Address Resolution 1706 A. Bridge CPE: 1708 Since a VPLS operates at the link layer, all hosts within all stub 1709 sites, in the case of bridge CPE, will typically be in the same 1710 network layer subnet. (Multinetting, whereby multiple subnets 1711 operate over the same LAN segment, is possible, but much less 1712 common). Frames are forwarded across and within the VPLS based upon 1713 the link layer addresses - e.g. IEEE MAC addresses - associated with 1714 the individual hosts. The VPLS needs to support broadcast traffic, 1715 such as that typically used for the address resolution mechanism used 1716 to map the host network addresses to their respective link addresses. 1717 The VPLS forwarding and reachability algorithms also need to be able 1718 to accommodate flooded traffic. 1720 B. Router CPE: 1722 A single network layer subnet is generally used to interconnect 1723 router CPE devices, across a VPLS. Behind each CPE router are hosts 1724 in different network layer subnets. CPE routers transfer packets 1725 across the VPLS by mapping next hop network layer addresses to the 1726 link layer addresses of a router peer. A link layer encapsulation is 1727 used, most commonly ethernet, as for the bridge case. 1729 As noted above, however, in cases where all of the CPE nodes 1730 connected to the VPLS are routers, then it may be possible, due to 1731 the constrained addressing space of the VPLS, to use encapsulations 1732 that use a different address space than normal MAC addressing. See, 1733 for instance, [Jamieson], for a proposed mechanism for VPLSs over 1734 MPLS networks, leveraging earlier work on VPRN support over MPLS 1735 [Heinanen1], which proposes MPLS as the tunneling mechanism, and 1736 locally assigned MPLS labels as the link layer addressing scheme to 1737 identify the CPE LSR routers connected to the VPLS. 1739 8.1.7 VPLS Edge Node Forwarding and Reachability Mechanisms 1741 A. Bridge CPE: 1743 The only practical VPLS edge node forwarding mechanism in this case 1744 is likely to be standard link layer packet flooding and MAC address 1745 learning, as per [IEEE]. As such, no explicit intra-VPLS reachability 1746 protocol will be needed, though there will be a need for broadcast 1747 mechanisms to flood traffic, as discussed above. In general, it may 1748 not prove necessary to also implement the spanning tree protocol 1749 [IEEE] between VPLS edge nodes, if the VPLS topology is such that no 1750 VPLS edge node is used for transit traffic between any other VPLS 1751 edge nodes - in other words, where there is both full mesh 1752 connectivity and transit is explicitly precluded. On the other hand, 1753 the CPE bridges may well implement the spanning tree protocol in 1754 order to safeguard against 'backdoor' paths that bypass connectivity 1755 through the VPLS. 1757 B. Router CPE: 1759 Standard bridging techniques can also be used in this case. In 1760 addition, the smaller link layer address address space of such a VPLS 1761 may also permit other techniques, with explicit link layer routes 1762 between CPE routers. [Jamieson], for instance, proposes that MPLS 1763 LSPs be set up, at the insertion of any new CPE router into the VPLS, 1764 between all CPE LSRs. This then precludes the need for packet 1765 flooding. In the more general case, if stub link reachability 1766 mechanisms were used to configure VPLS edge nodes with the link layer 1767 addresses of the CPE routers connected to them, then modifications of 1768 any of the intra-VPN reachability mechanisms discussed for VPRNs 1769 could be used to propagate this information to each other VPLS edge 1770 node. This would then allow for packet forwarding across the VPLS 1771 without flooding. 1773 Mechanisms could also be developed to further propagate the link 1774 layer addresses of peer CPE routers and their corresponding network 1775 layer addresses across the stub links to the CPE routers, where such 1776 information could be inserted into the CPE router's address 1777 resolution tables. This would then also preclude the need for 1778 broadcast address resolution protocols across the VPLS. 1780 Clearly there would be no need for the support of spanning tree 1781 protocols if explicit link layer routes were determined across the 1782 VPLS. If normal flooding mechanisms were used then spanning tree 1783 would only be required again only if full mesh connectivity was not 1784 available and hence VPLS nodes had to carry transit traffic. 1786 8.2 Specification Recommendations 1788 There is significant commonality between VPRNs and VPLSs, and, where 1789 possible, this similarity should be exploited in order to reduce 1790 development and configuration complexity. In particular, VPLSs should 1791 utilize the same tunneling and membership configuration mechanisms, 1792 with changes only to reflect the specific characteristics of VPLSs. 1793 Since one of the primary advantages of VPLSs is protocol 1794 transparency, it is likely that any general VPLS specification will 1795 need to support bridge CPE. As such, development of VPLS 1796 encapsulation, forwarding and reachability protocol mechanisms should 1797 prioritize support of bridge CPE through the support of ethernet 1798 encapsulations and standard link layer flooding and address learning 1799 mechanisms. 1801 As with VPRNs, there may be a need for specific mechanisms (e.g. 1802 [Jamieson]) for MPLS networks, and more generic mechanisms for non- 1803 MPLS networks. 1805 9.0 Summary of Recommendations 1807 In this Draft different types of VPNs have been discussed 1808 individually, but there are many common requirements and mechanisms 1809 that apply to all types of VPNs, and many networks will contain a mix 1810 of different types of VPNs. It is useful to have as much commonality 1811 as possible across these different VPN types. In particular, by 1812 standardizing a relatively small number of mechanisms, it is possible 1813 to allow a wide variety of VPNs to be implemented. To this end 1814 serious consideration should be given to standardization efforts in 1815 the following areas 1817 - defining a generic VPN tunneling protocol (section 5.1) 1819 - defining a globally unique VPN identifier (section 6.1.1) 1821 - defining a VPN membership information configuration and 1822 dissemination mechanism, that uses some form of directory or MIB 1823 (section 6.1.2 A,B) 1825 Also the usefulness of defining a VPN link reachability protocol for 1826 the constrained case of a full mesh topology (section 6.1.4 D), could 1827 be examined. 1829 This is in addition to the work being done on MPLS-specific 1830 mechanisms in the MPLS WG. 1832 10.0 Security considerations 1834 Security considerations are an integral part of any VPN mechanisms, 1835 and these are discussed in the sections describing those mechanisms. 1837 11.0 Acknowledgements 1839 Thanks to Anthony Alles, of Shasta Networks, for his invaluable 1840 assistance in the generation of this Draft, and to Joel Halpern, of 1841 Newbridge Networks, for his helpful review comments. 1843 12.0 References 1845 [Aboba1] Aboba, B. and Zorn, G. - "Implementation of PPTP/L2TP 1846 Compulsory Tunneling via RADIUS", draft-ietf-radius-tunnel-imp- 1847 03.txt. 1849 [Aboba2] Aboba, B. and Zorn, G. - "Requirements for Internet 1850 Roaming", draft- ietf-roamops-roamreq-10.txt. 1852 [ADSL1] ADSL Forum - "An Interoperable End-to-end Broadband Service 1853 Architecture over ADSL Systems (Version 3.0)", ADSL Forum 97-215. 1855 [ADSL2] ADSL Forum - "Core Network Architectures for ADSL Access 1856 Systems (Version 1.01)", ADSL Forum 998-017. 1858 [ATMF1] ATM Forum - "LAN Emulation over ATM 1.0", af-lane-0021.000, 1859 January 1995. 1861 [ATMF2] ATM Forum - "Multi-Protocol Over ATM Specification v1.0", 1862 af-mpoa-0087.000, June 1997. 1864 [Bates] Bates, T. "Multiprotocol Extensions for BGP-4", RFC 2283. 1866 [Bernet] Bernet, Y., et al - "A Framework for Differentiated 1867 Services", draft-ietf-diffserv-framework-00.txt. 1869 [Calhoun1] Calhoun, P. and Peirce, K. - "Layer Two Tunneling Protocol 1870 "L2TP" IP Differential Services Extension", draft-ietf-pppext-l2tp- 1871 ds-02.txt. 1873 [Calhoun2] Calhoun, P., et al - "Layer Two Tunneling Protocol "L2TP" 1874 Security Extensions for Non-IP networks", draft-ietf-pppext-l2tp- 1875 sec-04.txt. 1877 [Calhoun3] Calhoun, P. et al - "Tunnel Establishment Protocol", 1878 draft-ietf-mobileip-calhoun-tep-01.txt. 1880 [Callon] Callon, R., et al "Multiprotocol Label Switching 1881 Architecture", draft-ietf-mpls-arch-02.txt. 1883 [Chandra] Chandra, R. and Traina, P. "BGP Communities Attribute", 1884 RFC 1998. 1886 [Coltun] Coltun, R. "The OSPF Opaque LSA Option", RFC 2370. 1888 [Davie] Davie, B., et al - "Use of Label Switching with RSVP", 1889 draft-ietf-mpls-rsvp-00.txt 1891 [Estrin] Estrin, D., et al - "Protocol Independent Multicast-Sparse 1892 Mode (PIM-SM) Protocol Specification", RFC 2362. 1894 [Evarts] Evarts, J., et al - "PPP Over Ethernet "PPPOE"", draft- 1895 carrel-info- pppoe-00.txt. 1897 [Fenner] Fenner, W. - "Internet Group Management Protocol, Version 1898 2", RFC 2236. 1900 [Ferguson] Ferguson, P. and Huston, G. - "What is a VPN?", Revision, 1901 April 1 1998; http://www.employees.org:80/~ferguson/vpn.pdf. 1903 [Gupta] Gupta, V. - "Secure, Remote Access over the Internet using 1904 IPSec", draft-gupta-ipsec-remote-access-00.txt. 1906 [Hanks] Hanks, S., et al "Generic Routing Encapsulation over Ipv4 1907 Networks", RFC 1702. 1909 [Harkins] Harkins, D. and Carrel, D. "The Internet Key Exchange 1910 (IKE)", draft-ietf-ipsec-isakmp-oakley-08.txt. 1912 [Heinanen1] Heinanen, J. and Rosen, E. "VPN Support with MPLS" 1913 draft-heinanen-mpls-vpn-01.txt. 1915 [Heinanen2] Heinanen, J., et al - "MPLS Mappings of Generic VPN 1916 Mechanisms", draft-heinanen-generic-vpn-mpls-00.txt. 1918 [IEEE] ANSI/IEEE - 10038: 1993 (ISO/IEC) Information technology -- 1919 Telecommunications and information exchange between systems -- Local 1920 area networks -- Media access control (MAC) bridges, ANSI/IEEE Std 1921 802.1D, 1993 Edition. 1923 [Jamieson] Jamieson, D., et al - "MPLS VPN Architecture", draft- 1924 jamieson-mpls-vpn-00.txt. 1926 [Kent] Kent, S. and Atkinson, R. "Security Architecture for the 1927 Internet Protocol", draft-ietf-ipsec-arch-sec-06.txt. 1929 [Li] Li, T. and Rekhter, Y. - "Provider Architecture for 1930 Differentiated Services and Traffic Engineering (PASTE)", draft-li- 1931 paste-00.txt. 1933 [Malkin] Malkin, G. "RIP Version 2 Carrying Additional 1934 Information", RFC 1723. 1936 [Moy] Moy, J. "OSPF Version 2", RFC 2328. 1938 [Patel] Patel, B. and Aboba, B. - "Securing L2TP using IPSEC", 1939 draft-ietf- pppext-l2tp-security-02.txt. 1941 [Rekhter1] Rekhter, Y., et al "Address Allocation for Private 1942 Internets", RFC 1918. 1944 [Rekhter2] Rekhter, Y. and Li, T. "A Border Gateway Protocol 4 1945 (BGP-4)", RFC 1771. 1947 [Rekhter3] Rekhter, Y. and Rosen, E. "Carrying Label Information in 1948 BGP-4", draft-ietf-mpls-bgp4-mpls-00.txt. 1950 [Rigney] Rigney, C., et al - "Remote Authentication Dial In User 1951 Service (RADIUS)", RFC 2138. 1953 [Richard] Richard, C. and Smith, K. - "The PPP Bandwidth Allocation 1954 Protocol (BAP), The PPP Bandwidth Allocation Control Protocol (BACP)" 1955 RFC 2125. 1957 [Valencia1] Valencia, A., et al - "Layer Two Tunneling Protocol 1958 'L2TP'", draft-ietf-pppext-l2tp-11.txt. 1960 [Shacham] Shacham, A., et al - "IP Payload Compression Protocol 1961 (IPComp)", draft-ietf-ippcp-protocol-06.txt. 1963 [Shea] Shea, R. - "L2TP-over-IP Path MTU Discovery (''L2TPMTU'')", 1964 draft- ietf-pppext-l2tpmtu-00.txt. 1966 [Shieh1] Shieh, P et al. "The Architecture for Extending PPP 1967 Connections for Home Network Clients", ADSL Forum contribution 98- 1968 140. 1970 [Shieh2] Shieh, P et al. "The Requirement and Comparisons of 1971 Extending PPP over Ethernet", ADSL Forum contribution 98-141. 1973 [Simpson] Simpson, W. "IP in IP Tunneling", RFC 1853. 1975 [Sklower] Sklower, K., et al - "The PPP Multilink Protocol (MP)", RFC 1976 1990. 1978 [Srisuresh] Srisuresh, P. and Holdrege, M. - "IP Network Address 1979 Translator (NAT) Terminology and Considerations", draft-ietf-nat- 1980 terminology-00.txt. 1982 [Thomas] Thomas, B., et al - "LDP Specification", draft-ietf-mpls- 1983 ldp-01.txt. 1985 [Valencia2] Valencia, A., et al "Cisco Layer Two Forwarding 1986 (Protocol) "L2F"", RFC 2341. 1988 [Waitzman] Waitzman, D., et al - "Distance Vector Multicast Routing 1989 Protocol", RFC 1075. 1991 [Wallne] Wallner, D., et al - "Key Management for Multicast: Issues 1992 and Architectures", draft-wallner-key-arch-01.txt. 1994 [Zorn] Zorn, G., et al - "Point-to-Point Tunneling Protocol--PPTP", 1995 draft- ietf-pppext-pptp-04.txt. 1997 13.0 Author Information 1999 Bryan Gleeson 2000 Shasta Networks 2001 249 Humboldt Court 2002 Sunnyvale CA 94089-1300 2003 USA 2004 Tel: +1 (408) 548 3711 2005 Email: bgleeson@shastanets.com 2007 Juha Heinanen 2008 Telia Finland, Inc. 2009 Myyrmaentie 2 2010 01600 VANTAA 2011 Finland 2012 Tel: +358 303 944 808 2013 Email: jh@telia.fi 2015 Arthur Lin 2016 Shasta Networks 2017 249 Humboldt Court 2018 Sunnyvale CA 94089-1300 2019 USA 2020 Tel: +1 (408) 548 3788 2021 Email: alin@shastanets.com 2023 Grenville Armitage 2024 Bell Labs, Lucent Technologies 2025 101 Crawfords Corner Rd 2026 Holmdel, NJ 07733-3030 2027 USA 2028 Email: gja@lucent.com 2030 14.0 Full Copyright Statement 2032 Copyright (C) The Internet Society (1998). All Rights Reserved. 2034 This document and translations of it may be copied and furnished to others, 2035 and derivative works that comment on or otherwise explain it or assist in its 2036 implementation may be prepared, copied, published and distributed, in whole 2037 or in part, without restriction of any kind, provided that the above 2038 copyright notice and this paragraph are included on all such copies and 2039 derivative works. However, this document itself may not be modified in any 2040 way, such as by removing the copyright notice or references to the Internet 2041 Society or other Internet organizations, except as needed for the purpose of 2042 developing Internet standards in which case the procedures for copyrights 2043 defined in the Internet Standards process must be followed, or as required to 2044 translate it into languages other than English. 2046 The limited permissions granted above are perpetual and will not be revoked 2047 by the Internet Society or its successors or assigns. 2049 This document and the information contained herein is provided on an "AS IS" 2050 basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 2051 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 2052 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 2053 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 2054 PARTICULAR PURPOSE. 2056 Appendix A: Routing Protocol Piggybacking 2058 As noted above, routing protocol piggybacking could be used to carry VPN 2059 membership information alone, or also VPN reachability information. The 2060 means by which this is done, and the nature of the piggyback information, is 2061 a function both of the particular routing protocol, and of the underlying 2062 network mechanism. The particular cases of OSPF and BGP-4 are discussed 2063 below. 2065 6.2.1 OSPF 2067 OSPF is often used as an intra-AS routing protocol, and hence may be a 2068 required candidate for routing protocol piggybacking. One means by which VPN 2069 membership and reachability information could be piggybacked is through the 2070 use of the proposed OSPF opaque LSA [Coltun]. The exact details of how such 2071 a piggybacking advertisement might be coded are for further study. In 2072 particular, it may prove to be the case that opaque LSAs could be well suited 2073 for piggybacking VPN membership information, but not VPN reachability 2074 information, since opaque LSAs, at least as currently defined, are attributes 2075 of, not indexes into, reachability information. Using them in the latter 2076 manner, which would be required to piggyback VPN reachability information, 2077 may break some existing OSPF implementations. Opaque LSAs do, however, have a 2078 well defined scoping mechanism, that, at least within an AS, allows for 2079 control over the extent of dissemination of a VPN advertisement. 2081 Note also that as a link state protocol OSPF advertisements always allow for 2082 the identification of the source of an advertisement. However, each router 2083 in the OSPF network, and not only edge routers, will also need to examine 2084 received advertisements, and explicitly ignore piggybacked VPN 2085 advertisements, unless configured to be a VPN terminator (i.e. edge router). 2087 6.2.2 BGP-4 2089 There are a number of potential mechanisms by which VPN information could be 2090 piggybacked into BGP-4, including the Multiprotocol Extensions attribute 2091 [Bates] or the BGP communities attribute. In the case where VPN reachability 2092 information is piggybacked, each VPN address prefix could be encoded as 2093 Network Layer Reachability Information (NLRI) and bound to the VPN identifier 2094 as a community attribute, if the VPN ID has the format proposed previously. 2095 Note that in cases where it was desired only to advertise VPN membership 2096 information, then advertising each VPN prefix may be onerous and undesirable, 2097 but there is no specific mechanism in BGP-4, as yet, to advertise anything 2098 other than NLRI. 2100 In the case where this is done on an MPLS network, then the advertisement 2101 would carry each VPN prefix, together with the MPLS label(s) to be used to 2102 send packets to that stub link. As noted above, these labels, as a purely 2103 local matter, could identify either the route to each stub link, or only to 2104 the edge router itself, which would then use its own forwarding mechanisms 2105 for egress packets. Since there is already defined a particular mechanism 2106 for carrying MPLS labels in BGP-4 using the Multiprotocol Extensions field 2107 [Rekhter3], this would suggest that this mechanism should be generalized for 2108 the purpose also of conveying VPN information; hence it is proposed that that 2109 Draft be amended for this purpose. 2111 The use of BGP-4 for VPN piggybacking is more complex in cases where this is 2112 done on non-MPLS networks. In such a case, the piggybacked advertisements 2113 must allow for the explicit identification of the source of the 2114 advertisement. This is important for tunnel set up in non-MPLS networks, 2115 where each edge router needs to know the identity (i.e. IP address) of each 2116 of the other edge routers, in order to initiate whatever signaling mechanism 2117 may be used for tunnel set-up. 2119 At present there is no means by which the original source of a BGP 2120 advertisement can be identified once that advertisement is redistributed 2121 (e.g. from an intra-AS protocol like OSPF into BGP at a border node, or from 2122 an edge router through a border router for distribution outside the original 2123 AS). Since VPN support in non-MPLS networks is an important requirement, it 2124 is proposed that whatever BGP-4 mechanism is chosen for the purpose of VPN 2125 advertisements also be amended to allow for explicit tagging with the IP 2126 address of the original source of the advertisement. One possible means by 2127 which this could be done may be to associate the VPN ID (coded as a Community 2128 Attribute) with the /32 prefix (i.e. IP address) of the edge router 2129 supporting the VPN. This issue is for further study. 2131 Note that in the case where BGP advertisements are propagated across AS 2132 boundaries, then each border router must cache the full set of prefixes and 2133 associated label stacks of each advertised VPN. In such a case, further work 2134 is also needed to control scoping of BGP piggybacked advertisements. In 2135 particular, at AS boundaries, border routers would generally need to be 2136 manually configured with VPN route advertisement policies to determine 2137 whether such advertisements should be propagated, and, if so, to which peer 2138 ASs. In general ASs will also likely automatically reject VPN advertisements 2139 received from peer ASs unless specifically configured to pass them. Some 2140 administrative mechanism (e.g. manual procedures or some form of directory 2141 communication, for instance) would be needed for this purpose. 2143 Note also that such scoping policy configurations would be needed not only in 2144 each border router of each AS with one or more VPN termination points, but 2145 also in each AS in the transit path between them. This last may pose 2146 problems if the trust system includes the terminating ASs, but excludes one 2147 or more of the transit ASs. These problems expose a particular artifact of 2148 router piggybacking - while VPN membership and reachability information is 2149 relevant only to the particular edge routers concerned, router piggybacking 2150 necessarily requires also the active participation of all intermediate 2151 routers that need to process and propagate such advertisements. This may 2152 impose significant burdens on the operation and administration of such 2153 intermediate routers, as well as compromising the integrity of the VPNs 2154 concerned.