idnits 2.17.1 draft-gleeson-vpn-framework-03.txt: 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 60 longer pages, the longest (page 2) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 61 pages 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 12 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 2401 (ref. '5') (Obsoleted by RFC 4301) ** Downref: Normative reference to an Informational RFC: RFC 1702 (ref. '7') -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' ** Obsolete normative reference: RFC 2547 (ref. '15') (Obsoleted by RFC 4364) -- Possible downref: Non-RFC (?) normative reference: ref. '17' ** Obsolete normative reference: RFC 2409 (ref. '18') (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. '19' -- Possible downref: Non-RFC (?) normative reference: ref. '20' -- Possible downref: Non-RFC (?) normative reference: ref. '21' -- Possible downref: Non-RFC (?) normative reference: ref. '22' ** Obsolete normative reference: RFC 2406 (ref. '23') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 1723 (ref. '26') (Obsoleted by RFC 2453) ** Obsolete normative reference: RFC 2393 (ref. '28') (Obsoleted by RFC 3173) -- Possible downref: Non-RFC (?) normative reference: ref. '29' ** Obsolete normative reference: RFC 2598 (ref. '30') (Obsoleted by RFC 3246) -- Possible downref: Non-RFC (?) normative reference: ref. '31' ** Obsolete normative reference: RFC 1771 (ref. '32') (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2251 (ref. '34') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) -- Possible downref: Non-RFC (?) normative reference: ref. '35' -- Possible downref: Non-RFC (?) normative reference: ref. '36' -- Possible downref: Non-RFC (?) normative reference: ref. '38' ** Obsolete normative reference: RFC 2362 (ref. '39') (Obsoleted by RFC 4601, RFC 5059) ** Downref: Normative reference to an Experimental RFC: RFC 1075 (ref. '40') -- Possible downref: Non-RFC (?) normative reference: ref. '41' ** Downref: Normative reference to an Informational RFC: RFC 2627 (ref. '42') -- Possible downref: Non-RFC (?) normative reference: ref. '43' ** Obsolete normative reference: RFC 2138 (ref. '44') (Obsoleted by RFC 2865) ** Downref: Normative reference to an Historic RFC: RFC 2341 (ref. '45') ** Downref: Normative reference to an Informational RFC: RFC 2637 (ref. '46') -- Possible downref: Non-RFC (?) normative reference: ref. '47' -- Possible downref: Non-RFC (?) normative reference: ref. '48' -- Possible downref: Non-RFC (?) normative reference: ref. '49' -- Possible downref: Non-RFC (?) normative reference: ref. '50' ** Downref: Normative reference to an Informational RFC: RFC 2477 (ref. '51') -- Possible downref: Non-RFC (?) normative reference: ref. '52' -- Possible downref: Non-RFC (?) normative reference: ref. '55' -- Possible downref: Non-RFC (?) normative reference: ref. '56' -- Possible downref: Non-RFC (?) normative reference: ref. '57' -- Possible downref: Non-RFC (?) normative reference: ref. '58' -- Possible downref: Non-RFC (?) normative reference: ref. '59' -- Possible downref: Non-RFC (?) normative reference: ref. '60' -- Possible downref: Non-RFC (?) normative reference: ref. '61' -- Possible downref: Non-RFC (?) normative reference: ref. '62' -- Possible downref: Non-RFC (?) normative reference: ref. '63' ** Downref: Normative reference to an Informational RFC: RFC 2516 (ref. '64') -- Possible downref: Non-RFC (?) normative reference: ref. '65' Summary: 21 errors (**), 0 flaws (~~), 5 warnings (==), 38 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force B. Gleeson, A. Lin 2 INTERNET DRAFT Nortel Networks 3 Expires May 2000 J. Heinanen 4 Telia Finland 5 G. Armitage 6 Bell Labs, Lucent Technologies 7 A. Malis 8 Lucent Technologies 10 A Framework for IP Based Virtual Private Networks 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The Internet Society (1999). All Rights Reserved. 38 Abstract 40 This document describes a framework for Virtual Private Networks 41 (VPNs) running across IP backbones. It discusses the various 42 different types of VPNs, their respective requirements, and proposes 43 specific mechanisms that could be used to implement each type of VPN 44 using existing or proposed specifications. The objective of this 45 document is to serve as a framework for related protocol development 46 in order to develop the full set of specifications required for 47 widespread deployment of interoperable VPN solutions. 49 Table of Contents 51 1.0 Introduction ................................................ 4 52 2.0 VPN Application and Implementation Requirements ............. 6 53 2.1 General VPN Requirements .................................... 6 54 2.1.1 Opaque Packet Transport: ................................. 7 55 2.1.2 Data Security ............................................. 7 56 2.1.3 Quality of Service Guarantees ............................. 7 57 2.1.4 Tunneling Mechanism ....................................... 8 58 2.2 CPE and Network Based VPNs .................................. 8 59 2.3 VPNs and Extranets .......................................... 9 60 3.0 VPN Tunneling ............................................... 10 61 3.1 Tunneling Protocol Requirements for VPNs .................... 11 62 3.1.1 Multiplexing .............................................. 11 63 3.1.2 Signalling Protocol ....................................... 12 64 3.1.3 Data Security ............................................. 13 65 3.1.4 Multiprotocol Transport ................................... 14 66 3.1.5 Frame Sequencing .......................................... 15 67 3.1.6 Tunnel Maintenance ........................................ 15 68 3.1.7 Large MTUs ................................................ 16 69 3.1.8 Minimization of Tunnel Overhead ........................... 16 70 3.1.9 Flow and congestion control ............................... 17 71 3.1.10 QoS / Traffic Management ................................. 17 72 3.2 Recommendations ............................................. 18 73 4.0 VPN Types: Virtual Leased Lines ............................ 18 74 5.0 VPN Types: Virtual Private Routed Networks ................. 20 75 5.1 VPRN Characteristics ........................................ 20 76 5.1.1 Topology .................................................. 23 77 5.1.2 Addressing ................................................ 24 78 5.1.3 Forwarding ................................................ 24 79 5.1.4 Multiple concurrent VPRN connectivity ..................... 24 80 5.2 VPRN Related Work ........................................... 25 81 5.3 VPRN Generic Requirements ................................... 25 82 5.3.1 VPN Identifier ............................................ 26 83 5.3.2 VPN Membership Information Configuration .................. 27 84 5.3.2.1 Directory Lookup ........................................ 27 85 5.3.2.2 Explicit Management Configuration ....................... 28 86 5.3.2.3 Piggybacking in Routing Protocols ....................... 29 87 5.3.3 Stub Link Reachability Information ........................ 30 88 5.3.3.1 Stub Link Connectivity Scenarios ........................ 30 89 5.3.3.1.1 Dual VPRN and Internet Connectivity ................... 30 90 5.3.3.1.2 VPRN Connectivity Only ................................ 30 91 5.3.3.1.3 Multihomed Connectivity ............................... 31 92 5.3.3.1.4 Backdoor Links ........................................ 31 93 5.3.3.1 Routing Protocol Instance ............................... 31 94 5.3.3.2 Configuration ........................................... 33 95 5.3.3.3 ISP Administered Addresses .............................. 33 96 5.3.3.4 MPLS Label Distribution Protocol ........................ 33 97 5.3.4 Intra-VPN Reachability Information ........................ 34 98 5.3.4.1 Directory Lookup ........................................ 34 99 5.3.4.2 Explicit Configuration .................................. 34 100 5.3.4.3 Local Intra-VPRN Routing Instantiations ................. 34 101 5.3.4.4 Link Reachability Protocol .............................. 35 102 5.3.4.5 Piggybacking in IP Backbone Routing Protocols ........... 36 103 5.3.5 Tunneling Mechanisms ...................................... 36 104 5.4 Multihomed Stub Routers ..................................... 37 105 5.5 Multicast Support ........................................... 38 106 5.5.1 Edge Replication .......................................... 38 107 5.5.2 Native Multicast Support .................................. 39 108 5.6 Recommendations ............................................. 40 109 6.0 VPN Types: Virtual Private Dial Networks ................... 40 110 6.1 L2TP protocol characteristics ............................... 41 111 6.1.1 Multiplexing .............................................. 41 112 6.1.2 Signalling ................................................ 41 113 6.1.3 Data Security ............................................. 41 114 6.1.4 Multiprotocol Transport ................................... 42 115 6.1.5 Sequencing ................................................ 42 116 6.1.6 Tunnel Maintenance ........................................ 42 117 6.1.7 Large MTUs ................................................ 42 118 6.1.8 Tunnel Overhead ........................................... 43 119 6.1.9 Flow and Congestion Control ............................... 43 120 6.1.10 QoS / Traffic Management ................................. 43 121 6.1.11 Miscellaneous ............................................ 43 122 6.2 Compulsory Tunneling ........................................ 43 123 6.3 Voluntary Tunnels ........................................... 45 124 6.3.1 Issues with Use of L2TP for Voluntary Tunnels ............. 45 125 6.3.2 Issues with Use of IPSec for Voluntary Tunnels ............ 47 126 6.4 Networked Host Support ...................................... 48 127 6.4.1 Extension of PPP to Hosts Through L2TP .................... 49 128 6.4.2 Extension of PPP Directly to Hosts: ...................... 49 129 6.4.3 Use of IPSec .............................................. 49 130 6.5 Recommendations ............................................. 49 131 7.0 VPN Types: Virtual Private LAN Segment ..................... 50 132 7.1 VPLS Requirements ........................................... 51 133 7.1.1 Tunneling Protocols ....................................... 51 134 7.1.2 Multicast and Broadcast Support ........................... 51 135 7.1.3 VPLS Membership Configuration and Topology ................ 51 136 7.1.4 CPE Stub Node Types ....................................... 52 137 7.1.5 Stub Link Packet Encapsulation ............................ 52 138 7.1.5.1 Bridge CPE .............................................. 52 139 7.1.5.2 Router CPE .............................................. 52 140 7.1.6 CPE Addressing and Address Resolution ..................... 53 141 7.1.6.1 Bridge CPE .............................................. 53 142 7.1.6.2 Router CPE .............................................. 53 143 7.1.7 VPLS Edge Node Forwarding and Reachability Mechanisms ..... 53 144 7.1.7.1 Bridge CPE .............................................. 53 145 7.1.7.2 Router CPE .............................................. 54 146 7.2 Recommendations ............................................. 54 147 8.0 Summary of Recommendations .................................. 54 148 9.0 Security considerations ..................................... 55 149 10.0 Acknowledgements ........................................... 55 150 11.0 References ................................................. 56 151 12.0 Author Information ......................................... 60 152 13.0 Full Copyright Statement ................................... 61 154 1.0 Introduction 156 This document describes a framework for Virtual Private Networks 157 (VPNs) running across IP backbones. It discusses the various 158 different types of VPNs, their respective requirements, and proposes 159 specific mechanisms that could be used to implement each type of VPN 160 using existing or proposed specifications. The objective of this 161 document is to serve as a framework for related protocol development 162 in order to develop the full set of specifications required for 163 widespread deployment of interoperable VPN solutions. 165 There is currently significant interest in the deployment of virtual 166 private networks across IP backbone facilities. The widespread 167 deployment of VPNs has been hampered, however, by the lack of 168 interoperable implementations, which, in turn, derives from the lack 169 of general agreement on the definition and scope of VPNs and 170 confusion over the wide variety of solutions that are all described 171 by the term VPN. In the context of this document, a VPN is simply 172 defined as the 'emulation of a private Wide Area Network (WAN) 173 facility using IP facilities' (including the public Internet, or 174 private IP backbones). As such, there are as many types of VPNs as 175 there are types of WANs, hence the confusion over what exactly 176 constitutes a VPN. 178 In this document a VPN is modelled as a connectivity object. Hosts 179 may be attached to a VPN, and VPNs may be interconnected together, in 180 the same manner as hosts today attach to physical networks, and 181 physical networks are interconnected together (e.g. via bridges or 182 routers). Many aspects of networking, such as addressing, forwarding 183 mechanism, learning and advertising reachability, quality of service 184 (QoS), security, and firewalling, have common solutions across both 185 physical and virtual networks, and many issues that arise in the 186 discussion of VPNs have direct analogues with those issues as 187 implemented in physical networks. The introduction of VPNs does not 188 create the need to reinvent networking, or to introduce entirely new 189 paradigms that have no direct analogue with existing physical 190 networks. Instead it is often useful to first examine how a 191 particular issue is handled in a physical network environment, and 192 then apply the same principle to an environment which contains 193 virtual as well as physical networks, and to develop appropriate 194 extensions and enhancements when necessary. Clearly having 195 mechanisms that are common across both physical and virtual networks 196 facilitates the introduction of VPNs into existing networks, and also 197 reduces the effort needed for both standards and product development, 198 since existing solutions can be leveraged. 200 This framework document proposes a taxonomy of a specific set of VPN 201 types, showing the specific applications of each, their specific 202 requirements, and the specific types of mechanisms that may be most 203 appropriate for their implementation. The intent of this document is 204 to serve as a framework to guide a coherent discussion of the 205 specific modifications that may be needed to existing IP mechanisms 206 in order to develop a full range of interoperable VPN solutions. 208 The document first discusses the likely expectations customers have 209 of any type of VPN, and the implications of these for the ways in 210 which VPNs can be implemented. It also discusses the distinctions 211 between Customer Premises Equipment (CPE) based solutions, and 212 network based solutions. Thereafter it presents a taxonomy of the 213 various VPN types and their respective requirements. It also 214 outlines suggested approaches to their implementation, hence also 215 pointing to areas for future standardization. 217 Note also that this document only discusses implementations of VPNs 218 across IP backbones, be they private IP networks, or the public 219 Internet. The models and mechanisms described here are intended to 220 apply to both IPV4 and IPV6 backbones. This document specifically 221 does not discuss means of constructing VPNs using native mappings 222 onto switched backbones - e.g. VPNs constructed using the LAN 223 Emulation over ATM (LANE) [1] or Multiprotocol over ATM (MPOA) [2] 224 protocols operating over ATM backbones. Where IP backbones are 225 constructed using such protocols, by interconnecting routers over the 226 switched backbone, the VPNs discussed operate on top of this IP 227 network, and hence do not directly utilize the native mechanisms of 228 the underlying backbone. Native VPNs are restricted to the scope of 229 the underlying backbone, whereas IP based VPNs can extend to the 230 extent of IP reachability. Native VPN protocols are clearly outside 231 the scope of the IETF, and may be tackled by such bodies as the ATM 232 Forum. 234 2.0 VPN Application and Implementation Requirements 236 2.1 General VPN Requirements 238 There is growing interest in the use of IP VPNs as a more cost 239 effective means of building and deploying private communication 240 networks for multi-site communication than with existing approaches. 241 Existing private networks can be generally categorized into two types 242 - dedicated WANs that permanently connect together multiple sites, 243 and dial networks, that allow on-demand connections through the 244 Public Switched Telephone Network (PSTN) to one or more sites in the 245 private network. 247 WANs are typically implemented using leased lines or dedicated 248 circuits - for instance, Frame Relay or ATM connections - between the 249 multiple sites. CPE routers or switches at the various sites connect 250 these dedicated facilities together and allow for connectivity across 251 the network. Given the cost and complexity of such dedicated 252 facilities and the complexity of CPE device configuration, such 253 networks are generally not fully meshed, but instead have some form 254 of hierarchical topology. For example remote offices could be 255 connected directly to the nearest regional office, with the regional 256 offices connected together in some form of full or partial mesh. 258 Private dial networks are used to allow remote users to connect into 259 an enterprise network using PSTN or Integrated Services Digital 260 Network (ISDN) links. Typically, this is done through the deployment 261 of Network Access Servers (NASs) at one or more central sites. Users 262 dial into such NASs, which interact with Authentication, 263 Authorization, and Accounting (AAA) servers to verify the identity of 264 the user, and the set of services that the user is authorized to 265 receive. 267 In recent times, as more businesses have found the need for high 268 speed Internet connections to their private corporate networks, there 269 has been significant interest in the deployment of CPE based VPNs 270 running across the Internet. This has been driven typically by the 271 ubiquity and distance insensitive pricing of current Internet 272 services, that can result in significantly lower costs than typical 273 dedicated or leased line services. 275 The notion of using the Internet for private communications is not 276 new, and many techniques, such as controlled route leaking, have been 277 used for this purpose [3]. Only in recent times, however, have the 278 appropriate IP mechanisms needed to meet customer requirements for 279 VPNs all come together. These requirements include the following: 281 2.1.1 Opaque Packet Transport: 283 The traffic carried within a VPN may have no relation to the traffic 284 on the IP backbone, either because the traffic is multiprotocol, or 285 because the customer's IP network may use IP addressing unrelated to 286 that of the IP backbone on which the traffic is transported. In 287 particular, the customer's IP network may use non-unique, private IP 288 addressing [4]. 290 2.1.2 Data Security 292 In general customers using VPNs require some form of data security. 293 There are different trust models applicable to the use of VPNs. One 294 such model is where the customer does not trust the service provider 295 to provide any form of security, and instead implements a VPN using 296 CPE devices that implement firewall functionality and that are 297 connected together using secure tunnels. In this case the service 298 provider is used solely for IP packet transport. 300 An alternative model is where the customer trusts the service 301 provider to provide a secure managed VPN service. This is similar to 302 the trust involved when a customer utilizes a public switched Frame 303 Relay or ATM service, in that the customer trusts that packets will 304 not be misdirected, injected into the network in an unauthorized 305 manner, snooped on, modified in transit, or subjected to traffic 306 analysis by unauthorized parties. 308 With this model providing firewall functionality and secure packet 309 transport services is the responsibility of the service provider. 310 Different levels of security may be needed within the provider 311 backbone, depending on the deployment scenario used. If the VPN 312 traffic is contained within a single provider's IP backbone then 313 strong security mechanisms, such as those provided by the IP Security 314 protocol suite (IPSec) [5], may not be necessary for tunnels between 315 backbone nodes. If the VPN traffic traverses networks or equipment 316 owned by multiple administrations then strong security mechanisms may 317 be appropriate. Also a strong level of security may be applied by a 318 provider to customer traffic to address a customer perception that IP 319 networks, and particularly the Internet, are insecure. Whether or 320 not this perception is correct it is one that must be addressed by 321 the VPN implementation. 323 2.1.3 Quality of Service Guarantees 325 In addition to ensuring communication privacy, existing private 326 networking techniques, building upon physical or link layer 327 mechanisms, also offer various types of quality of service 328 guarantees. In particular, leased and dial up lines offer both 329 bandwidth and latency guarantees, while dedicated connection 330 technologies like ATM and Frame Relay have extensive mechanisms for 331 similar guarantees. As IP based VPNs become more widely deployed, 332 there will be market demand for similar guarantees, in order to 333 ensure end to end application transparency. While the ability of IP 334 based VPNs to offer such guarantees will depend greatly upon the 335 commensurate capabilities of the underlying IP backbones, a VPN 336 framework must also address the means by which VPN systems can 337 utilize such capabilities, as they evolve. 339 2.1.4 Tunneling Mechanism 341 Together, the first two of the requirements listed above imply that 342 VPNs must be implemented through some form of IP tunneling mechanism, 343 where the packet formats and/or the addressing used within the VPN 344 can be unrelated to that used to route the tunneled packets across 345 the IP backbone. Such tunnels, depending upon their form, can 346 provide some level of intrinsic data security, or this can also be 347 enhanced using other mechanisms (e.g. IPSec). 349 Furthermore, as discussed later, such tunneling mechanisms can also 350 be mapped into evolving IP traffic management mechanisms. There are 351 already defined a large number of IP tunneling mechanisms. Some of 352 these are well suited to VPN applications, as discussed in section 353 3.0. 355 2.2 CPE and Network Based VPNs 357 Most current VPN implementations are based on CPE equipment. VPN 358 capabilities are being integrated into a wide variety of CPE devices, 359 ranging from firewalls to WAN edge routers and specialized VPN 360 termination devices. Such equipment may be bought and deployed by 361 customers, or may be deployed (and often remotely managed) by service 362 providers in an outsourcing service. 364 There is also significant interest in 'network based VPNs', where the 365 operation of the VPN is outsourced to an Internet Service Provider 366 (ISP), and is implemented on network as opposed to CPE equipment. 367 There is significant interest in such solutions both by customers 368 seeking to reduce support costs and by ISPs seeking new revenue 369 sources. Supporting VPNs in the network allows the use of particular 370 mechanisms which may lead to highly efficient and cost effective VPN 371 solutions, with common equipment and operations support amortized 372 across large numbers of customers. 374 Most of the mechanisms discussed below can apply to either CPE based 375 or network based VPNs. However particular mechanisms are likely to 376 prove applicable only to the latter, since they leverage tools (e.g. 378 piggybacking on routing protocols) which are accessible only to ISPs 379 and which are unlikely to be made available to any customer, or even 380 hosted on ISP owned and operated CPE, due to the problems of 381 coordinating joint management of the CPE gear by both the ISP and the 382 customer. This document will indicate which techniques are likely to 383 apply only to network based VPNs. 385 2.3 VPNs and Extranets 387 The term 'extranet' is commonly used to refer to a scenario whereby 388 two or more companies have networked access to a limited amount of 389 each other's corporate data. For example a manufacturing company 390 might use an extranet for its suppliers to allow it to query 391 databases for the pricing and availability of components, and then to 392 order and track the status of outstanding orders. Another example is 393 joint software development, for instance, company A allows one 394 development group within company B to access its operating system 395 source code, and company B allows one development group in company A 396 to access its security software. Note that the access policies can 397 get arbitrarily complex. For example company B may internally 398 restrict access to its security software to groups in certain 399 geographic locations to comply with export control laws, for example. 401 A key feature of an extranet is thus the control of who can access 402 what data, and this is essentially a policy decision. Policy 403 decisions are typically enforced today at the interconnection points 404 between different domains, for example between a private network and 405 the Internet, or between a software test lab and the rest of the 406 company network. The enforcement may be done via a firewall, router 407 with access list functionality, application gateway, or any similar 408 device capable of applying policy to transit traffic. Policy 409 controls may be implemented within a corporate network, in addition 410 to between corporate networks. Also the interconnections between 411 networks could be a set of bilateral links, or could be a separate 412 network, perhaps maintained by an industry consortium. This separate 413 network could itself be a VPN or a physical network. 415 Introducing VPNs into a network does not require any change to this 416 model. Policy can be enforced between two VPNs, or between a VPN and 417 the Internet, in exactly the same manner as is done today without 418 VPNs. For example two VPNs could be interconnected, which each 419 administration locally imposing its own policy controls, via a 420 firewall, on all traffic that enters its VPN from the outside, 421 whether from another VPN or from the Internet. 423 This model of a VPN provides for a separation of policy from the 424 underlying mode of packet transport used. For example, a router may 425 direct voice traffic to ATM Virtual Channel Connections (VCCs) for 426 guaranteed QoS, non-local internal company traffic to secure tunnels, 427 and other traffic to a link to the Internet. In the past the secure 428 tunnels may have been frame relay circuits, now they may also be 429 secure IP tunnels or MPLS Label Switched Paths (LSPs) 431 Other models of a VPN are also possible. For example there is a 432 model whereby a set of application flows is mapped into a VPN. As 433 the policy rules imposed by a network administrator can get quite 434 complex, the number of distinct sets of application flows that are 435 used in the policy rulebase, and hence the number of VPNs, can thus 436 grow quite large, and there can be multiple overlapping VPNs. 437 However there is little to be gained by introducing such new 438 complexity into a network. Instead a VPN should be viewed as a 439 direct analogue to a physical network, as this allows the leveraging 440 of existing protocols and procedures, and the current expertise and 441 skill sets of network administrators and customers. 443 3.0 VPN Tunneling 445 As noted above in section 2.1, VPNs must be implemented using some 446 form of tunneling mechanism. This section looks at the generic 447 requirements for such VPN tunneling mechanisms. A number of 448 characteristics and aspects common to any link layer protocol are 449 taken and compared with the features offered by existing tunneling 450 protocols. This provides a basis for comparing different protocols 451 and is also useful to highlight areas where existing tunneling 452 protocols could benefit from extensions to better support their 453 operation in a VPN environment. 455 An IP tunnel connecting two VPN endpoints is a basic building block 456 from which a variety of different VPN services can be constructed. 457 An IP tunnel operates as an overlay across the IP backbone, and the 458 traffic sent through the tunnel is opaque to the underlying IP 459 backbone. In effect the IP backbone is being used as a link layer 460 technology, and the tunnel forms a point-to-point link. 462 A VPN device may terminate multiple IP tunnels and forward packets 463 between these tunnels and other network interfaces in different ways. 464 In the discussion of different types of VPNs, in later sections of 465 this document, the primary distinguishing characteristic of these 466 different types is the manner in which packets are forwarded between 467 interfaces (e.g. bridged or routed). There is a direct analogy with 468 how existing networking devices are characterized today. A two-port 469 repeater just forwards packets between its ports, and does not 470 examine the contents of the packet. A bridge forwards packets using 471 Media Access Control (MAC) layer information contained in the packet, 472 while a router forwards packets using layer 3 addressing information 473 contained in the packet. Each of these three scenarios has a direct 474 VPN analogue, as discussed later. Note that an IP tunnel is viewed 475 as just another sort of link, which can be concatenated with another 476 link, bound to a bridge forwarding table, or bound to an IP 477 forwarding table, depending on the type of VPN. 479 The following sections look at the requirements for a generic IP 480 tunneling protocol that can be used as a basic building block to 481 construct different types of VPNs. 483 3.1 Tunneling Protocol Requirements for VPNs 485 There are numerous IP tunneling mechanisms, including IP/IP [6], 486 Generic Routing Encapsulation (GRE) tunnels [7], Layer 2 Tunneling 487 Protocol (L2TP) [8], IPSec [5], and Multiprotocol Label Switching 488 (MPLS) [9]. Note that while some of these protocols are not often 489 thought of as tunneling protocols, they do each allow for opaque 490 transport of frames as packet payload across an IP network, with 491 forwarding disjoint from the address fields of the encapsulated 492 packets. 494 Note, however, that there is one significant distinction between each 495 of the IP tunneling protocols mentioned above, and MPLS. MPLS can be 496 viewed as a specific link layer for IP, insofar as MPLS specific 497 mechanisms apply only within the scope of an MPLS network, whereas IP 498 based mechanisms extend to the extent of IP reachability. As such, 499 VPN mechanisms built directly upon MPLS tunneling mechanisms cannot, 500 by definition, extend outside the scope of MPLS networks, any more so 501 than, for instance, ATM based mechanisms such as LANE can extend 502 outside of ATM networks. Note however, that an MPLS network can span 503 many different link layer technologies, and so, like an IP network, 504 its scope is not limited by the specific link layers used. A number 505 of proposals for defining a set of mechanisms to allow for 506 interoperable VPNs specifically over MPLS networks have also been 507 produced ([10] [11] [12] [13], [14] and [15]). 509 There are a number of desirable requirements for a VPN tunneling 510 mechanism, however, that are not all met by the existing tunneling 511 mechanisms. These requirements include: 513 3.1.1 Multiplexing 515 There are cases where multiple VPN tunnels may be needed between the 516 same two IP endpoints. This may be needed, for instance, in cases 517 where the VPNs are network based, and each end point supports 518 multiple customers. Traffic for different customers travels over 519 separate tunnels between the same two physical devices. A 520 multiplexing field is needed to distinguish which packets belong to 521 which tunnel. Sharing a tunnel in this manner may also reduce the 522 latency and processing burden of tunnel set up. Of the existing IP 523 tunneling mechanisms, L2TP (via the tunnel-id and session-id fields), 524 MPLS (via the label) and IPSec (via the Security Parameter Index 525 (SPI) field) have a multiplexing mechanism. Strictly speaking GRE 526 does not have a multiplexing field. However the key field, which was 527 intended to be used for authenticating the source of a packet, has 528 sometimes been used as a multiplexing field. IP/IP does not have a 529 multiplexing field. 531 The IETF [16] and the ATM Forum [17] have standardized on a single 532 format for a globally unique identifier used to identify a VPN (a 533 VPN-ID). A VPN-ID can be used in the control plane, to bind a tunnel 534 to a VPN at tunnel establishment time, or in the data plane, to 535 identify the VPN associated with a packet, on a per-packet basis. In 536 the data plane a VPN encapsulation header can be used by MPLS, MPOA 537 and other tunneling mechanisms to aggregate packets for different 538 VPNs over a single tunnel. In this case an explicit indication of 539 VPN-ID is included with every packet, and no use is made of any 540 tunnel specific multiplexing field. In the control plane a VPN-ID 541 field can be included in any tunnel establishment signalling protocol 542 to allow for the association of a tunnel (e.g. as identified by the 543 SPI field) with a VPN. In this case there is no need for a VPN-ID to 544 be included with every data packet. This is discussed further in 545 section 5.3.1. 547 3.1.2 Signalling Protocol 549 There is some configuration information that must be known by an end 550 point in advance of tunnel establishment, such as the IP address of 551 the remote end point, and any relevant tunnel attributes required, 552 such as the level of security needed. Once this information is 553 available, the actual tunnel establishment can be completed in one of 554 two ways - via a management operation, or via a signalling protocol 555 that allows tunnels to be established dynamically. 557 An example of a management operation would be to use an SNMP 558 Management Information Base (MIB) to configure various tunneling 559 parameters, e.g. MPLS labels, source addresses to use for IP/IP or 560 GRE tunnels, L2TP tunnel-ids and session-ids, or security association 561 parameters for IPSec. 563 Using a signalling protocol can significantly reduce the management 564 burden however, and as such, is essential in many deployment 565 scenarios. It reduces the amount of configuration needed, and also 566 reduces the management co-ordination needed if a VPN spans multiple 567 administrative domains. For example, the value of the multiplexing 568 field, described above, is local to the node assigning the value, and 569 can be kept local if distributed via a signalling protocol, rather 570 than being first configured into a management station and then 571 distributed to the relevant nodes. A signalling protocol also allows 572 nodes that are mobile or are only intermittently connected to 573 establish tunnels on demand. 575 When used in a VPN environment a signalling protocol should allow for 576 the transport of a VPN-ID to allow the resulting tunnel to be 577 associated with a particular VPN. It should also allow tunnel 578 attributes to be exchanged or negotiated, for example the use of 579 frame sequencing or the use of multiprotocol transport. Note that 580 the role of the signalling protocol need only be to negotiate tunnel 581 attributes, not to carry information about how the tunnel is used, 582 for example whether the frames carried in the tunnel are to be 583 forwarded at layer 2 or layer 3. (This is similar to Q.2931 ATM 584 signalling - the same signalling protocol is used to set up Classical 585 IP logical subnetworks as well as for LANE emulated LANs. 587 Of the various IP tunneling protocols, the following ones support a 588 signalling protocol that could be adapted for this purpose: L2TP (the 589 L2TP control protocol), IPSec (the Internet Key Exchange (IKE) 590 protocol [18]), and GRE (as used with mobile-ip tunneling [19]). Also 591 there are two MPLS signalling protocols that can be used to establish 592 LSP tunnels. One uses extensions to the MPLS Label Distribution 593 Protocol (LDP) protocol [20], called Constraint-Based Routing LDP 594 (CR-LDP) [21], and the other uses extensions to the Resource 595 Reservation Protocol (RSVP) for LSP tunnels [22]. 597 3.1.3 Data Security 599 A VPN tunneling protocol must support mechanisms to allow for 600 whatever level of security may be desired by customers, including 601 authentication and/or encryption of various strengths. None of the 602 tunneling mechanisms discussed, other than IPSec, have intrinsic 603 security mechanisms, but rely upon the security characteristics of 604 the underlying IP backbone. In particular, MPLS relies upon the 605 explicit labeling of label switched paths to ensure that packets 606 cannot be misdirected, while the other tunneling mechanisms can all 607 be secured through the use of IPSec. For VPNs implemented over non- 608 IP backbones (e.g. MPOA, Frame Relay or ATM virtual circuits), data 609 security is implicitly provided by the layer two switch 610 infrastructure. 612 Overall VPN security is not just a capability of the tunnels alone, 613 but has to be viewed in the broader context of how packets are 614 forwarded onto those tunnels. For example with VPRNs implemented 615 with virtual routers, the use of separate routing and forwarding 616 table instances ensures the isolation of traffic between VPNs. 617 Packets on one VPN cannot be misrouted to a tunnel on a second VPN 618 since those tunnels are not visible to the forwarding table of the 619 first VPN. 621 If some form of signalling mechanism is used by one VPN end point to 622 dynamically establish a tunnel with another endpoint, then there is a 623 requirement to be able to authenticate the party attempting the 624 tunnel establishment. IPSec has an array of schemes for this 625 purpose, allowing, for example, authentication to be based on pre- 626 shared keys, or to use digital signatures and certificates. Other 627 tunneling schemes have weaker forms of authentication. In some cases 628 no authentication may be needed, for example if the tunnels are 629 provisioned, rather than dynamically established, or if the trust 630 model in use does not require it. 632 Currently the IPSec Encapsulating Security Payload (ESP) protocol 633 [23] can be used to establish SAs that support either encryption or 634 authentication or both. However the protocol specification precludes 635 the use of an SA where neither encryption or authentication is used. 636 In a VPN environment this "null/null" option is useful, since other 637 aspects of the protocol (e.g. that it supports tunneling and 638 multiplexing) may be all that is required. In effect the "null/null" 639 option can be viewed as just another level of data security. 641 3.1.4 Multiprotocol Transport 643 In many applications of VPNs, the VPN may carry opaque, multiprotocol 644 traffic. As such, the tunneling protocol used must also support 645 multiprotocol transport. L2TP is designed to transport Point-to- 646 Point Protocol (PPP) [24] packets, and thus can be used to carry 647 multiprotocol traffic since PPP itself is multiprotocol. GRE also 648 provides for the identification of the protocol being tunneled. 649 IP/IP and IPSec tunnels have no such protocol identification field, 650 since the traffic being tunneled is assumed to be IP. 652 It is possible to extend the IPSec protocol suite to allow for the 653 transport of multiprotocol packets. This can be achieved, for 654 example, by extending the signalling component of IPSec - IKE, to 655 indicate the protocol type of the traffic being tunneled, or to carry 656 a packet multiplexing header (e.g. an LLC/SNAP header or GRE header) 657 with each tunneled packet. This approach is similar to that used for 658 the same purpose in ATM networks, where signalling is used to 659 indicate the encapsulation used on the VCC, and where packets sent on 660 the VCC can use either an LLC/SNAP header or be placed directly into 661 the AAL5 payload, the latter being known as VC-multiplexing (see 662 [25]). 664 3.1.5 Frame Sequencing 666 One quality of service attribute required by customers of a VPN may 667 be frame sequencing, matching the equivalent characteristic of 668 physical leased lines or dedicated connections. Sequencing may be 669 required for the efficient operation of particular end to end 670 protocols or applications. In order to implement frame sequencing, 671 the tunneling mechanism must support a sequencing field. Both L2TP 672 and GRE have such a field. IPSec has a sequence number field, but it 673 is used by a receiver to perform an anti-replay check, not to 674 guarantee in-order delivery of packets. 676 It is possible to extend IPSec to allow the use of the existing 677 sequence field to guarantee in-order delivery of packets. This can 678 be achieved, for example, by using IKE to negotiate whether or not 679 sequencing is to be used, and to define an end point behaviour which 680 preserves packet sequencing. 682 3.1.6 Tunnel Maintenance 684 The VPN end points must monitor the operation of the VPN tunnels to 685 ensure that connectivity has not been lost, and to take appropriate 686 action (such as route recalculation) if there has been a failure. 688 There are two approaches possible. One is for the tunneling protocol 689 itself to periodically check in-band for loss of connectivity, and to 690 provide an explicit indication of failure. For example L2TP has an 691 optional keep-alive mechanism to detect non-operational tunnels. 693 The other approach does not require the tunneling protocol itself to 694 perform this function, but relies on the operation of some out-of- 695 band mechanism to determine loss of connectivity. For example if a 696 routing protocol such as Routing Information Protocol (RIP) [26] or 697 Open Shortest Path First (OSPF) [27] is run over a tunnel mesh, a 698 failure to hear from a neighbour within a certain period of time will 699 result in the routing protocol declaring the tunnel to be down. 700 Another out-of-band approach is to perform regular ICMP pings with a 701 peer. This is generally sufficient assurance that the tunnel is 702 operational, due to the fact the tunnel also runs across the same IP 703 backbone. 705 When tunnels are established dynamically a distinction needs to be 706 drawn between the static and dynamic tunnel information needed. 707 Before a tunnel can be established some static information is needed 708 by a node, such as the identify of the remote end point and the 709 attributes of the tunnel to propose and accept. This is typically 710 put in place as a result of a configuration operation. As a result 711 of the signalling exchange to establish a tunnel, some dynamic state 712 is established in each end point, such as the value of the 713 multiplexing field or keys to be used. For example with IPSec, the 714 establishment of a Security Association (SA) puts in place the keys 715 to be used for the lifetime of that SA. 717 Different policies may be used as to when to trigger the 718 establishment of a dynamic tunnel. One approach is to use a data- 719 driven approach and to trigger tunnel establishment whenever there is 720 data to be transferred, and to timeout the tunnel due to inactivity. 721 This approach is particularly useful if resources for the tunnel are 722 being allocated in the network for QoS purposes. Another approach is 723 to trigger tunnel establishment whenever the static tunnel 724 configuration information is installed, and to attempt to keep the 725 tunnel up all the time. 727 3.1.7 Large MTUs 729 An IP tunnel has an associated Maximum Transmission Unit (MTU), just 730 like a regular link. It is conceivable that this MTU may be larger 731 than the MTU of one or more individual hops along the path between 732 tunnel endpoints. If so, some form of frame fragmentation will be 733 required within the tunnel. 735 If the frame to be transferred is mapped into one IP datagram, normal 736 IP fragmentation will occur when the IP datagram reaches a hop with 737 an MTU smaller than the IP tunnel's MTU. This can have undesirable 738 performance implications at the router performing such mid-tunnel 739 fragmentation. 741 An alternative approach is for the tunneling protocol itself to 742 incorporate a segmentation and reassembly capability that operates at 743 the tunnel level, perhaps using the tunnel sequence number and an 744 end-of-message marker of some sort. (Note that multilink PPP uses a 745 mechanism similar to this to fragment packets). This avoids IP level 746 fragmentation within the tunnel itself. None of the existing 747 tunneling protocols support such a mechanism. 749 3.1.8 Minimization of Tunnel Overhead 751 There is clearly benefit in minimizing the overhead of any tunneling 752 mechanisms. This is particularly important for the transport of 753 jitter and latency sensitive traffic such as packetized voice and 754 video. On the other hand, the use of security mechanisms, such as 755 IPSec, do impose their own overhead, hence the objective should be to 756 minimize overhead over and above that needed for security, and to not 757 burden those tunnels in which security is not mandatory with 758 unnecessary overhead. 760 One area where the amount of overhead may be significant is when 761 voluntary tunneling is used for dial-up remote clients connecting to 762 a VPN, due to the typically low bandwidth of dial-up links. This is 763 discussed further in section 6.3. 765 3.1.9 Flow and congestion control 767 During the development of the L2TP protocol procedures were developed 768 for flow and congestion control. These were necessitated primarily 769 because of the need to provide adequate performance over lossy 770 networks when PPP compression is used, which, unlike IP Payload 771 Compression Protocol (IPComp) [28], is stateful across packets. 772 Another motivation was to accommodate devices with very little 773 buffering, used for example to terminate low speed dial-up lines. 774 However the flow and congestion control mechanisms defined in the 775 final version of the L2TP specification are used only for the control 776 channels, and not for data traffic. 778 In general the interactions between multiple layers of flow and 779 congestion control schemes can be very complex. Given the 780 predominance of TCP traffic in today's networks and the fact that TCP 781 has its own end-to-end flow and congestion control mechanisms, it is 782 not clear that there is much benefit to implementing similar 783 mechanisms within tunneling protocols. Good flow and congestion 784 control schemes, that can adapt to a wide variety of network 785 conditions and deployment scenarios are complex to develop and test, 786 both in themselves and in understanding the interaction with other 787 schemes that may be running in parallel. There may be some benefit, 788 however, in having the capability whereby a sender can shape traffic 789 to the capacity of a receiver in some manner, and in providing the 790 protocol mechanisms to allow a receiver to signal its capabilities to 791 a sender. This is an area that may benefit from further study. 793 Note also the work of the Performance Implications of Link 794 Characteristics (PILC) working group of the IETF, which is examining 795 how the properties of different network links can have an impact on 796 the performance of Internet protocols operating over those links. 798 3.1.10 QoS / Traffic Management 800 As noted above, customers may require that VPNs yield similar 801 behaviour to physical leased lines or dedicated connections with 802 respect to such QoS parameters as loss rates, jitter, latency and 803 bandwidth guarantees. How such guarantees could be delivered will, 804 in general, be a function of the traffic management characteristics 805 of the VPN nodes themselves, and the access and backbone networks 806 across which they are connected. 808 A full discussion of QoS and VPNs is outside the scope of this 809 document, however by modelling a VPN tunnel as just another type of 810 link layer, many of the existing mechanisms developed for ensuring 811 QoS over physical links can also be applied. For example at a VPN 812 node, the mechanisms of policing, marking, queuing, shaping and 813 scheduling can all be applied to VPN traffic with VPN-specific 814 parameters, queues and interfaces, just as for non-VPN traffic. The 815 techniques developed for Diffserv, Intserv and for traffic 816 engineering in MPLS are also applicable. See also [29] for a 817 discussion of QoS and VPNs. 819 It should be noted, however, that this model of tunnel operation is 820 not necessarily consistent with the way in which specific tunneling 821 protocols are currently modelled. While a model is an aid to 822 comprehension, and not part of a protocol specification, having 823 differing models can complicate discussions, particularly if a model 824 is misinterpreted as being part of a protocol specification or as 825 constraining choice of implementation method. For example, IPSec 826 tunnel processing can be modelled both as an interface and as an 827 attribute of a particular packet flow. 829 3.2 Recommendations 831 IPSec is needed whenever there is a requirement for strong encryption 832 or strong authentication. It also supports multiplexing and a 833 signalling protocol - IKE. However extending the IPSec protocol 834 suite to also cover the following areas would be beneficial, in order 835 to better support the tunneling requirements of a VPN environment. 837 - the transport of a VPN-ID when establishing an SA (3.1.2) 839 - a null encryption and null authentication option (3.1.3) 841 - multiprotocol operation (3.1.4) 843 - frame sequencing (3.1.5) 845 L2TP provides no data security by itself, and any PPP security 846 mechanisms used do not apply to the L2TP protocol itself, so that in 847 order for strong security to be provided L2TP must run over IPSec. 848 Defining specific modes of operation for IPSec when it is used to 849 support L2TP traffic will aid interoperability. This is currently a 850 work item for the proposed L2TP working group. 852 4.0 VPN Types: Virtual Leased Lines 854 The simplest form of a VPN is a 'Virtual Leased Line' (VLL) service. 855 In this case a point-to-point link is provided to a customer, 856 connecting two CPE devices, as illustrated below. The link layer 857 type used to connect the CPE devices to the ISP nodes can be any link 858 layer type, for example an ATM VCC or a Frame Relay circuit. The CPE 859 devices can be either routers bridges or hosts. 861 The two ISP nodes are both connected to an IP network, and an IP 862 tunnel is set up between them. Each ISP node is configured to bind 863 the stub link and the IP tunnel together at layer 2 (e.g. an ATM VCC 864 and the IP tunnel). Frames are relayed between the two links. For 865 example the ATM Adaptation Layer 5 (AAL5) payload is taken and 866 encapsulated in an IPSec tunnel, and vice versa. The contents of the 867 AAL5 payload are opaque to the ISP node, and are not examined there. 869 +--------+ ----------- +--------+ 870 +---+ | ISP | ( IP ) | ISP | +---+ 871 |CPE|-------| edge |-----( backbone ) -----| edge |------|CPE| 872 +---+ ATM | node | ( ) | node | ATM +---+ 873 VCC +--------+ ----------- +--------+ VCC 875 <--------- IP Tunnel --------> 877 10.1.1.5 subnet = 10.1.1.4/30 10.1.1.6 878 Addressing used by customer (transparent to provider) 880 Figure 4.1: VLL Example 882 To a customer it looks the same as if a single ATM VCC or Frame Relay 883 circuit were used to interconnect the CPE devices, and the customer 884 could be unaware that part of the circuit was in fact implemented 885 over an IP backbone. This may be useful, for example, if a provider 886 wishes to provide a LAN interconnect service using ATM as the network 887 interface, but does not have an ATM network that directly 888 interconnects all possible customer sites. 890 It is not necessary that the two links used to connect the CPE 891 devices to the ISP nodes be of the same media type, but in this case 892 the ISP nodes cannot treat the traffic in an opaque manner, as 893 described above. Instead the ISP nodes must perform the functions of 894 an interworking device between the two media types (e.g. ATM and 895 Frame Relay), and perform functions such as LLC/SNAP to NLPID 896 conversion, mapping between ARP protocol variants and performing any 897 media specific processing that may be expected by the CPE devices 898 (e.g. ATM OAM cell handling or Frame Relay XID exchanges). 900 The IP tunneling protocol used must support multiprotocol operation 901 and may need to support sequencing, if that characteristic is 902 important to the customer traffic. If the tunnels are established 903 using a signalling protocol, they may be set up in a data driven 904 manner, when a frame is received from a customer link and no tunnel 905 exists, or the tunnels may be established at provisioning time and 906 kept up permanently. 908 Note that the use of the term 'VLL' in this document is different to 909 that used in the definition of the Diffserv Expedited Forwarding Per 910 Hop Behaviour (EF-PHB) [30]. In that document a VLL is used to mean 911 a low latency, low jitter, assured bandwidth path, which can be 912 provided using the described PHB. Thus the focus there is primarily 913 on link characteristics that are temporal in nature. In this document 914 the term VLL does not imply the use of any specific QoS mechanism, 915 Diffserv or otherwise. Instead the focus is primarily on link 916 characteristics that are more topological in nature, (e.g. such as 917 constructing a link which includes an IP tunnel as one segment of the 918 link). For a truly complete emulation of a link layer both the 919 temporal and topological aspects need to be taken into account. 921 5.0 VPN Types: Virtual Private Routed Networks 923 5.1 VPRN Characteristics 925 A Virtual Private Routed Network (VPRN) is defined to be the 926 emulation of a multi-site wide area routed network using IP 927 facilities. This section looks at how a network-based VPRN service 928 can be provided. CPE-based VPRNs are also possible, but are not 929 specifically discussed here. With network-based VPRNs many of the 930 issues that need to be addressed are concerned with configuration and 931 operational issues, which must take into account the split in 932 administrative responsibility between the service provider and the 933 service user. 935 The distinguishing characteristic of a VPRN, in comparison to other 936 types of VPNs, is that packet forwarding is carried out at the 937 network layer. A VPRN consists of a mesh of IP tunnels between ISP 938 routers, together with the routing capabilities needed to forward 939 traffic received at each VPRN node to the appropriate destination 940 site. Attached to the ISP routers are CPE routers connected via one 941 or more links, termed 'stub' links. There is a VPRN specific 942 forwarding table at each ISP router to which members of the VPRN are 943 connected. Traffic is forwarded between ISP routers, and between ISP 944 routers and customer sites, using these forwarding tables, which 945 contain network layer reachability information (in contrast to a 946 Virtual Private LAN Segment type of VPN (VPLS) where the forwarding 947 tables contain MAC layer reachability information - see section 7.0). 949 An example VPRN is illustrated in the following diagram, which shows 950 3 ISP edge routers connected via a full mesh of IP tunnels, used to 951 interconnect 4 CPE routers. One of the CPE routers is multihomed to 952 the ISP network. In the multihomed case, all stub links may be 953 active, or, as shown, there may be one primary and one or more backup 954 links to be used in case of failure of the primary. The term 955 'backdoor' link is used to refer to a link between two customer sites 956 that does not traverse the ISP network. 958 10.1.1.0/30 +--------+ +--------+ 10.2.2.0/30 959 +---+ | ISP | IP tunnel | ISP | +---+ 960 |CPE|-------| edge |<--------------------->| edge |-------|CPE| 961 +---+ stub | router | 10.9.9.4/30 | router | stub +---+ 962 link +--------+ +--------+ link : 963 | ^ | | ^ : 964 | | | --------------- | | : 965 | | +----( )----+ | : 966 | | ( IP BACKBONE ) | : 967 | | ( ) | : 968 | | --------------- | : 969 | | | | : 970 | |IP tunnel +--------+ IP tunnel| : 971 | | | ISP | | : 972 | +---------->| edge |<----------+ : 973 | 10.9.9.8/30 | router | 10.9.9.12/30 : 974 backup| +--------+ backdoor: 975 link | | | link : 976 | stub link | | stub link : 977 | | | : 978 | +---+ +---+ : 979 +-------------|CPE| |CPE|.......................: 980 10.3.3.0/30 +---+ +---+ 10.4.4.0/30 982 Figure 5.1: VPRN Example 984 The principal benefit of a VPRN is that the complexity and the 985 configuration of the CPE routers is minimized. To a CPE router, the 986 ISP edge router appears as a neighbour router in the customer's 987 network, to which it sends all traffic, using a default route. The 988 tunnel mesh that is set up to transfer traffic extends between the 989 ISP edge routers, not the CPE routers. In effect the burden of 990 tunnel establishment and maintenance and routing configuration is 991 outsourced to the ISP. In addition other services needed for the 992 operation of a VPN such as the provision of a firewall and QoS 993 processing can be handled by a small number of ISP edge routers, 994 rather than a large number of potentially heterogeneous CPE devices. 995 The introduction and management of new services can also be more 996 easily handled, as this can be achieved without the need to upgrade 997 any CPE equipment. This latter benefit is particularly important 998 when there may be large numbers of residential subscribers using VPN 999 services to access private corporate networks. In this respect the 1000 model is somewhat akin to that used for telephony services, whereby 1001 new services (e.g. call waiting) can be introduced with no change in 1002 subscriber equipment. 1004 The VPRN type of VPN is in contrast to one where the tunnel mesh 1005 extends to the CPE routers, and where the ISP network provides layer 1006 2 connectivity alone. The latter case can be implemented either as a 1007 set of VLLs between CPE routers (see section 4.0), in which case the 1008 ISP network provides a set of layer 2 point-to-point links, or as a 1009 VPLS (see section 7.0), in which case the ISP network is used to 1010 emulate a multiaccess LAN segment. With these scenarios a customer 1011 may have more flexibility (e.g. any IGP or any protocol can be run 1012 across all customer sites) but this usually comes at the expense of a 1013 more complex configuration for the customer. Thus, depending on 1014 customer requirements, a VPRN or a VPLS may be the more appropriate 1015 solution. 1017 Because a VPRN carries out forwarding at the network layer, a single 1018 VPRN only directly supports a single network layer protocol. For 1019 multiprotocol support, a separate VPRN for each network layer 1020 protocol could be used, or one protocol could be tunneled over 1021 another (e.g. non-IP protocols tunneled over an IP VPRN) or 1022 alternatively the ISP network could be used to provide layer 2 1023 connectivity only, such as with a VPLS as mentioned above. 1025 The issues to be addressed for VPRNs include initial configuration, 1026 determination by an ISP edge router of the set of links that are in 1027 each VPRN, the set of other routers that have members in the VPRN, 1028 and the set of IP address prefixes reachable via each stub link, 1029 determination by a CPE router of the set of IP address prefixes to be 1030 forwarded to an ISP edge router, the mechanism used to disseminate 1031 stub reachability information to the correct set of ISP routers, and 1032 the establishment and use of the tunnels used to carry the data 1033 traffic. Note also that, although discussed first for VPRNs, many of 1034 these issues also apply to the VPLS scenario described later, with 1035 the network layer addresses being replaced by link layer addresses. 1037 Note that VPRN operation is decoupled from the mechanisms used by the 1038 customer sites to access the Internet. A typical scenario would be 1039 for the ISP edge router to be used to provide both VPRN and Internet 1040 connectivity to a customer site. In this case the CPE router just 1041 has a default route pointing to the ISP edge router, with the latter 1042 being responsible for steering private traffic to the VPRN and other 1043 traffic to the Internet, and providing firewall functionality between 1044 the two domains. Alternatively a customer site could have Internet 1045 connectivity via an ISP router not involved in the VPRN, or even via 1046 a different ISP. In this case the CPE device is responsible for 1047 splitting the traffic into the two domains and providing firewall 1048 functionality. 1050 5.1.1 Topology 1052 The topology of a VPRN may consist of a full mesh of tunnels between 1053 each VPRN node, or may be an arbitrary topology, such as a set of 1054 remote offices connected to the nearest regional site, with these 1055 regional sites connected together via a full or partial mesh. With 1056 VPRNs using IP tunnels there is much less cost assumed with full 1057 meshing than in cases where physical resources (e.g. a leased line) 1058 must be allocated for each connected pair of sites, or where the 1059 tunneling method requires resources to be allocated in the devices 1060 used to interconnect the edge routers (e.g Frame Relay DLCIs). A 1061 full mesh topology yields optimal routing, since it precludes the 1062 need for traffic between two sites to traverse a third. Another 1063 attraction of a full mesh is that there is no need to configure 1064 topology information for the VPRN. Instead, given the member routers 1065 of a VPRN, the topology is implicit. If the number of ISP edge 1066 routers in a VPRN is very large, however, a full mesh topology may 1067 not be appropriate, due to the scaling issues involved, for example, 1068 the growth in the number of tunnels needed between sites, (which for 1069 n sites is n(n-1)/2), or the number of routing peers per router. 1070 Network policy may also lead to non full mesh topologies, for example 1071 an administrator may wish to set up the topology so that traffic 1072 between two remote sites passes through a central site, rather than 1073 go directly between the remote sites. It is also necessary to deal 1074 with the scenario where there is only partial connectivity across the 1075 IP backbone under certain error conditions (e.g. A can reach B, and B 1076 can reach C, but A cannot reach C directly), which can occur if 1077 policy routing is being used. 1079 For a network-based VPRN, it is assumed that each customer site CPE 1080 router connects to an ISP edge router through one or more point-to- 1081 point stub links (e.g. leased lines, ATM or Frame Relay connections). 1082 The ISP routers are responsible for learning and disseminating 1083 reachability information amongst themselves. The CPE routers must 1084 learn the set of destinations reachable via each stub link, though 1085 this may be as simple as a default route. 1087 The stub links may either be dedicated links, set up via 1088 provisioning, or may be dynamic links set up on demand, for example 1089 using PPP, voluntary tunneling (see section 6.3), or ATM signalling. 1090 With dynamic links it is necessary to authenticate the subscriber, 1091 and determine the authorized resources that the subscriber can access 1092 (e.g. which VPRNs the subscriber may join). Other than the way the 1093 subscriber is initially bound to the VPRN, (and this process may 1094 involve extra considerations such as dynamic IP address assignment), 1095 the subsequent VPRN mechanisms and services can be used for both 1096 types of subscribers in the same way. 1098 5.1.2 Addressing 1100 The addressing used within a VPRN may have no relation to the 1101 addressing used on the IP backbone over which the VPRN is 1102 instantiated. In particular non-unique private IP addressing may be 1103 used [4]. Multiple VPRNs may be instantiated over the same set of 1104 physical devices, and they may use the same or overlapping address 1105 spaces. 1107 5.1.3 Forwarding 1109 For a VPRN the tunnel mesh forms an overlay network operating over an 1110 IP backbone. Within each of the ISP edge routers there must be VPN 1111 specific forwarding state to forward packets received from stub links 1112 ('ingress traffic') to the appropriate next hop router, and to 1113 forward packets received from the core ('egress traffic') to the 1114 appropriate stub link. For cases where an ISP edge router supports 1115 multiple stub links belonging to the same VPRN, the tunnels can, as a 1116 local matter, either terminate on the edge router, or on a stub link. 1117 In the former case a VPN specific forwarding table is needed for 1118 egress traffic, in the latter case it is not. A VPN specific 1119 forwarding table is generally needed in the ingress direction, in 1120 order to direct traffic received on a stub link onto the correct IP 1121 tunnel towards the core. 1123 Also since a VPRN operates at the internetwork layer, the IP packets 1124 sent over a tunnel will have their Time to Live (TTL) field 1125 decremented in the normal manner, preventing packets circulating 1126 indefinitely in the event of a routing loop within the VPRN. 1128 5.1.4 Multiple concurrent VPRN connectivity 1130 Note also that a single customer site may belong concurrently to 1131 multiple VPRNs and may want to transmit traffic both onto one or more 1132 VPRNs and to the default Internet, over the same stub link. There 1133 are a number of possible approaches to this problem, but these are 1134 outside the scope of this document. 1136 5.2 VPRN Related Work 1138 VPRN requirements and mechanisms have been discussed previously in a 1139 number of different documents. One of the first was [10], which 1140 showed how the same VPN functionality can be implemented over both 1141 MPLS and non-MPLS networks. Some others are briefly discussed below. 1143 There are two main variants as regards the mechanisms used to provide 1144 VPRN membership and reachability functionality, - overlay and 1145 piggybacking. These are discussed in greater detail in sections 1146 5.3.2, 5.3.3 and 5.3.4 below. An example of the overlay model is 1147 described in [14], which discusses the provision of VPRN 1148 functionality by means of a separate per-VPN routing protocol 1149 instance and route and forwarding table instantiation, otherwise 1150 known as virtual routing. Each VPN routing instance is isolated from 1151 any other VPN routing instance, and from the routing used across the 1152 backbone. As a result any routing protocol (e.g. OSPF, RIP2, IS-IS) 1153 can be run with any VPRN, independently of the routing protocols used 1154 in other VPRNs, or in the backbone itself. The VPN model described 1155 in [12] is also an overlay VPRN model using virtual routing. That 1156 document is specifically geared towards the provision of VPRN 1157 functionality over MPLS backbones, and it describes how VPRN 1158 membership dissemination can be automated over an MPLS backbone, by 1159 performing VPN neighbour discovery over the base MPLS tunnel mesh. 1160 [31] extends the virtual routing model to include VPN areas, and VPN 1161 border routers which route between VPN areas. VPN areas may be 1162 defined for administrative or technical reasons, such as different 1163 underlying network infrastructures (e.g. ATM, MPLS, IP). 1165 In contrast [15] describes the provision of VPN functionality using a 1166 piggybacking approach for membership and reachability dissemination, 1167 with this information being piggybacked in Border Gateway Protocol 4 1168 (BGP) [32] packets. VPNs are constructed using BGP policies, which 1169 are used to control which sites can communicate with each other. [13] 1170 also uses BGP for piggybacking membership information, and piggybacks 1171 reachability information on the protocol used to establish MPLS LSPs 1172 (CR-LDP or extended RSVP). Unlike the other proposals, however, this 1173 proposal requires the participation on the CPE router to implement 1174 the VPN functionality. 1176 5.3 VPRN Generic Requirements 1178 There are a number of common requirements which any network-based 1179 VPRN solution must address, and there are a number of different 1180 mechanisms that can be used to meet these requirements. These 1181 generic issues are 1183 1) The use of a globally unique VPN identifier in order to be able to 1184 refer to a particular VPN. 1186 2) VPRN membership determination. An edge router must learn of the 1187 local stub links that are in each VPRN, and must learn of the set 1188 of other routers that have members in that VPRN. 1190 3) Stub link reachability information. An edge router must learn the 1191 set of addresses and address prefixes reachable via each stub 1192 link. 1194 4) Intra-VPRN reachability information. Once an edge router has 1195 determined the set of address prefixes associated with each of its 1196 stub links, then this information must be disseminated to each 1197 other edge router in the VPRN. 1199 5) Tunneling mechanism. An edge router must construct the necessary 1200 tunnels to other routers that have members in the VPRN, and must 1201 perform the encapsulation and decapsulation necessary to send and 1202 receive packets over the tunnels. 1204 5.3.1 VPN Identifier 1206 The IETF [16] and the ATM Forum [17] have standardized on a single 1207 format for a globally unique identifier used to identify a VPN - a 1208 VPN-ID. Only the format of the VPN-ID has been defined, not its 1209 semantics or usage. The aim is to allow its use for a wide variety 1210 of purposes, and to allow the same identifier to used with different 1211 technologies and mechanisms. For example a VPN-ID can be included in 1212 a MIB to identify a VPN for management purposes. A VPN-ID can be 1213 used in a control plane protocol, for example to bind a tunnel to a 1214 VPN at tunnel establishment time. All packets that traverse the 1215 tunnel are then implicitly associated with the identified VPN. A 1216 VPN-ID can be used in a data plane encapsulation, to allow for an 1217 explicit per-packet identification of the VPN associated with the 1218 packet. If a VPN is implemented using different technologies (e.g IP 1219 and ATM) in a network, the same identifier can be used to identify 1220 the VPN across the different technologies. Also if a VPN spans 1221 multiple administrative domains the same identifier can be used 1222 everywhere. 1224 Most of the VPN schemes developed (e.g. [11], [12], [13], [14]) 1225 require the use of a VPN-ID that is carried in control and/or data 1226 packets, which is used to associate the packet with a particular VPN. 1227 Although the use of a VPN-ID in this manner is very common, it is not 1228 universal. [15] describes a scheme where there is no protocol field 1229 used to identify a VPN in this manner. In this scheme the VPNs as 1230 understood by a user, are administrative constructs, built using BGP 1231 policies. There are a number of attributes associated with VPN 1232 routes, such as a route distinguisher, and origin and target "VPN", 1233 that are used by the underlying protocol mechanisms for 1234 disambiguation and scoping, and these are also used by the BGP policy 1235 mechanism in the construction of VPNs, but there is nothing 1236 corresponding with the VPN-ID as used in the other documents. 1238 Note also that [33] defines a multiprotocol encapsulation for use 1239 over ATM AAL5 that uses the standard VPN-ID format. 1241 5.3.2 VPN Membership Information Configuration and Dissemination 1243 In order to establish a VPRN, or to insert new customer sites into an 1244 established VPRN, an ISP edge router must determine which stub links 1245 are associated with which VPRN. For static links (e.g. an ATM VCC) 1246 this information must be configured into the edge router, since the 1247 edge router cannot infer such bindings by itself. An SNMP MIB 1248 allowing for bindings between local stub links and VPN identities is 1249 one solution. 1251 For subscribers that attach to the network dynamically (e.g. using 1252 PPP or voluntary tunneling) it is possible to make the association 1253 between stub link and VPRN as part of the end user authentication 1254 processing that must occur with such dynamic links. For example the 1255 VPRN to which a user is to be bound may be derived from the domain 1256 name the used as part of PPP authentication. If the user is 1257 successfully authenticated (e.g. using a Radius server), then the 1258 newly created dynamic link can be bound to the correct VPRN. Note 1259 that static configuration information is still needed, for example to 1260 maintain the list of authorized subscribers for each VPRN, but the 1261 location of this static information could be an external 1262 authentication server rather than on an ISP edge router. Whether the 1263 link was statically or dynamically created, a VPN-ID can be 1264 associated with that link to signify to which VPRN it is bound. 1266 After learning which stub links are bound to which VPRN, each edge 1267 router must learn either the identity of, or, at least, the route to, 1268 each other edge router supporting other stub links in that particular 1269 VPRN. Implicit in the latter is the notion that there exists some 1270 mechanism by which the configured edge routers can then use this edge 1271 router and/or stub link identity information to subsequently set up 1272 the appropriate tunnels between them. The problem of VPRN member 1273 dissemination between participating edge routers, can be solved in a 1274 variety of ways, discussed below. 1276 5.3.2.1 Directory Lookup 1278 The members of a particular VPRN, that is, the identity of the edge 1279 routers supporting stub links in the VPRN, and the set of static stub 1280 links bound to the VPRN per edge router, could be configured into a 1281 directory, which edge routers could query, using some defined 1282 mechanism (e.g. Lightweight Directory Access Protocol (LDAP) [34]), 1283 upon startup. 1285 Using a directory allows either a full mesh topology or an arbitrary 1286 topology to be configured. For a full mesh, the full list of member 1287 routers in a VPRN is distributed everywhere. For an arbitrary 1288 topology, different routers may receive different member lists. 1290 Using a directory allows for authorization checking prior to 1291 disseminating VPRN membership information, which may be desirable 1292 where VPRNs span multiple administrative domains. In such a case, 1293 directory to directory protocol mechanisms could also be used to 1294 propagate authorized VPRN membership information between the 1295 directory systems of the multiple administrative domains. 1297 There also needs to be some form of database synchronization 1298 mechanism (e.g. triggered or regular polling of the directory by edge 1299 routers, or active pushing of update information to the edge routers 1300 by the directory) in order for all edge routers to learn the identity 1301 of newly configured sites inserted into an active VPRN, and also to 1302 learn of sites removed from a VPRN. 1304 5.3.2.2 Explicit Management Configuration 1306 A VPRN MIB could be defined which would allow a central management 1307 system to configure each edge router with the identities of each 1308 other participating edge router and the identity of each of the 1309 static stub links bound to the VPRN. Like the use of a directory, 1310 this mechanism allows both full mesh and arbitrary topologies to be 1311 configured. Another mechanism using a centralized management system 1312 is to use a policy server and use the Common Open Policy Service 1313 (COPS) protocol [35] to distribute VPRN membership and policy 1314 information, such as the tunnel attributes to use when establishing a 1315 tunnel, as described in [36]. 1317 Note that this mechanism allows the management station to impose 1318 strict authorization control; on the other hand, it may be more 1319 difficult to configure edge routers outside the scope of the 1320 management system. The management configuration model can also be 1321 considered a subset of the directory method, in that the management 1322 directories could use MIBs to push VPRN membership information to the 1323 participating edge routers, either subsequent to, or as part of, the 1324 local stub link configuration process. 1326 5.3.2.3 Piggybacking in Routing Protocols 1328 VPRN membership information could be piggybacked into the routing 1329 protocols run by each edge router across the IP backbone, since this 1330 is an efficient means of automatically propagating information 1331 throughout the network to other participating edge routers. 1332 Specifically, each route advertisement by each edge router could 1333 include, at a minimum, the set of VPN identifiers associated with 1334 each edge router, and adequate information to allow other edge 1335 routers to determine the identity of, and/or, the route to, the 1336 particular edge router. Other edge routers would examine received 1337 route advertisements to determine if any contained information was 1338 relevant to a supported (i.e. configured) VPRN; this determination 1339 could be done by looking for a VPN identifier matching a locally 1340 configured VPN. The nature of the piggybacked information, and 1341 related issues, such as scoping, and the means by which the nodes 1342 advertising particular VPN memberships will be identified, will 1343 generally be a function both of the routing protocol and of the 1344 nature of the underlying transport. 1346 Using this method all the routers in the network will have the same 1347 view of the VPRN membership information, and so a full mesh topology 1348 is easily supported. Supporting an arbitrary topology is more 1349 difficult, however, since some form of pruning would seem to be 1350 needed. 1352 The advantage of the piggybacking scheme is that it allows for 1353 efficient information dissemination, but it does require that all 1354 nodes in the path, and not just the participating edge routers, be 1355 able to accept such modified route advertisements. A disadvantage is 1356 that significant administrative complexity may be required to 1357 configure scoping mechanisms so as to both permit and constrain the 1358 dissemination of the piggybacked advertisements, and in itself this 1359 may be quite a configuration burden, particularly if the VPRN spans 1360 multiple routing domains (e.g. different autonomous systems / ISPs). 1362 Furthermore, unless some security mechanism is used for routing 1363 updates so as to permit only all relevant edge routers to read the 1364 piggybacked advertisements, this scheme generally implies a trust 1365 model where all routers in the path must perforce be authorized to 1366 know this information. Depending upon the nature of the routing 1367 protocol, piggybacking may also require intermediate routers, 1368 particularly autonomous system (AS) border routers, to cache such 1369 advertisements and potentially also re-distribute them between 1370 multiple routing protocols. 1372 Each of the schemes described above have merit in particular 1373 situations. Note that, in practice, there will almost always be some 1374 centralized directory or management system which will maintain VPRN 1375 membership information, such as the set of edge routers that are 1376 allowed to support a certain VPRN, the bindings of static stub links 1377 to VPRNs, or authentication and authorization information for users 1378 that access the network via dynamics links. This information needs 1379 to be configured and stored in some form of database, so that the 1380 additional steps needed to facilitate the configuration of such 1381 information into edge routers, and/or, facilitate edge router access 1382 to such information, may not be excessively onerous. 1384 5.3.3 Stub Link Reachability Information 1386 There are two aspects to stub site reachability - the means by which 1387 VPRN edge routers determine the set of VPRN addresses and address 1388 prefixes reachable at each stub site, and the means by which the CPE 1389 routers learn the destinations reachable via each stub link. A 1390 number of common scenarios are outlined below. In each case the 1391 information needed by the ISP edge router is the same - the set of 1392 VPRN addresses reachable at the customer site, but the information 1393 needed by the CPE router differs. 1395 5.3.3.1 Stub Link Connectivity Scenarios 1397 5.3.3.1.1 Dual VPRN and Internet Connectivity 1399 The CPE router is connected via one link to an ISP edge router, which 1400 provides both VPRN and Internet connectivity. 1402 This is the simplest case for the CPE router, as it just needs a 1403 default route pointing to the ISP edge router. 1405 5.3.3.1.2 VPRN Connectivity Only 1407 The CPE router is connected via one link to an ISP edge router, which 1408 provides VPRN, but not Internet, connectivity. 1410 The CPE router must know the set of non-local VPRN destinations 1411 reachable via that link. This may be a single prefix, or may be a 1412 number of disjoint prefixes. The CPE router may be either statically 1413 configured with this information, or may learn it dynamically by 1414 running an instance of an Interior Gateway Protocol (IGP). For 1415 simplicity it is assumed that the IGP used for this purpose is RIP, 1416 though it could be any IGP. The ISP edge router will inject into 1417 this instance of RIP the VRPN routes which it learns by means of one 1418 of the intra-VPRN reachability mechanisms described in section 5.3.4. 1419 Note that the instance of RIP run to the CPE, and any instance of a 1420 routing protocol used to learn intra-VPRN reachability (even if also 1421 RIP) are separate, with the ISP edge router redistributing the routes 1422 from one instance to another. 1424 5.3.3.1.3 Multihomed Connectivity 1426 The CPE router is multihomed to the ISP network, which provides VPRN 1427 connectivity. 1429 In this case all the ISP edge routers could advertise the same VPRN 1430 routes to the CPE router, which then sees all VPRN prefixes equally 1431 reachable via all links. More specific route redistribution is also 1432 possible, whereby each ISP edge router advertises a different set of 1433 prefixes to the CPE router. 1435 5.3.3.1.4 Backdoor Links 1437 The CPE router is connected to the ISP network, which provides VPRN 1438 connectivity, but also has a backdoor link to another customer site 1440 In this case the ISP edge router will advertise VPRN routes as in 1441 case 2 to the CPE device. However now the same destination is 1442 reachable via both the ISP edge router and via the backdoor link. If 1443 the CPE routers connected to the backdoor link are running the 1444 customer's IGP, then the backdoor link may always be the favoured 1445 link as it will appear an an 'internal' path, whereas the destination 1446 as injected via the ISP edge router will appear as an 'external' path 1447 (to the customer's IGP). To avoid this problem, assuming that the 1448 customer wants the traffic to traverse the ISP network, then a 1449 separate instance of RIP should be run between the CPE routers at 1450 both ends of the backdoor link, in the same manner as an instance of 1451 RIP is run on a stub or backup link between a CPE router and an ISP 1452 edge router. This will then also make the backdoor link appear as an 1453 external path, and by adjusting the link costs appropriately, the ISP 1454 path can always be favoured, unless it goes down, when the backdoor 1455 link is then used. 1457 The description of the above scenarios covers what reachability 1458 information is needed by the ISP edge routers and the CPE routers, 1459 and discusses some of the mechanisms used to convey this information. 1460 The sections below look at these mechanisms in more detail. 1462 5.3.3.1 Routing Protocol Instance 1464 A routing protocol can be run between the CPE edge router and the ISP 1465 edge router to exchange reachability information. This allows an ISP 1466 edge router to learn the VPRN prefixes reachable at a customer site, 1467 and also allows a CPE router to learn the destinations reachable via 1468 the provider network. 1470 The extent of the routing domain for this protocol instance is 1471 generally just the ISP edge router and the CPE router although if the 1472 customer site is also running the same protocol as its IGP, then the 1473 domain may extend into customer site. If the customer site is 1474 running a different routing protocol then the CPE router 1475 redistributes the routes between the instance running to the ISP edge 1476 router, and the instance running into the customer site. 1478 Given the typically restricted scope of this routing instance, a 1479 simple protocol will generally suffice. RIP is likely to be the most 1480 common protocol used, though any routing protocol, such as OSPF, or 1481 BGP run in internal mode (IBGP), could also be used. 1483 Note that the instance of the stub link routing protocol is different 1484 from any instance of a routing protocol used for intra-VPRN 1485 reachability. For example, if the ISP edge router uses routing 1486 protocol piggybacking to disseminate VPRN membership and reachability 1487 information across the core, then it may redistribute suitably 1488 labeled routes from the CPE routing instance to the core routing 1489 instance. The routing protocols used for each instance are 1490 decoupled, and any suitable protocol can be used in each case. There 1491 is no requirement that the same protocol, or even the same stub link 1492 reachability information gathering mechanism, be run between each CPE 1493 router and associated ISP edge router in a particular VPRN, since 1494 this is a purely local matter. 1496 This decoupling allows ISPs to deploy a common (across all VPRNs) 1497 intra-VPRN reachability mechanism, and a common stub link 1498 reachability mechanism, with these mechanisms isolated both from each 1499 other, and from the particular IGP used in a customer network. In 1500 the first case, due to the IGP-IGP boundary implemented on the ISP 1501 edge router, the ISP can insulate the intra-VPRN reachability 1502 mechanism from misbehaving stub link protocol instances. In the 1503 second case the ISP is not required to be aware of the particular IGP 1504 running in a customer site. Other scenarios are possible, where the 1505 ISP edge routers are running a routing protocol in the same instance 1506 as the customer's IGP, but are unlikely to be practical, since it 1507 defeats the purpose of a VPRN simplifying CPE router configuration. 1508 In cases where a customer wishes to run an IGP across multiple sites, 1509 a VPLS solution is more suitable. 1511 Note that if a particular customer site concurrently belongs to 1512 multiple VPRNs (or wishes to concurrently communicate with both a 1513 VPRN and the Internet), then the ISP edge router must have some means 1514 of unambiguously mapping stub link address prefixes to particular 1515 VPRNs. A simple way is to have multiple stub links, one per VPRN. 1516 It is also possible to run multiple VPRNs over one stub link. This 1517 could be done either by ensuring (and appropriately configuring the 1518 ISP edge router to know) that particular disjoint address prefixes 1519 are mapped into separate VPRNs, or by tagging the routing 1520 advertisements from the CPE router with the appropriate VPN 1521 identifier. For example if MPLS was being used to convey stub link 1522 reachability information, different MPLS labels would be used to 1523 differentiate the disjoint prefixes assigned to particular VPRNs. In 1524 any case, some administrative procedure would be required for this 1525 coordination. 1527 5.3.3.2 Configuration 1529 The reachability information across each stub link could be manually 1530 configured, which may be appropriate if the set of addresses or 1531 prefixes is small and static. 1533 5.3.3.3 ISP Administered Addresses 1535 The set of addresses used by each stub site could be administered and 1536 allocated via the VPRN edge router, which may be appropriate for 1537 small customer sites, typically containing either a single host, or a 1538 single subnet. Address allocation can be carried out using protocols 1539 such as PPP or DHCP [37], with, for example, the edge router acting 1540 as a Radius client and retrieving the customer's IP address to use 1541 from a Radius server, or acting as a DHCP relay and examining the 1542 DHCP reply message as it is relayed to the customer site. In this 1543 manner the edge router can build up a table of stub link reachability 1544 information. Although these address assignment mechanisms are 1545 typically used to assign an address to a single host, some vendors 1546 have added extensions whereby an address prefix can be assigned, 1547 with, in some cases, the CPE device acting as a "mini-DHCP" server 1548 and assigning addresses for the hosts in the customer site. 1550 Note that with these schemes it is the responsibility of the address 1551 allocation server to ensure that each site in the VPN received a 1552 disjoint address space. Note also that an ISP would typically only 1553 use this mechanism for small stub sites, which are unlikely to have 1554 backdoor links. 1556 5.3.3.4 MPLS Label Distribution Protocol 1558 In cases where the CPE router runs MPLS, LDP can be used to convey 1559 the set of prefixes at a stub site to a VPRN edge router. Using the 1560 downstream unsolicited mode of label distribution the CPE router can 1561 distribute a label for each route in the stub site. Note however 1562 that the processing carried out by the edge router in this case is 1563 more than just the normal LDP processing, since it is learning new 1564 routes via LDP, rather than the usual case of learning labels for 1565 existing routes that it has learned via standard routing mechanisms. 1567 5.3.4 Intra-VPN Reachability Information 1569 Once an edge router has determined the set of prefixes associated 1570 with each of its stub links, then this information must be 1571 disseminated to each other edge router in the VPRN. Note also that 1572 there is an implicit requirement that the set of reachable addresses 1573 within the VPRN be locally unique that is, each VPRN stub link (not 1574 performing load sharing) maintain an address space disjoint from any 1575 other, so as to permit unambiguous routing. In practical terms, it 1576 is also generally desirable, though not required, that this address 1577 space be well partitioned i.e. specific, disjoint address prefixes 1578 per edge router, so as to preclude the need to maintain and 1579 disseminate large numbers of host routes. 1581 The problem of intra-VPN reachability information dissemination can 1582 be solved in a number of ways, some of which include the following: 1584 5.3.4.1 Directory Lookup 1586 Along with VPRN membership information, a central directory could 1587 maintain a listing of the address prefixes associated with each 1588 customer site. Such information could be obtained by the server 1589 through protocol interactions with each edge router. Note that the 1590 same directory synchronization issues discussed above in section 1591 5.3.2 also apply in this case. 1593 5.3.4.2 Explicit Configuration 1595 The address spaces associated with each edge router could be 1596 explicitly configured into each other router. This is clearly a 1597 non-scalable solution, particularly when arbitrary topologies are 1598 used, and also raises the question of how the management system 1599 learns such information in the first place. 1601 5.3.4.3 Local Intra-VPRN Routing Instantiations 1603 In this approach, each edge router runs an instance of a routing 1604 protocol (a 'virtual router') per VPRN, running across the VPRN 1605 tunnels to each peer edge router, to disseminate intra-VPRN 1606 reachability information. Both full-mesh and arbitrary VPRN 1607 topologies can be easily supported, since the routing protocol itself 1608 can run over any topology. The intra-VPRN routing advertisements 1609 could be distinguished from normal tunnel data packets either by 1610 being addressed directly to the peer edge router, or by a tunnel 1611 specific mechanism. 1613 Note that this intra-VPRN routing protocol need have no relationship 1614 either with the IGP of any customer site or with the routing 1615 protocols operated by the ISPs in the IP backbone. Depending on the 1616 size and scale of the VPRNs to be supported either a simple protocol 1617 like RIP or a more sophisticated protocol like OSPF could be used. 1618 Because the intra-VPRN routing protocol operates as an overlay over 1619 the IP backbone it is wholly transparent to any intermediate routers, 1620 and to any edge routers not within the VPRN. This also implies that 1621 such routing information can remain opaque to such routers, which may 1622 be a necessary security requirements in some cases. Also note that 1623 if the routing protocol runs directly over the same tunnels as the 1624 data traffic, then it will inherit the same level of security as that 1625 afforded the data traffic, for example strong encryption and 1626 authentication. 1628 If the tunnels over which an intra-VPRN routing protocol runs are 1629 dedicated to a specific VPN (e.g. a different multiplexing field is 1630 used for each VPN) then no changes are needed to the routing protocol 1631 itself. On the other hand if shared tunnels are used, then it is 1632 necessary to extend the routing protocol to allow a VPN-ID field to 1633 be included in routing update packets, to allow sets of prefixes to 1634 be associated with a particular VPN. 1636 5.3.4.4 Link Reachability Protocol 1638 By link reachability protocol is meant a protocol that allows two 1639 nodes, connected via a point-to-point link, to exchange reachability 1640 information. Given a full mesh topology, each edge router could run 1641 a link reachability protocol, for instance some variation of MPLS 1642 CR-LDP, across the tunnel to each peer edge router in the VPRN, 1643 carrying the VPN-ID and the reachability information of each VPRN 1644 running across the tunnel between the two edge routers. If VPRN 1645 membership information has already been distributed to an edge 1646 router, then the neighbour discovery aspects of a traditional routing 1647 protocol are not needed, as the set of neighbours is already known. 1648 TCP connections can be used to interconnect the neighbours, to 1649 provide reliability. This approach may reduce the processing burden 1650 of running routing protocol instances per VPRN, and may be of 1651 particular benefit where a shared tunnel mechanism is used to connect 1652 a set of edge routers supporting multiple VPRNs. 1654 Another approach to developing a link reachability protocol would be 1655 to base it on IBGP. The problem that needs to be solved by a link 1656 reachability protocol is very similar to that solved by IBGP - 1657 conveying address prefixes reliably between edge routers. 1659 Using a link reachability protocol it is straightforward to support a 1660 full mesh topology - each edge router conveys its own local 1661 reachability information to all other routers, but does not 1662 redistribute information received from any other router. However 1663 once an arbitrary topology needs to be supported, the link 1664 reachability protocol needs to develop into a full routing protocol, 1665 due to the need to implement mechanisms to avoid loops, and there 1666 would seem little benefit in reinventing another routing protocol to 1667 deal with this. Some reasons why partially connected meshes may be 1668 needed even in a tunneled environment are discussed in section 5.1.1. 1670 5.3.4.5 Piggybacking in IP Backbone Routing Protocols 1672 As with VPRN membership, the set of address prefixes associated with 1673 each stub interface could also be piggybacked into the routing 1674 advertisements from each edge router and propagated through the 1675 network. Other edge routers extract this information from received 1676 route advertisements in the same way as they obtain the VPRN 1677 membership information (which, in this case, is implicit in the 1678 identification of the source of each route advertisement). Note that 1679 this scheme may require, depending upon the nature of the routing 1680 protocols involved, that intermediate routers, e.g. border routers, 1681 cache intra-VPRN routing information in order to propagate it 1682 further. This also has implications for the trust model, and for the 1683 level of security possible for intra-VPRN routing information. 1685 Note that in any of the cases discussed above, an edge router has the 1686 option of disseminating its stub link prefixes in a manner so as to 1687 permit tunneling from remote edge routers directly to the egress stub 1688 links. Alternatively, it could disseminate the information so as to 1689 associate all such prefixes with the edge router, rather than with 1690 specific stub links. In this case, the edge router would need to 1691 implement a VPN specific forwarding mechanism for egress traffic, to 1692 determine the correct egress stub link. The advantage of this is 1693 that it may significantly reduce the number of distinct tunnels or 1694 tunnel label information which need to be constructed and maintained. 1695 Note that this choice is purely a local manner and is not visible to 1696 remote edge routers. 1698 5.3.5 Tunneling Mechanisms 1700 Once VPRN membership information has been disseminated, the tunnels 1701 comprising the VPRN core can be constructed. 1703 One approach to setting up the tunnel mesh is to use point-to-point 1704 IP tunnels, and the requirements and issues for such tunnels have 1705 been discussed in section 3.0. For example while tunnel 1706 establishment can be done through manual configuration, this is 1707 clearly not likely to be a scalable solution, given the O(n^2) 1708 problem of meshed links. As such, tunnel set up should use some form 1709 of signalling protocol to allow two nodes to construct a tunnel to 1710 each other knowing only each other's identity. 1712 Another approach is to use the multipoint to point 'tunnels' provided 1713 by MPLS. As noted in [38], MPLS can be considered to be a form of IP 1714 tunneling, since the labels of MPLS packets allow for routing 1715 decisions to be decoupled from the addressing information of the 1716 packets themselves. MPLS label distribution mechanisms can be used 1717 to associate specific sets of MPLS labels with particular VPRN 1718 address prefixes supported on particular egress points (i.e. stub 1719 links of edge routers) and hence allow other edge routers to 1720 explicitly label and route traffic to particular VPRN stub links. 1722 One attraction of MPLS as a tunneling mechanism is that it may 1723 require less processing within each edge router than alternative 1724 tunneling mechanisms. This is a function of the fact that data 1725 security within a MPLS network is implicit in the explicit label 1726 binding, much as with a connection oriented network, such as Frame 1727 Relay. This may hence lessen customer concerns about data security 1728 and hence require less processor intensive security mechanisms (e.g. 1729 IPSec). However there are other potential security concerns with 1730 MPLS. There is no direct support for security features such as 1731 authentication, confidentiality, and non-repudiation and the trust 1732 model for MPLS means that intermediate routers, (which may belong to 1733 different administrative domains), through which membership and 1734 prefix reachability information is conveyed, must be trusted, not 1735 just the edge routers themselves. 1737 5.4 Multihomed Stub Routers 1739 The discussion thus far has implicitly assumed that stub routers are 1740 connected to one and only one VPRN edge router. In general, this 1741 restriction should be capable of being relaxed without any change to 1742 VPRN operation, given general market interest in multihoming for 1743 reliability and other reasons. In particular, in cases where the 1744 stub router supports multiple redundant links, with only one 1745 operational at any given time, with the links connected either to the 1746 same VPRN edge router, or to two or more different VPRN edge routers, 1747 then the stub link reachability mechanisms will both discover the 1748 loss of an active link, and the activation of a backup link. In the 1749 former situation, the previously connected VPRN edge router will 1750 cease advertising reachability to the stub node, while the VPRN edge 1751 router with the now active link will begin advertising reachability, 1752 hence restoring connectivity. 1754 An alternative scenario is where the stub node supports multiple 1755 active links, using some form of load sharing algorithm. In such a 1756 case, multiple VPRN edge routers may have active paths to the stub 1757 node, and may so advertise across the VPRN. This scenario should not 1758 cause any problem with reachability across the VPRN providing that 1759 the intra-VPRN reachability mechanism can accommodate multiple paths 1760 to the same prefix, and has the appropriate mechanisms to preclude 1761 looping - for instance, distance vector metrics associated with each 1762 advertised prefix. 1764 5.5 Multicast Support 1766 Multicast and broadcast traffic can be supported across VPRNs either 1767 by edge replication or by native multicast support in the backbone. 1768 These two cases are discussed below. 1770 5.5.1 Edge Replication 1772 This is where each VPRN edge router replicates multicast traffic for 1773 transmission across each link in the VPRN. Note that this is the 1774 same operation that would be performed by CPE routers terminating 1775 actual physical links or dedicated connections. As with CPE routers, 1776 multicast routing protocols could also be run on each VPRN edge 1777 router to determine the distribution tree for multicast traffic and 1778 hence reduce unnecessary flood traffic. This could be done by 1779 running instances of standard multicast routing protocols, e.g. 1780 Protocol Independent Multicast (PIM) [39] or Distance Vector 1781 Multicast Routing Protocol (DVMRP) [40], on and between each VPRN 1782 edge router, through the VPRN tunnels, in the same way that unicast 1783 routing protocols might be run at each VPRN edge router to determine 1784 intra-VPN unicast reachability, as discussed in section 5.3.4. 1785 Alternatively, if a link reachability protocol was run across the 1786 VPRN tunnels for intra-VPRN reachability, then this could also be 1787 augmented to allow VPRN edge routers to indicate both the particular 1788 multicast groups requested for reception at each edge node, and also 1789 the multicast sources at each edge site. 1791 In either case, there would need to be some mechanism to allow for 1792 the VPRN edge routers to determine which particular multicast groups 1793 were requested at each site and which sources were present at each 1794 site. How this could be done would, in general, be a function of the 1795 capabilities of the CPE stub routers at each site. If these run 1796 multicast routing protocols, then they can interact directly with the 1797 equivalent protocols at each VPRN edge router. If the CPE device 1798 does not run a multicast routing protocol, then in the absence of 1799 Internet Group Management Protocol (IGMP) proxying [41] the customer 1800 site would be limited to a single subnet connected to the VPRN edge 1801 router via a bridging device, as the scope of an IGMP message is 1802 limited to a single subnet. However using IGMP-proxying the CPE 1803 router can engage in multicast forwarding without running a multicast 1804 routing protocol, in constrained topologies. On its interfaces into 1805 the customer site the CPE router performs the router functions of 1806 IGMP, and on its interface to the VPRN edge router it performs the 1807 host functions of IGMP. 1809 5.5.2 Native Multicast Support 1811 This is where VPRN edge routers map intra-VPRN multicast traffic onto 1812 a native IP multicast distribution mechanism across the backbone. 1813 Note that intra-VPRN multicast has the same requirements for 1814 isolation from general backbone traffic as intra-VPRN unicast 1815 traffic. Currently the only IP tunneling mechanism that has native 1816 support for multicast is MPLS. On the other hand, while MPLS 1817 supports native transport of IP multicast packets, additional 1818 mechanisms would be needed to leverage these mechanisms for the 1819 support of intra-VPRN multicast. 1821 For instance, each VPRN router could prefix multicast group addresses 1822 within each VPRN with the VPN-ID of that VPRN and then redistribute 1823 these, essentially treating this VPN-ID/intra-VPRN multicast address 1824 tuple as a normal multicast address, within the backbone multicast 1825 routing protocols, as with the case of unicast reachability, as 1826 discussed previously. The MPLS multicast label distribution 1827 mechanisms could then be used to set up the appropriate multicast 1828 LSPs to interconnect those sites within each VPRN supporting 1829 particular multicast group addresses. Note, however, that this would 1830 require each of the intermediate LSRs to not only be aware of each 1831 intra-VPRN multicast group, but also to have the capability of 1832 interpreting these modified advertisements. Alternatively, 1833 mechanisms could be defined to map intra-VPRN multicast groups into 1834 backbone multicast groups. 1836 Other IP tunneling mechanisms do not have native multicast support. 1837 It may prove feasible to extend such tunneling mechanisms by 1838 allocating IP multicast group addresses to the VPRN as a whole and 1839 hence distributing intra-VPRN multicast traffic encapsulated within 1840 backbone multicast packets. Edge VPRN routers could filter out 1841 unwanted multicast groups. Alternatively, mechanisms could also be 1842 defined to allow for allocation of backbone multicast group addresses 1843 for particular intra-VPRN multicast groups, and to then utilize 1844 these, through backbone multicast protocols, as discussed above, to 1845 limit forwarding of intra-VPRN multicast traffic only to those nodes 1846 within the group. 1848 A particular issue with the use of native multicast support is the 1849 provision of security for such multicast traffic. Unlike the case of 1850 edge replication, which inherits the security characteristics of the 1851 underlying tunnel, native multicast mechanisms will need to use some 1852 form of secure multicast mechanism. The development of architectures 1853 and solutions for secure multicast is an active research area, for 1854 example see [42] and [43]. The Secure Multicast Group (SMuG) of the 1855 IRTF has been set up to develop prototype solutions, which would then 1856 be passed to the IETF IPSec working group for standardization. 1858 However considerably more development is needed before scalable 1859 secure native multicast mechanisms can be generally deployed. 1861 5.6 Recommendations 1863 The various proposals that have been developed to support some form 1864 of VPRN functionality can be broadly classified into two groups - 1865 those that utilize the router piggybacking approach for distributing 1866 VPN membership and/or reachability information ([13],[15]) and those 1867 that use the virtual routing approach ([12],[14]). In some cases the 1868 mechanisms described rely on the characteristics of a particular 1869 infrastructure (e.g. MPLS) rather than just IP. 1871 Within the context of the virtual routing approach it may be useful 1872 to develop a membership distribution protocol based on a directory or 1873 MIB. When combined with the protocol extensions for IP tunneling 1874 protocols outlined in section 3.2, this would then provide the basis 1875 for a complete set of protocols and mechanisms that support 1876 interoperable VPRNs that span multiple administrations over an IP 1877 backbone. Note that the other major pieces of functionality needed - 1878 the learning and distribution of customer reachability information, 1879 can be performed by instances of standard routing protocols, without 1880 the need for any protocol extensions. 1882 Also for the constrained case of a full mesh topology, the usefulness 1883 of developing a link reachability protocol could be examined, however 1884 the limitations and scalability issues associated with this topology 1885 may not make it worthwhile to develop something specific for this 1886 case, as standard routing will just work. 1888 Extending routing protocols to allow a VPN-ID to carried in routing 1889 update packets could also be examined, but is not necessary if VPN 1890 specific tunnels are used. 1892 6.0 VPN Types: Virtual Private Dial Networks 1894 A Virtual Private Dial Network (VPDN) allows for a remote user to 1895 connect on demand through an ad hoc tunnel into another site. The 1896 user is connected to a public IP network via a dial-up PSTN or ISDN 1897 link, and user packets are tunneled across the public network to the 1898 desired site, giving the impression to the user of being 'directly' 1899 connected into that site. A key characteristic of such ad hoc 1900 connections is the need for user authentication as a prime 1901 requirement, since anyone could potentially attempt to gain access to 1902 such a site using a switched dial network. 1904 Today many corporate networks allow access to remote users through 1905 dial connections made through the PSTN, with users setting up PPP 1906 connections across an access network to a network access server, at 1907 which point the PPP sessions are authenticated using AAA systems 1908 running such standard protocols as Radius [44]. Given the pervasive 1909 deployment of such systems, any VPDN system must in practice allow 1910 for the near transparent re-use of such existing systems. 1912 The IETF have developed the Layer 2 Tunneling Protocol (L2TP) [8] 1913 which allows for the extension of of user PPP sessions from an L2TP 1914 Access Concentrator (LAC) to a remote L2TP Network Server (LNS). The 1915 L2TP protocol itself was based on two earlier protocols, the Layer 2 1916 Forwarding protocol (L2F) [45], and the Point-to-Point Tunneling 1917 Protocol (PPTP) [46], and this is reflected in the two quite 1918 different scenarios for which L2TP can be used - compulsory tunneling 1919 and voluntary tunneling, discussed further below in sections 6.2 and 1920 6.3. 1922 This document focuses on the use of L2TP over an IP network (using 1923 UDP), but L2TP may also be run directly over other protocols such as 1924 ATM or Frame Relay. Issues specifically related to running L2TP over 1925 non-IP networks, such as how to secure such tunnels, are not 1926 addressed here. 1928 6.1 L2TP protocol characteristics 1930 This section looks at the characteristics of the L2TP tunneling 1931 protocol using the categories outlined in section 3.0. 1933 6.1.1 Multiplexing 1935 L2TP has inherent support for the multiplexing of multiple calls from 1936 different users over a single link. Between the same two IP 1937 endpoints, there can be multiple L2TP tunnels, as identified by a 1938 tunnel-id, and multiple sessions within a tunnel, as identified by a 1939 session-id. 1941 6.1.2 Signalling 1943 This is supported via the inbuilt control connection protocol, 1944 allowing both tunnels and sessions to be established dynamically. 1946 6.1.3 Data Security 1948 By allowing for the transparent extension of PPP from the user, 1949 through the LAC to the LNS, L2TP allows for the use of whatever 1950 security mechanisms, with respect to both connection set up, and data 1951 transfer, may be used with normal PPP connections. However this does 1952 not provide security for the L2TP control protocol itself. In this 1953 case L2TP could be further secured by running it in combination with 1954 IPSec through IP backbones [47], [48], or related mechanisms on non- 1955 IP backbones [49]. 1957 The interaction of L2TP with AAA systems for user authentication and 1958 authorization is a function of the specific means by which L2TP is 1959 used, and the nature of the devices supporting the LAC and the LNS. 1960 These issues are discussed in depth in [50]. 1962 The means by which the host determines the correct LAC to connect to, 1963 and the means by which the LAC determines which users to further 1964 tunnel, and the LNS parameters associated with each user, are outside 1965 the scope of the operation of a VPDN, but may be addressed, for 1966 instance, by evolving Internet roaming specifications [51]. 1968 6.1.4 Multiprotocol Transport 1970 L2TP transports PPP packets (and only PPP packets) and thus can be 1971 used to carry multiprotocol traffic since PPP itself is 1972 multiprotocol. 1974 6.1.5 Sequencing 1976 L2TP supports sequenced delivery of packets. This is a capability 1977 that can be negotiated at session establishment, and that can be 1978 turned on and off by an LNS during a session. The sequence number 1979 field in L2TP can also be used to provide an indication of dropped 1980 packets, which is needed by various PPP compression algorithms to 1981 operate correctly. If no compression is in use, and the LNS 1982 determines that the protocols in use (as evidenced by the PPP NCP 1983 negotiations) can deal with out of sequence packets (e.g. IP), then 1984 it may disable the use of sequencing. 1986 6.1.6 Tunnel Maintenance 1988 A keepalive protocol is used by L2TP in order to allow it to 1989 distinguish between a tunnel outage and prolonged periods of tunnel 1990 inactivity. 1992 6.1.7 Large MTUs 1994 L2TP itself has no inbuilt support for a segmentation and reassembly 1995 capability, but when run over UDP/IP IP fragmentation will take place 1996 if necessary. Note that a LAC or LNS may adjust the Maximum Receive 1997 Unit (MRU) negotiated via PPP in order to preclude fragmentation, if 1998 it has knowledge of the MTU used on the path between LAC and LNS. To 1999 this end, there is a proposal to allow the use of MTU discovery for 2000 cases where the L2TP tunnel transports IP frames [52]. 2002 6.1.8 Tunnel Overhead 2004 L2TP as used over IP networks runs over UDP and must be used to carry 2005 PPP traffic. This results in a significant amount of overhead, both 2006 in the data plane with UDP, L2TP and PPP headers, and also in the 2007 control plane, with the L2TP and PPP control protocols. This is 2008 discussed further in section 6.3 2010 6.1.9 Flow and Congestion Control 2012 L2TP supports flow and congestion control mechanisms for the control 2013 protocol, but not for data traffic. See section 3.1.9 for more 2014 details. 2016 6.1.10 QoS / Traffic Management 2018 An L2TP header contains a 1-bit priority field, which can be set for 2019 packets that may need preferential treatment (e.g. keepalives) during 2020 local queuing and transmission. Also by transparently extending PPP, 2021 L2TP has inherent support for such PPP mechanisms as multi-link PPP 2022 [53] and its associated control protocols [54], which allow for 2023 bandwidth on demand to meet user requirements. 2025 In addition L2TP calls can be mapped into whatever underlying traffic 2026 management mechanisms may exist in the network, and there are 2027 proposals to allow for requests through L2TP signalling for specific 2028 differentiated services behaviors [55]. 2030 6.1.11 Miscellaneous 2032 Since L2TP is designed to transparently extend PPP, it does not 2033 attempt to supplant the normal address assignment mechanisms 2034 associated with PPP. Hence, in general terms the host initiating the 2035 PPP session will be assigned an address by the LNS using PPP 2036 procedures. This addressing may have no relation to the addressing 2037 used for communication between the LAC and LNS. The LNS will also 2038 need to support whatever forwarding mechanisms are needed to route 2039 traffic to and from the remote host. 2041 6.2 Compulsory Tunneling 2043 Compulsory tunneling refers to the scenario in which a network node - 2044 a dial or network access server, for instance - acting as a LAC, 2045 extends a PPP session across a backbone using L2TP to a remote LNS, 2046 as illustrated below. This operation is transparent to the user 2047 initiating the PPP session to the LAC. This allows for the 2048 decoupling of the location and/or ownership of the modem pools used 2049 to terminate dial calls, from the site to which users are provided 2050 access. Support for this scenario was the original intent of the L2F 2051 specification, upon which the L2TP specification was based. 2053 There are a number of different deployment scenarios possible. One 2054 example, shown in the diagram below, is where a subscriber host dials 2055 into a NAS acting as a LAC, and is tunneled across an IP network 2056 (e.g. the Internet) to a gateway acting as an LNS. The gateway 2057 provides access to a corporate network, and could either be a device 2058 in the corporate network itself, or could be an ISP edge router, in 2059 the case where a customer has outsourced the maintenance of LNS 2060 functionality to an ISP. Another scenario is where an ISP uses L2TP 2061 to provide a subscriber with access to the Internet. The subscriber 2062 host dials into a NAS acting as a LAC, and is tunneled across an 2063 access network to an ISP edge router acting as an LNS. This ISP edge 2064 router then feeds the subscriber traffic into the Internet. Yet 2065 other scenarios are where an ISP uses L2TP to provide a subscriber 2066 with access to a VPRN, or with concurrent access to both a VPRN and 2067 the Internet. 2069 A VPDN, whether using compulsory or voluntary tunneling, can be 2070 viewed as just another type of access method for subscriber traffic, 2071 and as such can be used to provide connectivity to different types of 2072 networks, e.g. a corporate network, the Internet, or a VPRN. The last 2073 scenario is also an example of how a VPN service as provided to a 2074 customer may be implemented using a combination of different types of 2075 VPN. 2077 10.0.0.1 2078 +----+ 2079 |Host|----- LAC ------------- LNS 10.0.0.0/8 2080 +----+ / +-----+ ( ) +-----+ --------- 2081 /----| NAS |---( IP Backbone )---| GW |----( Corp. ) 2082 dial +-----+ ( ) +-----+ ( Network ) 2083 connection ------------- --------- 2085 <------- L2TP Tunnel -------> 2087 <--------------------- PPP Session -------> 2089 Figure 6.1: Compulsory Tunneling Example 2091 Compulsory tunneling was originally intended for deployment on 2092 network access servers supporting wholesale dial services, allowing 2093 for remote dial access through common facilities to an enterprise 2094 site, while precluding the need for the enterprise to deploy its own 2095 dial servers. Another example of this is where an ISP outsources its 2096 own dial connectivity to an access network provider (such as a Local 2097 Exchange Carrier (LEC) in the USA) removing the need for an ISP to 2098 maintain its own dial servers and allowing the LEC to serve multiple 2099 ISPs. More recently, compulsory tunneling mechanisms have also been 2100 proposed for evolving Digital Subscriber Line (DSL) services [56], 2101 [57], which also seek to leverage the existing AAA infrastructure. 2103 Call routing for compulsory tunnels requires that some aspect of the 2104 initial PPP call set up can be used to allow the LAC to determine the 2105 identity of the LNS. As noted in [50], these aspects can include the 2106 user identity, as determined through some aspect of the access 2107 network, including calling party number, or some attribute of the 2108 called party, such as the Fully Qualified Domain Name (FQDN) of the 2109 identity claimed during PPP authentication. 2111 It is also possible to chain two L2TP tunnels together, whereby a LAC 2112 initiates a tunnel to an intermediate relay device, which acts as an 2113 LNS to this first LAC, and acts as a LAC to the final LNS. This may 2114 be needed in some cases due to administrative, organizational or 2115 regulatory issues pertaining to the split between access network 2116 provider, IP backbone provider and enterprise customer. 2118 6.3 Voluntary Tunnels 2120 Voluntary tunneling refers to the case where an individual host 2121 connects to a remote site using a tunnel originating on the host, 2122 with no involvement from intermediate network nodes, as illustrated 2123 below. The PPTP specification, parts of which have been incorporated 2124 into L2TP, was based upon a voluntary tunneling model. 2126 As with compulsory tunneling there are different deployment scenarios 2127 possible. The diagram below shows a subscriber host accessing a 2128 corporate network with either L2TP or IPSec being used as the 2129 voluntary tunneling mechanism. Another scenario is where voluntary 2130 tunneling is used to provide a subscriber with access to a VPRN. 2132 6.3.1 Issues with Use of L2TP for Voluntary Tunnels 2134 The L2TP specification has support for voluntary tunneling, insofar 2135 as the LAC can be located on a host, not only on a network node. 2136 Note that such a host has two IP addresses - one for the LAC-LNS IP 2137 tunnel, and another, typically allocated via PPP, for the network to 2138 which the host is connecting. The benefits of using L2TP for 2139 voluntary tunneling are that the existing authentication and address 2140 assignment mechanisms used by PPP can be reused without modification. 2141 For example an LNS could also include a Radius client, and 2142 10.0.0.1 2143 +----+ 2144 |Host|----- ------------- 10.0.0.0/8 2145 +----+ / +-----+ ( ) +-----+ --------- 2146 /----| NAS |---( IP Backbone )---| GW |----( Corp. ) 2147 dial +-----+ ( ) +-----+ ( Network ) 2148 connection ------------- --------- 2150 <-------------- L2TP Tunnel --------------> 2151 with LAC on host 2152 <-------------- PPP Session --------------> LNS on gateway 2154 or 2156 <-------------- IPSEC Tunnel --------------> 2158 Figure 6.2: Voluntary Tunneling Example 2160 communicate with a Radius server to authenticate a PPP PAP or CHAP 2161 exchange, and to retrieve configuration information for the host such 2162 as its IP address and a list of DNS servers to use. This information 2163 can then be passed to the host via the PPP IPCP protocol. 2165 The above procedure is not without its costs, however. There is 2166 considerable overhead with such a protocol stack, particularly when 2167 IPSec is also needed for security purposes, and given that the host 2168 may be connected via a low-bandwidth dial up link. The overhead 2169 consists of both extra headers in the data plane and extra control 2170 protocols needed in the control plane. Using L2TP for voluntary 2171 tunneling, secured with IPSec, means a web application, for example, 2172 would run over the following stack 2174 HTTP/TCP/IP/PPP/L2TP/UDP/ESP/IP/PPP/AHDLC 2176 It is proposed in [58] that IPSec alone be used for voluntary tunnels 2177 reducing overhead, using the following stack. 2179 HTTP/TCP/IP/ESP/IP/PPP/AHDLC 2181 In this case IPSec is used in tunnel mode, with the tunnel 2182 terminating either on an IPSec edge device at the enterprise site, or 2183 on the provider edge router connected to the enterprise site. There 2184 are two possibilities for the IP addressing of the host. Two IP 2185 addresses could be used, in a similar manner to the L2TP case. 2186 Alternatively the host can use a single public IP address as the 2187 source IP address in both inner and outer IP headers, with the 2188 gateway performing Network Address Translation (NAT) before 2189 forwarding the traffic to the enterprise network. To other hosts in 2190 the enterprise network the host appears to have an 'internal' IP 2191 address. Using NAT has some limitations and restrictions, also 2192 pointed out in [58]. 2194 Another area of potential problems with PPP is due to the fact that 2195 the characteristics of a link layer implemented via an L2TP tunnel 2196 over an IP backbone are quite different to a link layer run over a 2197 serial line, as discussed in the L2TP specification itself. For 2198 example, poorly chosen PPP parameters may lead to frequent resets and 2199 timeouts, particularly if compression is in use. This is because an 2200 L2TP tunnel may misorder packets, and may silently drop packets, 2201 neither of which normally occurs on serial lines. The general packet 2202 loss rate could also be significantly higher due to network 2203 congestion. Using the sequence number field in an L2TP header 2204 addresses the misordering issue, and for cases where the LAC and LNS 2205 are coincident with the PPP endpoints, as in voluntary tunneling, the 2206 sequence number field can also be used to detect a dropped packet, 2207 and to pass a suitable indication to any compression entity in use, 2208 which typically requires such knowledge in order to keep the 2209 compression histories in synchronization at both ends. (In fact this 2210 is more of an issue with compulsory tunneling since the LAC may have 2211 to deliberately issue a corrupted frame to the PPP host, to give an 2212 indication of packet loss, and some hardware may not allow this). 2214 6.3.2 Issues with Use of IPSec for Voluntary Tunnels 2216 If IPSec is used for voluntary tunneling, the functions of user 2217 authentication and host configuration, achieved by means of PPP when 2218 using L2TP, still need to be carried out. A distinction needs to be 2219 drawn here between machine authentication and user authentication. 2220 'Two factor' authentication is carried out on the basis of both 2221 something the user has, such as a machine or smartcard with a digital 2222 certificate, and something the user knows, such as a password. 2223 (Another example is getting money from an bank ATM machine - you need 2224 a card and a PIN number). Many of the existing legacy schemes 2225 currently in use to perform user authentication are asymmetric in 2226 nature, and are not supported by IKE. For remote access the most 2227 common existing user authentication mechanism is to use PPP between 2228 the user and access server, and Radius between the access server and 2229 authentication server. The authentication exchanges that occur in 2230 this case, e.g. a PAP or CHAP exchange, are asymmetric. Also CHAP 2231 supports the ability for the network to reauthenticate the user at 2232 any time after the initial session has been established, to ensure 2233 that the current user is the same person that initiated the session. 2235 While IKE provides strong support for machine authentication, it has 2236 only limited support for any form of user authentication and has no 2237 support for asymmetric user authentication. While a user password 2238 can be used to derive a key used as a preshared key, this cannot be 2239 used with IKE Main Mode in a remote access environment, as the user 2240 will not have a fixed IP address, and while Aggressive Mode can be 2241 used instead, this affords no identity protection. To this end there 2242 have been a number of proposals to allow for support of legacy 2243 asymmetric user level authentication schemes with IPSec. [59] 2244 defines a new IKE message exchange - the transaction exchange - which 2245 allows for both Request/Reply and Set/Acknowledge message sequences, 2246 and it also defines attributes that can be used for client IP stack 2247 configuration. [60] and [61] describe mechanisms that use the 2248 transaction message exchange, or a series of such exchanges, carried 2249 out between the IKE Phase 1 and Phase 2 exchanges, to perform user 2250 authentication. A different approach, that does not extend the IKE 2251 protocol itself, is described in [62]. With this approach a user 2252 establishes a Phase 1 SA with a security gateway and then sets up a 2253 Phase 2 SA to the gateway, over which an existing authentication 2254 protocol is run. The gateway acts as a proxy and relays the protocol 2255 messages to an authentication server. 2257 In addition there have also been proposals to allow the remote host 2258 to be configured with an IP address and other configuration 2259 information over IPSec. For example [63] describes a method whereby 2260 a remote host first establishes a Phase 1 SA with a security gateway 2261 and then sets up a Phase 2 SA to the gateway, over which the DHCP 2262 protocol is run. The gateway acts as a proxy and relays the protocol 2263 messages to the DHCP server. Again, like [62], this proposal does 2264 not involve extensions to the IKE protocol itself. 2266 Another aspect of PPP functionality that may need to supported is 2267 multiprotocol operation, as there may be a need to carry network 2268 layer protocols other than IP, and even to carry link layer protocols 2269 (e.g. ethernet) as would be needed to support bridging over IPSec. 2270 This is discussed in section 3.1.4. 2272 The methods of supporting legacy user authentication and host 2273 configuration capabilities in a remote access environment are 2274 currently being discussed in the IPSec working group. 2276 6.4 Networked Host Support 2278 The current PPP based dial model assumes a host directly connected to 2279 a connection oriented dial access network. Recent work on new access 2280 technologies such as DSL have attempted to replicate this model [57], 2281 so as to allow for the re-use of existing AAA systems. The 2282 proliferation of personal computers, printers and other network 2283 appliances in homes and small businesses, and the ever lowering costs 2284 of networks, however, are increasingly challenging the directly 2285 connected host model. Increasingly, most hosts will access the 2286 Internet through small, typically Ethernet, local area networks. 2288 There is hence interest in means of accommodating the existing AAA 2289 infrastructure within service providers, whilst also supporting 2290 multiple networked hosts at each customer site. The principal 2291 complication with this scenario is the need to support the login 2292 dialogue, through which the appropriate AAA information is exchanged. 2293 A number of proposals have been made to address this scenario: 2295 6.4.1 Extension of PPP to Hosts Through L2TP 2297 A number of proposals (e.g. [56]) have been made to extend L2TP over 2298 Ethernet so that PPP sessions can run from networked hosts out to the 2299 network, in much the same manner as a directly attached host. 2301 6.4.2 Extension of PPP Directly to Hosts: 2303 There is also a specification for mapping PPP directly onto Ethernet 2304 (PPPOE) [64] which uses a broadcast mechanism to allow hosts to find 2305 appropriate access servers with which to connect. Such servers could 2306 then further tunnel, if needed, the PPP sessions using L2TP or a 2307 similar mechanism. 2309 6.4.3 Use of IPSec 2311 The IPSec based voluntary tunneling mechanisms discussed above can be 2312 used either with networked or directly connected hosts. 2314 Note that all of these methods require additional host software to be 2315 used, which implements either LAC, PPPOE client or IPSec client 2316 functionality. 2318 6.5 Recommendations 2320 The L2TP specification has been finalized and will be widely used for 2321 compulsory tunneling. As discussed in section 3.2, defining specific 2322 modes of operation for IPSec when used to secure L2TP would be 2323 beneficial. 2325 Also, for voluntary tunneling using IPSec, completing the work needed 2326 to provide support for the following areas would be useful 2328 - asymmetric / legacy user authentication (6.3) 2330 - host address assignment and configuration (6.3) 2331 along with any other issues specifically related to the support of 2332 remote hosts. Currently as there are many different non-interoperable 2333 proprietary solutions in this area. 2335 7.0 VPN Types: Virtual Private LAN Segment 2337 A Virtual Private LAN Segment (VPLS) is the emulation of a LAN 2338 segment using Internet facilities. A VPLS can be used to provide 2339 what is sometimes known also as a Transparent LAN Service (TLS), 2340 which can be used to interconnect multiple stub CPE nodes, either 2341 bridges or routers, in a protocol transparent manner. A VPLS 2342 emulates a LAN segment over IP, in the same way as protocols such as 2343 LANE emulate a LAN segment over ATM. The primary benefits of a VPLS 2344 are complete protocol transparency, which may be important both for 2345 multiprotocol transport and for regulatory reasons in particular 2346 service provider contexts. 2348 10.1.1.1 +--------+ +--------+ 10.1.1.2 2349 +---+ | ISP | IP tunnel | ISP | +---+ 2350 |CPE|-------| edge |-----------------------| edge |-------|CPE| 2351 +---+ stub | node | | node | stub +---+ 2352 link +--------+ +--------+ link 2353 ^ | | ^ 2354 | | --------------- | | 2355 | | ( ) | | 2356 | +----( IP BACKBONE )----+ | 2357 | ( ) | 2358 | --------------- | 2359 | | | 2360 |IP tunnel +--------+ IP tunnel| 2361 | | ISP | | 2362 +-----------| edge |-----------+ 2363 | node | 2364 +--------+ subnet = 10.1.1.0/24 2365 | 2366 stub link | 2367 | 2368 +---+ 2369 |CPE| 10.1.1.3 2370 +---+ 2372 Figure 7.1: VPLS Example 2374 7.1 VPLS Requirements 2376 Topologically and operationally a VPLS can be most easily modelled as 2377 being essentially equivalent to a VPRN, except that each VPLS edge 2378 node implements link layer bridging rather than network layer 2379 forwarding. As such, most of the VPRN tunneling and configuration 2380 mechanisms discussed previously can also be used for a VPLS, with the 2381 appropriate changes to accommodate link layer, rather than network 2382 layer, packets and addressing information. The following sections 2383 discuss the primary changes needed in VPRN operation to support 2384 VPLSs. 2386 7.1.1 Tunneling Protocols 2388 The tunneling protocols employed within a VPLS can be exactly the 2389 same as those used within a VPRN, if the tunneling protocol permits 2390 the transport of multiprotocol traffic, and this is assumed below. 2392 7.1.2 Multicast and Broadcast Support 2394 A VPLS needs to have a broadcast capability. This is needed both for 2395 broadcast frames, and for link layer packet flooding, where a unicast 2396 frame is flooded because the path to the destination link layer 2397 address is unknown. The address resolution protocols that run over a 2398 bridged network typically use broadcast frames (e.g. ARP). The same 2399 set of possible multicast tunneling mechanisms discussed earlier for 2400 VPRNs apply also to a VPLS, though the generally more frequent use of 2401 broadcast in VPLSs may increase the pressure for native multicast 2402 support that reduces, for instance, the burden of replication on VPLS 2403 edge nodes. 2405 7.1.3 VPLS Membership Configuration and Topology 2407 The configuration of VPLS membership is analogous to that of VPRNs 2408 since this generally requires only knowledge of the local VPN link 2409 assignments at any given VPLS edge node, and the identity of, or 2410 route to, the other edge nodes in the VPLS; in particular, such 2411 configuration is independent of the nature of the forwarding at each 2412 VPN edge node. As such, any of the mechanisms for VPN member 2413 configuration and dissemination discussed for VPRN configuration can 2414 also be applied to VPLS configuration. Also as with VPRNs, the 2415 topology of the VPLS could be easily manipulated by controlling the 2416 configuration of peer nodes at each VPLS edge node, assuming that the 2417 membership dissemination mechanism was such as to permit this. It is 2418 likely that typical VPLSs will be fully meshed, however, in order to 2419 preclude the need for traffic between two VPLS nodes to transit 2420 through another VPLS node, which would then require the use of the 2421 Spanning Tree protocol [65] for loop prevention. 2423 7.1.4 CPE Stub Node Types 2425 A VPLS can support either bridges or routers as a CPE device. 2427 CPE routers would peer transparently across a VPLS with each other 2428 without requiring any router peering with any nodes within the VPLS. 2429 The same scalability issues that apply to a full mesh topology for 2430 VPRNs, apply also in this case, only that now the number of peering 2431 routers is potentially greater, since the ISP edge device is no 2432 longer acting as an aggregation point. 2434 With CPE bridge devices the broadcast domain encompasses all the CPE 2435 sites as well as the VPLS itself. There are significant scalability 2436 constraints in this case, due to the need for packet flooding, and 2437 the fact that any topology change in the bridged domain is not 2438 localized, but is visible throughout the domain. As such this 2439 scenario is generally only suited for support of non-routable 2440 protocols. 2442 The nature of the CPE impacts the nature of the encapsulation, 2443 addressing, forwarding and reachability protocols within the VPLS, 2444 and are discussed separately below. 2446 7.1.5 Stub Link Packet Encapsulation 2448 7.1.5.1 Bridge CPE 2450 In this case, packets sent to and from the VPLS across stub links are 2451 link layer frames, with a suitable access link encapsulation. The 2452 most common case is likely to be ethernet frames, using an 2453 encapsulation appropriate to the particular access technology, such 2454 as ATM, connecting the CPE bridges to the VPLS edge nodes. Such 2455 frames are then forwarded at layer 2 onto a tunnel used in the VPLS. 2456 As noted previously, this does mandate the use of an IP tunneling 2457 protocol which can transport such link layer frames. Note that this 2458 does not necessarily mandate, however, the use of a protocol 2459 identification field in each tunnel packet, since the nature of the 2460 encapsulated traffic (e.g. ethernet frames) could be indicated at 2461 tunnel setup. 2463 7.1.5.2 Router CPE 2465 In this case, typically, CPE routers send link layer packets to and 2466 from the VPLS across stub links, destined to the link layer addresses 2467 of their peer CPE routers. Other types of encapsulations may also 2468 prove feasible in such a case, however, since the relatively 2469 constrained addressing space needed for a VPLS to which only router 2470 CPE are connected, could allow for alternative encapsulations, as 2471 discussed further below. 2473 7.1.6 CPE Addressing and Address Resolution 2475 7.1.6.1 Bridge CPE 2477 Since a VPLS operates at the link layer, all hosts within all stub 2478 sites, in the case of bridge CPE, will typically be in the same 2479 network layer subnet. (Multinetting, whereby multiple subnets 2480 operate over the same LAN segment, is possible, but much less 2481 common). Frames are forwarded across and within the VPLS based upon 2482 the link layer addresses - e.g. IEEE MAC addresses - associated with 2483 the individual hosts. The VPLS needs to support broadcast traffic, 2484 such as that typically used for the address resolution mechanism used 2485 to map the host network addresses to their respective link addresses. 2486 The VPLS forwarding and reachability algorithms also need to be able 2487 to accommodate flooded traffic. 2489 7.1.6.2 Router CPE 2491 A single network layer subnet is generally used to interconnect 2492 router CPE devices, across a VPLS. Behind each CPE router are hosts 2493 in different network layer subnets. CPE routers transfer packets 2494 across the VPLS by mapping next hop network layer addresses to the 2495 link layer addresses of a router peer. A link layer encapsulation is 2496 used, most commonly ethernet, as for the bridge case. 2498 As noted above, however, in cases where all of the CPE nodes 2499 connected to the VPLS are routers, then it may be possible, due to 2500 the constrained addressing space of the VPLS, to use encapsulations 2501 that use a different address space than normal MAC addressing. See, 2502 for instance, [11], for a proposed mechanism for VPLSs over MPLS 2503 networks, leveraging earlier work on VPRN support over MPLS [38], 2504 which proposes MPLS as the tunneling mechanism, and locally assigned 2505 MPLS labels as the link layer addressing scheme to identify the CPE 2506 LSR routers connected to the VPLS. 2508 7.1.7 VPLS Edge Node Forwarding and Reachability Mechanisms 2510 7.1.7.1 Bridge CPE 2512 The only practical VPLS edge node forwarding mechanism in this case 2513 is likely to be standard link layer packet flooding and MAC address 2514 learning, as per [65]. As such, no explicit intra-VPLS reachability 2515 protocol will be needed, though there will be a need for broadcast 2516 mechanisms to flood traffic, as discussed above. In general, it may 2517 not prove necessary to also implement the Spanning Tree protocol 2518 between VPLS edge nodes, if the VPLS topology is such that no VPLS 2519 edge node is used for transit traffic between any other VPLS edge 2520 nodes - in other words, where there is both full mesh connectivity 2521 and transit is explicitly precluded. On the other hand, the CPE 2522 bridges may well implement the spanning tree protocol in order to 2523 safeguard against 'backdoor' paths that bypass connectivity through 2524 the VPLS. 2526 7.1.7.2 Router CPE 2528 Standard bridging techniques can also be used in this case. In 2529 addition, the smaller link layer address space of such a VPLS may 2530 also permit other techniques, with explicit link layer routes between 2531 CPE routers. [11], for instance, proposes that MPLS LSPs be set up, 2532 at the insertion of any new CPE router into the VPLS, between all CPE 2533 LSRs. This then precludes the need for packet flooding. In the more 2534 general case, if stub link reachability mechanisms were used to 2535 configure VPLS edge nodes with the link layer addresses of the CPE 2536 routers connected to them, then modifications of any of the intra-VPN 2537 reachability mechanisms discussed for VPRNs could be used to 2538 propagate this information to each other VPLS edge node. This would 2539 then allow for packet forwarding across the VPLS without flooding. 2541 Mechanisms could also be developed to further propagate the link 2542 layer addresses of peer CPE routers and their corresponding network 2543 layer addresses across the stub links to the CPE routers, where such 2544 information could be inserted into the CPE router's address 2545 resolution tables. This would then also preclude the need for 2546 broadcast address resolution protocols across the VPLS. 2548 Clearly there would be no need for the support of spanning tree 2549 protocols if explicit link layer routes were determined across the 2550 VPLS. If normal flooding mechanisms were used then spanning tree 2551 would only be required if full mesh connectivity was not available 2552 and hence VPLS nodes had to carry transit traffic. 2554 7.2 Recommendations 2556 There is significant commonality between VPRNs and VPLSs, and, where 2557 possible, this similarity should be exploited in order to reduce 2558 development and configuration complexity. In particular, VPLSs 2559 should utilize the same tunneling and membership configuration 2560 mechanisms, with changes only to reflect the specific characteristics 2561 of VPLSs. 2563 8.0 Summary of Recommendations 2565 In this document different types of VPNs have been discussed 2566 individually, but there are many common requirements and mechanisms 2567 that apply to all types of VPNs, and many networks will contain a mix 2568 of different types of VPNs. It is useful to have as much commonality 2569 as possible across these different VPN types. In particular, by 2570 standardizing a relatively small number of mechanisms, it is possible 2571 to allow a wide variety of VPNs to be implemented. 2573 The benefits of adding support for the following mechanisms should be 2574 carefully examined. 2576 For IKE/IPSec: 2578 - the transport of a VPN-ID when establishing an SA (3.1.2) 2580 - a null encryption and null authentication option (3.1.3) 2582 - multiprotocol operation (3.1.4) 2584 - frame sequencing (3.1.5) 2586 - asymmetric / legacy user authentication (6.3) 2588 - host address assignment and configuration (6.3) 2590 For L2TP: 2592 - defining modes of operation of IPSec when used to support L2TP 2593 (3.2) 2595 For VPNs generally: 2597 - defining a VPN membership information configuration and 2598 dissemination mechanism, that uses some form of directory or MIB 2599 (5.3.2) 2601 - ensure that solutions developed, as far as possible, are 2602 applicable to different types of VPNs, rather than being specific 2603 to a single type of VPN. 2605 9.0 Security considerations 2607 Security considerations are an integral part of any VPN mechanisms, 2608 and these are discussed in the sections describing those mechanisms. 2610 10.0 Acknowledgements 2612 Thanks to Anthony Alles, of Nortel Networks, for his invaluable 2613 assistance with the generation of this document, and who developed 2614 much of the material on which early versions of this document were 2615 based. Thanks also to Joel Halpern for his helpful review comments. 2617 11.0 References 2619 [1] ATM Forum. "LAN Emulation over ATM 1.0", af-lane-0021.000, 2620 January 1995. 2622 [2] ATM Forum. "Multi-Protocol Over ATM Specification v1.0", af- 2623 mpoa-0087.000, June 1997. 2625 [3] Ferguson, P. and Huston, G. "What is a VPN?", Revision 1, April 2626 1 1998; http://www.employees.org/~ferguson/vpn.pdf. 2628 [4] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and 2629 E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 2630 1918, February 1996. 2632 [5] Kent, S. and R. Atkinson, "Security Architecture for the 2633 Internet Protocol", RFC 2401, November 1998. 2635 [6] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 2636 1996. 2638 [7] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic 2639 Routing Encapsulation (GRE)", RFC 1702, October 1994. 2641 [8] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and 2642 B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, 2643 August 1999. 2645 [9] Rosen, E., et al "Multiprotocol Label Switching Architecture", 2646 Work in Progress. 2648 [10] Heinanen, J., et al. "MPLS Mappings of Generic VPN Mechanisms", 2649 Work in Progress. 2651 [11] Jamieson, D., et al. "MPLS VPN Architecture", Work in Progress. 2653 [12] Casey, L. et al. "IP VPN Realization using MPLS Tunnels", Work 2654 in Progress. 2656 [13] Li, T. "CPE based VPNs using MPLS", Work in Progress. 2658 [14] Muthukrishnan, K. and Malis A. "Core IP VPN Architecture", Work 2659 in Progress. 2661 [15] Rosen, E. and Rekhter, Y. "BGP/MPLS VPNs", RFC 2547, March 2662 1999. 2664 [16] Fox, B. and Gleeson, B. "Virtual Private Networks Identifier", 2665 RFC 2685, September 1999. 2667 [17] Petri, B. (editor) "MPOA v1.1 Addendum on VPN support", ATM 2668 Forum, af-mpoa-0129.000. 2670 [18] Harkins, D. and C. Carrel, "The Internet Key Exchange (IKE)", 2671 RFC 2409, November 1998. 2673 [19] Calhoun, P. et al. "Tunnel Establishment Protocol", Work in 2674 Progress. 2676 [20] Andersson, L., et al. "LDP Specification", Work in Progress. 2678 [21] Jamoussi, B. et al. "Constraint-Based LSP Setup using LDP" Work 2679 in Progress. 2681 [22] Awduche, D. et al. "Extensions to RSVP for LSP Tunnels", Work 2682 in Progress. 2684 [23] Kent, S. and R. Atkinson, "IP Encapsulating Security Protocol 2685 (ESP)", RFC 2406, November 1998. 2687 [24] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 2688 51, RFC 1661, July 1994. 2690 [25] Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D. and 2691 A. Malis, "ATM Signalling Support for IP over ATM", RFC 1755, 2692 February 1995. 2694 [26] Malkin, G. "RIP Version 2 Carrying Additional Information", 2695 RFC 1723, November 1994. 2697 [27] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 2699 [28] Shacham, A., Monsour, R., Pereira, R. and Thomas, M. "IP 2700 Payload Compression Protocol (IPComp)" RFC 2393, December 1998. 2702 [29] Duffield N, et al. "A Performance Oriented Service Interface 2703 for Virtual Private Networks", Work in Progress. 2705 [30] Jacobson, V., Nichols, K. and Poduri, K. "An Expedited 2706 Forwarding PHB", RFC2598, June 1999 2708 [31] Casey, L. "An extended IP VPN Architecture", Work in Progress. 2710 [32] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)," 2711 RFC 1771, March 1995. 2713 [33] Grossman, D. and Heinanen, J. "Multiprotocol Encapsulation over 2714 ATM Adaptation Layer 5", RFC 2684, September 1999. 2716 [34] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access 2717 Protocol (v3)", RFC 2251, December 1997. 2719 [35] Boyle, J. et al. "The COPS (Common Open Policy Service) 2720 Protocol", Work in Progress. 2722 [36] MacRae, M. and Ayandeh, S. "Using COPS for VPN Connectivity" 2723 Work in Progress. 2725 [37] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 2726 March 1997. 2728 [38] Heinanen, J. and Rosen, E. "VPN Support with MPLS" Work in 2729 Progress. 2731 [39] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., 2732 Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei, 2733 "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol 2734 Specification", RFC 2362, June 1998. 2736 [40] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector 2737 Multicast Routing Protocol", RFC 1075, November 1988. 2739 [41] Fenner, W. "IGMP-based Multicast Forwarding (IGMP Proxying)", 2740 Work in Progress. 2742 [42] Wallner, D., Harder, E. and Agee R. "Key Management for 2743 Multicast: Issues and Architectures" RFC 2627, June 1999 2745 [43] Hardjono, T. et al. "Secure IP Multicast: Problem areas, 2746 Framework, and Building Blocks" Work in Progress. 2748 [44] Rigney, C., Rubens, A., Simpson, W., and Willens, S., "Remote 2749 Authentication Dial In User Service (RADIUS)", RFC 2138, April 2750 1997. 2752 [45] Valencia, A., Littlewood, M. and T. Kolar. "Cisco Layer Two 2753 Forwarding (Protocol) "L2F"", RFC 2341, May 1998. 2755 [46] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and 2756 Zorn G., "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, 2757 July 1999. 2759 [47] Patel, B. et al. "Securing L2TP using IPSEC", Work in Progress. 2761 [48] Srisuresh, P. "Secure Remote Access with L2TP", Work in 2762 Progress. 2764 [49] Calhoun, P., et al. "Layer Two Tunneling Protocol "L2TP" 2765 Security Extensions for Non-IP networks", Work in Progress. 2767 [50] Aboba, B. and Zorn, G. "Implementation of PPTP/L2TP Compulsory 2768 Tunneling via RADIUS", Work in progress. 2770 [51] Aboba, B. and Zorn, G. "Criteria for Evaluating Roaming 2771 Protocols", RFC 2477, January 1999. 2773 [52] Shea, R. "L2TP-over-IP Path MTU Discovery (L2TPMTU)", Work in 2774 Progress. 2776 [53] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. 2777 Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 2778 1996. 2780 [54] Richards, C. and K. Smith, "The PPP Bandwidth Allocation 2781 Protocol (BAP) The PPP Bandwidth Allocation Control Protocol 2782 (BACP)", RFC 2125, March 1997. 2784 [55] Calhoun, P. and Peirce, K. "Layer Two Tunneling Protocol "L2TP" 2785 IP Differential Services Extension", Work in Progress. 2787 [56] ADSL Forum. "An Interoperable End-to-end Broadband Service 2788 Architecture over ADSL Systems (Version 3.0)", ADSL Forum 97- 2789 215. 2791 [57] ADSL Forum. "Core Network Architectures for ADSL Access Systems 2792 (Version 1.01)", ADSL Forum 98-017. 2794 [58] Gupta, V. "Secure, Remote Access over the Internet using 2795 IPSec", Work in Progress. 2797 [59] Pereira, R. et al. "The ISAKMP Configuration Method", Work in 2798 Progress. 2800 [60] Pereira, R. and Beaulieu, S. "Extended Authentication Within 2801 ISAKMP/Oakley", Work in Progress. 2803 [61] Litvin, M. et al. "A Hybrid Authentication Mode for IKE", Work 2804 in Progress. 2806 [62] Kelly, S. et al. "User-level Authentication Mechanisms for 2807 IPsec", Work in Progress. 2809 [63] Patel, B. et al. "DHCP Configuration of IPSEC Tunnel Mode", 2810 Work in Progress. 2812 [64] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. and 2813 Wheeler, R., "A Method for Transmitting PPP Over Ethernet 2814 (PPPoE)", RFC 2516, February 1999 2816 [65] ANSI/IEEE - 10038: 1993 (ISO/IEC) Information technology - 2817 Telecommunications and information exchange between systems - 2818 Local area networks - Media access control (MAC) bridges, 2819 ANSI/IEEE Std 802.1D, 1993 Edition. 2821 12.0 Author Information 2823 Bryan Gleeson 2824 Nortel Networks 2825 4500 Great America Parkway 2826 Santa Clara CA 95054 2827 USA 2828 Tel: +1 (408) 548 3711 2829 Email: bgleeson@shastanets.com 2831 Juha Heinanen 2832 Telia Finland, Inc. 2833 Myyrmaentie 2 2834 01600 VANTAA 2835 Finland 2836 Tel: +358 303 944 808 2837 Email: jh@telia.fi 2839 Arthur Lin 2840 Nortel Networks 2841 4500 Great America Parkway 2842 Santa Clara CA 95054 2843 USA 2844 Tel: +1 (408) 548 3788 2845 Email: alin@shastanets.com 2847 Grenville Armitage 2848 Bell Labs Research Silicon Valley 2849 3180 Porter Drive, 2850 Palo Alto, CA 94304 2851 USA 2852 Email: gja@lucent.com 2854 Andrew G. Malis 2855 Lucent Technologies 2856 1 Robbins Road 2857 Westford, MA 01886 2858 USA 2859 Tel: +1 978 952 7414 2860 Email: amalis@lucent.com 2862 13.0 Full Copyright Statement 2864 Copyright (C) The Internet Society (1999). All Rights Reserved. 2866 This document and translations of it may be copied and furnished to 2867 others, and derivative works that comment on or otherwise explain it 2868 or assist in its implementation may be prepared, copied, published 2869 and distributed, in whole or in part, without restriction of any 2870 kind, provided that the above copyright notice and this paragraph are 2871 included on all such copies and derivative works. However, this 2872 document itself may not be modified in any way, such as by removing 2873 the copyright notice or references to the Internet Society or other 2874 Internet organizations, except as needed for the purpose of 2875 developing Internet standards in which case the procedures for 2876 copyrights defined in the Internet Standards process must be 2877 followed, or as required to translate it into languages other than 2878 English. 2880 The limited permissions granted above are perpetual and will not be 2881 revoked by the Internet Society or its successors or assigns. 2883 This document and the information contained herein is provided on an 2884 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2885 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2886 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2887 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2888 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.