idnits 2.17.1 draft-heinanen-generic-vpn-mpls-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 20 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 21 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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) ** Obsolete normative reference: RFC 2283 (ref. 'Bates') (Obsoleted by RFC 2858) == Outdated reference: A later version (-07) exists of draft-ietf-mpls-arch-02 ** Downref: Normative reference to an Informational RFC: RFC 1998 (ref. 'Chandra') ** Obsolete normative reference: RFC 2370 (ref. 'Coltun') (Obsoleted by RFC 5250) -- Possible downref: Normative reference to a draft: ref. 'Davie' ** Downref: Normative reference to an Informational RFC: RFC 1702 (ref. 'Hanks') -- Unexpected draft version: The latest known version of draft-ietf-ipsec-isakmp-oakley is -07, but you're referring to -08. ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp-oakley (ref. 'Harkins') -- Possible downref: Normative reference to a draft: ref. 'Heinanen' ** Downref: Normative reference to an Informational draft: draft-li-paste (ref. 'Li') ** Obsolete normative reference: RFC 1723 (ref. 'Malkin') (Obsoleted by RFC 2453) ** Obsolete normative reference: RFC 1771 (ref. 'Rekhter2') (Obsoleted by RFC 4271) == Outdated reference: A later version (-05) exists of draft-ietf-mpls-bgp4-mpls-00 ** Downref: Normative reference to an Informational RFC: RFC 1853 (ref. 'Simpson') == Outdated reference: A later version (-16) exists of draft-ietf-pppext-l2tp-11 Summary: 20 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group Juha Heinanen 3 Internet Engineering Task Force Telia Finland, Inc. 4 INTERNET DRAFT Bryan Gleeson, Arthur Lin 5 Expires February 1998 Shasta Networks, Inc. 7 MPLS Mappings of Generic VPN Mechanisms 8 10 1. Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as "work in progress." 22 To view the entire list of current Internet-Drafts, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 25 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 26 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 28 2. Abstract 30 This document describes a set of generic mechanisms which can be used 31 to set up network based Virtual Private Networks (VPN) across IP 32 networks. In particular, it describes how these mechanisms can be 33 mapped into a network running the Multi-Protocol Label Switching 34 (MPLS) specification. The mechanisms described, however, can apply 35 to any type of IP network running various forms of IP tunneling 36 mechanisms, and are not solely restricted to MPLS networks. This 37 Draft serves to introduce these generic mechanisms, which are part of 38 the broader VPN framework which will be described more fully in 39 forthcoming Drafts. 41 3. Introduction 43 An earlier Draft [Heinanen] proposed a number of mechanisms for 44 Virtual Private Network (VPN) support in networks running the Multi- 45 Protocol Label Switching (MPLS) specification [Callon]. 47 Subsequently, it was noted that most of the mechanisms proposed in 48 that Draft are subsets of generic VPN mechanisms, and can also apply 49 to current IP networks. Hence this Draft first discusses these 50 generic mechanisms and shows how these may be applied in general IP 51 networks. In particular, these can be applied in IP networks not 52 running any major new protocol, such as MPLS, which may facilitate 53 roll- out of VPN services on current IP networks, prior to the 54 possible future deployment of MPLS. Subsequently, the Draft also 55 discusses how these mechanisms can be applied to MPLS networks in 56 particular. 58 As with the earlier Draft, this Draft is intended to serve as a 59 framework, highlighting areas for more detailed specification. 60 Neither has enough detail to allow for interoperable implementations. 61 Hence more work is required to finalize a specification for VPN 62 support, both on MPLS networks and on current networks. A future 63 Internet Draft will propose a more general VPN framework and specific 64 areas for future specification so as to allow more general 65 interoperable VPN solutions. 67 4. VPN Definition and Scope 69 A VPN can be succinctly defined as the emulation of a private wide 70 area network (WAN) facility using IP facilities (including the public 71 Internet, or private IP backbones). There are a wide variety of VPN 72 types, corresponding to the very wide variety of WAN facilities that 73 are currently defined. Future Drafts will discuss the full range of 74 possible VPN types, but the particular type of VPN specifically 75 discussed in this Draft can be described as a 'virtual private routed 76 network' (VPRN), in which a customer with multiple geographically 77 dispersed sites wishes to connect each of these sites together into a 78 private network. Such networks are routinely built today using, for 79 instance, frame relay links and/or leased lines between the routers 80 at each pair of sites, or, more likely, given the cost of such links, 81 by star wiring each site to a single central site. 83 A VPRN emulates such a network using dedicated IP links. The nature 84 of the connectivity of these sites is discussed further below, but 85 for the moment it can be assumed that it is desired that each of 86 these sites be logically meshed to each other site, since there is 87 less cost assumed with full meshing in a virtual IP network, than in 88 cases where physical resources (e.g. Frame Relay DLCI, or a leased 89 line) must be allocated for each connected pair of sites. This 90 yields optimal routing, since it precludes the need for traffic 91 between two sites to traverse through a third. 93 VPNs of various sorts are today routinely implemented using a 94 combination of host applications and customer premises equipment 95 (CPE) routers. The mechanisms discussed in both this Draft and its 96 predecessor, however, apply specifically only to the class of 97 'network based VPNs', where the operation of the VPN is outsourced to 98 an Internet service provider (ISP), and is implemented on network as 99 opposed to CPE equipment. There is significant interest in such 100 solutions both by customers seeking to reduce support costs and by 101 ISPs seeking new revenue sources. The network based focus allows the 102 use of particular mechanisms which may lead to highly efficient and 103 cost effective VPRN solutions. However such mechanisms also leverage 104 tools (e.g. piggybacking on routing protocols) which are accessible 105 only to ISPs and which are unlikely to be made available to any 106 customer, or even hosted on ISP owned and operated CPE, due to the 107 problems of coordinating joint management of the CPE gear by both the 108 ISP and the customer. 110 Hence, it is assumed that each customer site CPE router connects to 111 an ISP edge router through one or more dedicated point-to-point stub 112 links (e.g. leased lines, ATM or Frame Relay connections); the VPRN 113 mechanisms discussed below will operate on each of these ISP edge 114 routers, in order to route traffic received across a stub link to the 115 appropriate destination customer site across its stub link. In 116 particular, the edge router will hide all VPRN topology information 117 from the CPE routers, hence significantly simplifying the operation 118 of the CPE. 120 Note that a single ISP edge router could terminate multiple stub 121 links belonging to the same VPRN. The means by which traffic is 122 routed between such local interfaces is outside the scope of 123 standardization, per se, though obviously these would leverage many 124 of the same routing and forwarding mechanisms used for communication 125 with remote VPN sites. 127 In such a scenario, a VPN connecting each of these sites must 128 generally meet a number of minimum requirements, which arise from the 129 need to essentially emulate the facilities that customers expect from 130 a leased line facility, and which, hence, they also generally expect 131 from any emulation of such a facility. While there are a number of 132 such requirements, three are of particular concern to this Draft: 134 A. Support for Disjoint Address Spaces: 136 The addressing used within the VPRN may have no relation to the 137 addressing of the ISP, or ISPs, across which the VPRN may operate. 138 In particular, the former may also be non-unique, private IP 139 addressing [Rekhter1]. 141 B. Support for Intra-VPN routing: 143 Since a VPRN will generally interconnect multiple sites, the VPRN 144 mechanism must implement some mechanism by which intra-VPN traffic 145 can be efficiently routed to the correct destination site within the 146 VPRN. 148 C. Support for Data Security: 150 In general, customers using VPNs require some form of data security, 151 given the general perceptions of the lack of security of IP networks, 152 and particularly that of the Internet. Whether or not this 153 perception is correct, it is one that must be addressed by any VPN 154 implementation. Most recent VPN implementations are converging on 155 the use of IPSec facilities [Kent] for this purpose. 157 Together, these requirements imply that VPRNs must be implemented 158 through some form of IP tunneling mechanism, where the addressing 159 used within the VPRN can be disjoint from that used to route the 160 tunneled packets across the IP backbone. Such tunnels, depending 161 upon their form, can provide some level of intrinsic data security, 162 or this can also be enhanced using other mechanisms (e.g. IPSec). 164 Such tunnels together form an overlay network operating over and 165 across the general Internet backbone, connecting each of the ISP edge 166 routers supporting VPN stub links to each other. Within each of the 167 ISP edge routers, there must be VPN specific IP forwarding 168 mechanisms, to forward packets received across each of the stub links 169 ('ingress' traffic) to the appropriate destination edge router, based 170 upon the address space of the customer's network, and to forward 171 packets received from the core ('egress' traffic) to the appropriate 172 stub link, for cases where an edge router supports multiple stub 173 links belonging to the same VPN (as will be noted below, VPN tunnels 174 can, as a local matter, either terminate on the edge router, or on 175 each stub link; in the former case, a VPN specific forwarding table 176 is needed for egress traffic, in the latter case, it is not). 178 Note also that a single customer site may belong concurrently to 179 multiple VPNs, of various sorts, and/or may wish to transmit traffic 180 both onto one or more VPNs and to the default Internet. The 181 mechanisms needed to do this are outside the scope of this Draft, and 182 are not discussed further. 184 For the purposes of this Draft, it is also assumed that all of the 185 traffic being sent across the VPRN is IP traffic, since the devices 186 implementing the VPRN need to be able to interpret the packet header 187 information to determine the appropriate end-point within the VPRN. 188 However, that procedures discussed here could be readily extended for 189 Multiprotocol transport, either by forming separate VPRNs for each 190 protocol, or by running Multiprotocol routing and forwarding 191 procedures in each VPN router, and multiplexing multiple protocols 192 across the VPN stub links. IP encapsulation methods could also be 193 used to transport different protocols across IP links. These 194 multiprotocol transport mechanisms are left for further study. 196 5. Generic VPN Mechanisms 198 ISPs wishing to offer tunnel based VPRN services need to be able to 199 do so with minimal configuration, since this yields the most cost 200 effective solution. The generic VPN mechanisms discussed here apply 201 to the means by which this can be done. The following sections 202 discuss these in detail. 204 5.1 VPN Membership Information Configuration and Dissemination 206 In order to establish a VPRN, or to insert new customer sites into an 207 established VPRN, the stub links on each edge router from those sites 208 in the particular VPRN must first be configured with the identity of 209 the particular VPRN to which the stub links belong. Note that this 210 first step, of stub link configuration, is unavoidable, since clearly 211 the edge router cannot infer such bindings and hence must be 212 configured with this information. The means by which this is done 213 are outside the scope of this Draft, but a management information 214 base (MIB) allowing for bindings between local stub links and VPN 215 identities may be one obvious solution. 217 Thereafter, each edge router must learn either the identity of, or, 218 at least, the router to, each other edge router supporting other stub 219 links in that particular VPRN. Implicit in the latter is the notion 220 that there exists some mechanism by which the configured edge routers 221 can then use this edge router and/or stub link identity information 222 to subsequently set up the appropriate tunnels between them; this is 223 discussed further below. 225 In order to configure each stub link with the identity of the VPN to 226 which it belongs, some form of VPN identifier is required; the scope 227 of uniqueness of this identifier is a function of its usage, which is 228 related to how VPRN membership is disseminated. This problem, of 229 VPRN member dissemination between participating edge routers, can be 230 solved in a variety of ways: 232 A. Directory Lookup: 234 The members of a particular VPRN, that is, at a minimum, the identity 235 of the edge routers supporting stub links in the VPRN, and possibly 236 also the identity of each of the stub links, could be configured into 237 a directory, which edge routers could query, using some defined 238 mechanism (e.g. LDAP), upon configuration of their local stub 239 interfaces and VPN identifier. The latter, in this case, need only be 240 unique within the scope of the directory. 242 This mechanism allows for authorization checking prior to 243 disseminating VPRN membership information, which may be desirable 244 where VPRNs span multiple administrative domains. In such a case, 245 directory to directory protocol mechanisms could also be used to 246 propagate authorized VPRN membership information between the 247 directory systems of the multiple administrative domains. 249 There would also need to be some form of database synchronization 250 mechanism (e.g. triggered or regular polling of the directory by edge 251 routers, or active pushing of update information to the edge routers 252 by the directory) in order for all edge routers to learn the identity 253 of newly configured sites inserted into an active VPRN. 255 B. Explicit Management Configuration: 257 A VPRN Management Information Base (MIB) could be defined which would 258 allow a central management system to configure each edge router with 259 the identities of each other participating edge router and possibly 260 also the identity of each of the stub links. Similar mechanisms 261 could also be used, as noted above, to configure the VPN bindings of 262 the local stub links on the edge router. The scope of the VPN 263 identifier in this case is related to the scope of the management 264 system. 266 Note that this mechanism allows the management station to impose 267 strict authorization control; on the other hand, it may be more 268 difficult to configure edge routers outside the scope of the 269 management system. The management configuration model can also be 270 considered a subset of the directory method, in that the (management) 271 directories could use MIBs to push VPRN membership information to the 272 participating edge routers, either subsequent to, or as part of, the 273 local stub link configuration process. 275 C. Piggybacking in Routing Protocols: 277 VPRN membership information could be piggybacked into the routing 278 protocols run by each edge router, since this is an efficient means 279 of automatically propagating information throughout the network to 280 other participating edge routers. Specifically, each route 281 advertisement by each edge router could include, at the minimum, the 282 set of VPN identifiers associated with each edge router, and adequate 283 information to allow other edge routers to determine the identity of, 284 and/or, the route to, the particular edge router. Other edge routers 285 would examine received route advertisements to determine if any 286 contained information relevant to a supported (i.e. configured) VPRN; 287 this determination could be done by looking for a VPN identifier 288 matching a locally configured VPN. The nature of the piggybacked 289 information, and related issues, such as scoping, and the means by 290 which the nodes advertising particular VPN memberships will be 291 identified, will generally be a function both of the routing protocol 292 and of the nature of the underlying transport, and is discussed 293 further below. 295 The advantage of this last scheme is that it allows for very 296 efficient information dissemination, particularly across multiple 297 routing domains (e.g. across different autonomous systems/ISPs) but 298 it does require that all nodes in the path, and not just the 299 participating edge routers, be able to accept such modified route 300 advertisements. Significant administrative complexity may also be 301 required to configure scoping mechanisms so as to both permit and 302 constrain the dissemination of the piggybacked advertisements. 304 Furthermore, unless some security mechanism is used for routing 305 updates so as to permit only all relevant edge routers to read the 306 piggybacked advertisements, this scheme generally implies a trust 307 model where all routers in the path must perforce be authorized to 308 know this information. Depending upon the nature of the routing 309 protocol, piggybacking may also require intermediate routers, 310 particularly autonomous system (AS) border routers, to cache such 311 advertisements and potentially also re-distribute them between 312 multiple routing protocols. 314 Each of the schemes described above have merit in particular 315 situations. The earlier Draft [Heinanen] discussed the last scheme 316 only, and that is further spelled out below, but the other two 317 schemes may also offer important practical advantages. In 318 particular, note that, in practice, there will almost always be some 319 directory or management system which will maintain VPN membership 320 information, since, as noted above, the binding of VPNs to stub links 321 must be configured, hence, presumably, such information would be 322 obtained from, and stored within, some database. Hence the 323 additional steps to facilitate the configuration of such information 324 into edge routers, and/or, facilitate edge router access to such 325 information, may not be excessively onerous. These methods will be 326 discussed in greater detail in forthcoming Drafts. 328 5.1.1 VPN Identifier 330 A principal benefit of the router piggybacking model is that it 331 allows for simple dissemination of VPN membership information across 332 multiple ASs. This implies the need for a VPN identifier than can be 333 unique across multiple ASs. To that end, [Heinanen] proposed a 334 globally unique VPN identifier (note that such an identifier may be 335 useful for VPN types other than only VPRNs) made up of the 336 concatenation of an AS number, and a label assigned by the AS 337 administrator which is locally unique within the particular AS. It is 338 proposed that this be adopted as the VPN identifier, with the further 339 stipulation that the VPN ID be coded as a four octet BGP Communities 340 Attribute [Chandra], made up a two octet AS number and a 2 octet, 341 unstructured integer VPN number, to allow for sufficient numbers of 342 VPNs per AS. The specific details of this proposed format are for 343 future clarification. 345 Note that where a VPN crosses multiple ASs, then there must be some 346 administrative mechanisms to coordinate VPN ID assignment e.g. 347 through the notion of a 'home AS' for a particular VPN, which is used 348 in the VPN ID of that VPN. A VPN ID coded as proposed could also be 349 easily piggybacked in BGP, and could also be easily specified within 350 BGP policy filters in AS border routers for scoping and 351 administrative purposes. 353 For the remainder of the discussion, it is assumed that the VPN 354 identifier will be as so described. 356 5.2 Tunneling Mechanisms 358 Once VPRN membership information has been disseminated, the tunnels 359 comprising the VPRN can be constructed. While this can be done 360 through manual configuration, this is clearly not likely to be a 361 scalable solution, given the o(n^2) problem of meshed links. As 362 such, tunnel set up should use some form of signaling protocol which 363 would allow two nodes to construct a tunnel to each other knowing 364 only each other's identity. Note also that there are some tunneling 365 mechanisms which allow for multiple disjoint calls or sessions within 366 the same tunnel - in such a 'shared tunnel' case, the signaling 367 protocol could also be used to assign a call within an existing 368 tunnel between two edge routers for a new VPN between them. 370 There are two specific cases of interest networks running MPLS, and 371 current networks not running MPLS. These are discussed separately. 373 5.2.1 MPLS Networks 375 As noted in [Heinanen], MPLS can be considered to be a form of IP 376 tunneling, since the labels of MPLS packets allow for routing 377 decisions to be decoupled from the addressing information of the 378 packets themselves. MPLS label distribution mechanisms can be used to 379 associate specific sets of MPLS labels with particular VPRN address 380 prefixes supported on particular egress points (i.e. stub links of 381 edge routers) and hence allow other edge routers to explicitly label 382 and route traffic to particular VPRN stub links. The exact 383 relationship of the various MPLS labels and the particular VPN to 384 which they are bound is a function of whether or not the CPE edge 385 routers participate or do not participate in MPLS with the ISP edge 386 routers. These cases are discussed in greater detail below. 388 The principal attraction of MPLS as a tunneling mechanism is that it 389 may require less processing within each edge router than alternative 390 tunneling mechanisms. This is also a function of the fact that data 391 security within a MPLS network is implicit in the explicit label 392 binding, much as with a connection oriented network, such as Frame 393 Relay. This may hence lessen customer concerns about data security 394 and hence require less processor intensive security mechanisms (e.g. 395 IPSec). As discussed below, however, such implicit mechanisms 396 address only some of the potential security concerns of customers. 398 5.2.2 Non-MPLS Networks 400 For non-MPLS networks, VPNs in general require the use of an explicit 401 IP tunneling mechanism. There are numerous IP tunneling mechanisms, 402 including IP/IP [Simpson], GRE tunnels [Hanks], L2TP [Valencia] and 403 IPSec [Kent]. Each of these allow for opaque transport of IP 404 packets, with routing disjoint from the address fields of the 405 encapsulated packets. Additional processing is required in edge 406 routers for the use of any of these protocols, with some (e.g. IPSec) 407 mandating significant processing capabilities. On the other hand, 408 such tunneling protocols can provide significantly more comprehensive 409 data security capabilities than the implicit security of MPLS. 411 It is the case, however, that none of the protocols listed above were 412 originally designed to support VPNs of the type under consideration. 413 As such, none provide all of the mechanisms likely to be needed for 414 VPN applications. In particular, only L2TP and IPSec can be 415 considered to have any form of signaling protocol (the L2TP control 416 protocol, and the Internet Key Exchange protocol [Harkins], 417 respectively) which could potentially be used to automate the process 418 of tunnel set up. Furthermore, none of these tunneling protocols have 419 support today for multicast (other than source replication), whereas 420 MPLS does have such support, though the application of MPLS 421 mechanisms to multicast transport within VPNs is not yet fully 422 defined, and requires further study. 424 Given however, the current paucity of operational networks running 425 MPLS, there is likely to be significant value in fully defining a VPN 426 tunneling mechanism which could be deployed in current networks. It 427 may also be possible to readily extend other IP tunneling protocols 428 to incorporate support for multicast. Subsequent Drafts will address 429 these issues. 431 5.3 Stub Link Reachability Information 433 There must be mechanisms to allow ISP edge routers to determine the 434 set of VPN addresses and address prefixes reachable at each stub link 435 connecting to the edge router. There are a number of means by which 436 this can be done: 438 A. Routing Protocol Instance: 440 A routing protocol can be run between the CPE edge router and the ISP 441 edge router to exchange reachability information. Note that this 442 routing exchange is asymmetrical since the CPE router views the ISP 443 edge router as the default path into the VPN. Any suitable routing 444 protocol could be used to exchange routing information between the 445 CPE and ISP edge routers. It should be noted that the only function 446 of this protocol is indeed to exchange reachability information, not 447 to discover topology, since, by definition, there is only a single, 448 point-to-point (logical) link between the CPE router and the ISP edge 449 router, with the latter then discovering (and hiding) the VPN 450 topology. 452 Likely protocols for this purpose include RIPv2, OSPF [Moy] and BGP-4 453 [Rekhter2]. Note that even if the same protocol is used between the 454 CPE and ISP edge routers, and from the ISP edge routers into the 455 core, these will be two quite distinct routing instantiations. If 456 the ISP edge router uses routing protocol piggybacking to disseminate 457 VPN membership and reachability information across the core, then it 458 may redistribute suitably labeled routes from the CPE routing 459 instantiation to the core routing instantiation (but never the other 460 way round). There is no requirement that the same protocol, or even 461 the same CPE reachability information gathering mechanism, be run 462 between each CPE router and associated edge router in a particular 463 VPRN, since this is purely local matter. 465 Note that if a particular customer site concurrently belongs to 466 multiple VPNs (or wishes to concurrently communicate with both a VPN 467 and the Internet), then the ISP edge router must have some means of 468 unambiguously mapping stub link address prefixes to particular VPNs. 469 This could be done either by ensuring (and appropriately configuring 470 the ISP edge router to know) that particular disjoint address 471 prefixes are mapped into separate VPNs, or by tagging the routing 472 advertisements from the CPE edge router with the appropriate VPN 473 identifier. In the case of MPLS, as discussed below, different MPLS 474 labels would be used to differentiate the disjoint prefixes assigned 475 to particular VPNs. In any case, some administrative procedure would 476 be required for this coordination. 478 B. Configuration: 480 The reachability information across each stub link could be manually 481 configured, which may be appropriate if the set of addresses or 482 prefixes is small and static. 484 C. ISP Administered Addresses: 486 The set of addresses used by each stub site could be administered and 487 allocated by the ISP, which may be appropriate for very small sites 488 with little network administration resources. In such a case the ISP 489 edge router could determine these addresses by proxying for the 490 particular address administration mechanism (e.g. DHCP). Note that 491 in this case it would be the responsibility of the ISP to ensure that 492 each site in the VPN received a disjoint address space. 494 D. MPLS Label Distribution Protocol: 496 In cases where the CPE edge router runs MPLS, the MPLS LDP could be 497 extended to convey the set of prefixes at each stub site, together 498 with the appropriate labeling information. While LDP is not 499 generally considered a routing protocol per se, it may be useful to 500 extend it for this particular constrained scenario. This is for 501 further study. 503 5.4 Intra-VPN Reachability Information 505 Once an edge router has determined the set of prefixes associated 506 with each of its stub links, then this information must be 507 disseminated to each other edge router in the VPRN. Note also that 508 there is an implicit requirement that the set of reachable addresses 509 within the VPRN be locally unique that is, each VPRN stub link (not 510 performing load sharing) maintain an address space disjoint from any 511 other, so as to permit unambiguous routing. In practical terms, it 512 is also generally desirable, though not required, that this address 513 space be well partitioned i.e. specific, disjoint address prefixes 514 per stub link, so as to preclude the need to maintain and disseminate 515 large numbers of host routes. 517 The intra-VPN reachability information dissemination can be solved in 518 a number of ways, some of which include the following: 520 A. Directory Lookup: 522 Along with VPN membership information, a central directory could 523 maintain a listing of the address prefixes associated with each end 524 point. Such information could be obtained by the server through 525 protocol interactions with each edge router. Note that the same 526 directory synchronization issues discussed above would apply in this 527 case. 529 B. Explicit Configuration: 531 The address spaces associated with each edge router could be 532 explicitly configured into each other router. This is clearly a 533 non-scalable solution, and also raises the question of how the 534 management system learns such information in the first place. 536 C. Local Intra-VPRN Routing Instantiations: 538 In this approach, each edge router runs an instantiation of a routing 539 protocol (a 'virtual router') per VPRN, running across the VPRN 540 tunnels to each peer edge router, to disseminate intra-VPRN 541 reachability information. The intra-VPN routing advertisements could 542 be distinguished from normal tunnel data packets either by being 543 addressed directly to the peer edge router, or by a tunnel specific 544 mechanism. 546 Note that this intra-VPRN routing protocol need have no relationship 547 with the routing protocols operated by the ISPs in the path. 548 Specifically, the intra- VPRN routing protocol operates as an overlay 549 over the IP backbone, and, given the very simple meshed topology of 550 the VPRN, could be a very simple protocol, such as RIPv2 [Malkin], at 551 least unless the VPRN spans a very large number of edge routers. 552 Since the intra-VPN routing protocol runs as an overlay, it is also 553 wholly transparent to any intermediate routers, and to any edge 554 routers not within the VPRN. This also implies that such routing 555 information can also remain opaque to such routers, which may be a 556 necessary security requirements in some cases. 558 D. Link Reachability Protocol 560 Each edge router could run a link reachability protocol - for 561 instance, some variation of the MPLS LDP - across the tunnel to each 562 peer edge router in the VPRN, carrying the VPN ID and the 563 reachability information of each VPRN running across the tunnel 564 between the two edge routers. Such a protocol would need to be 565 specified, and would require aspects of current routing protocols 566 such as hello protocols, and re-transmit timers and/or positive 567 acknowledgements. However, such an approach may reduce the 568 processing burden of running routing protocol instantiations per 569 VPRN, and may be of particular benefit where a shared tunnel 570 mechanism is used to connect a set of edge routers supporting 571 multiple VPRNs. 573 E. Piggybacking in Routing Protocols: 575 As with VPN membership, the set of address prefixes associated with 576 each stub interface could also be piggybacked into the routing 577 advertisements from each edge router and propagated through the 578 network. Other edge routers would extract this information from 579 received route advertisements in the same way as they would obtain 580 the VPRN membership information (which, in this case, is implicit in 581 the identification of the source of each route advertisement). Note 582 that this scheme may require, depending upon the nature of the 583 routing protocols involved, that intermediate routers e.g. border 584 routers cache intra-VPRN routing information in order to propagate it 585 further. This also has implications for the trust model, and for the 586 level of security possible for intra-VPRN routing information. 588 Note that in any of the cases discussed above, an edge router has the 589 option of disseminating its stub link prefixes in a manner so as to 590 permit tunneling from remote edge routers directly to the egress stub 591 links. Alternatively, it could disseminate the information so as to 592 associate all such prefixes with the edge router, rather than with 593 specific stub links. In this case, the edge router would need to 594 implement a VPN specific forwarding mechanism for egress traffic, to 595 determine the correct egress stub link. The advantage of this is 596 that it may significantly reduce the number of distinct tunnels or 597 tunnel label information which need to be constructed and maintained. 598 Note that this choice is purely a local manner and is not visible to 599 remote edge routers. 601 The earlier Draft [Heinanen] discussed the last scheme only, and that 602 is further spelled out below. A number of vendors have already 603 announced, however, their intention to support variants of the 604 virtual router scheme, which is also less disruptive to currently 605 deployed routing protocols. As such, this scheme merits further 606 investigation and will be addressed in future Drafts. 608 6. Routing Protocol Piggybacking 610 As noted above, routing protocol piggybacking could be used to carry 611 VPN membership information alone, or also VPN reachability 612 information. The means by which this is done, and the nature of the 613 piggyback information, is a function both of the particular routing 614 protocol, and of the underlying network mechanism. The particular 615 cases of OSPF and BGP-4 are discussed below. 617 6.1 OSPF 619 OSPF is often used as an intra-AS routing protocol, and hence may be 620 a required candidate for routing protocol piggybacking. One means by 621 which VPN membership and reachability information could be 622 piggybacked is through the use of the proposed OSPF opaque LSA 623 [Coltun]. The exact details of how such a piggybacking advertisement 624 might be coded are for further study. In particular, it may prove to 625 be the case that opaque LSAs could be well suited for piggybacking 626 VPN membership information, but not VPN reachability information, 627 since opaque LSAs, at least as currently defined, are attributes of, 628 not indexes into, reachability information. Using them in the latter 629 manner, which would be required to piggyback VPN reachability 630 information, may break some existing OSPF implementations. Opaque 631 LSAs do, however, have a well defined scoping mechanism, that, at 632 least within an AS, allows for control over the extent of 633 dissemination of a VPN advertisement. 635 Note also that as a link state protocol OSPF advertisements always 636 allow for the identification of the source of an advertisement. 637 However, each router in the OSPF network, and not only edge routers, 638 will also need to examine received advertisements, and explicitly 639 ignore piggybacked VPN advertisements, unless configured to be a VPN 640 terminator (i.e. edge router). 642 6.2 BGP-4 644 There are a number of potential mechanisms by which VPN information 645 could be piggybacked into BGP-4, including the Multiprotocol 646 Extensions attribute [Bates] or the BGP communities attribute. In 647 the case where VPN reachability information is piggybacked, each VPN 648 address prefix could be encoded as Network Layer Reachability 649 Information (NLRI) and bound to the VPN identifier as a community 650 attribute, if the VPN ID has the format proposed previously. Note 651 that in cases where it was desired only to advertise VPN membership 652 information, then advertising each VPN prefix may be onerous and 653 undesirable, but there is no specific mechanism in BGP-4, as yet, to 654 advertise anything other than NLRI. 656 In the case where this is done on an MPLS network, then the 657 advertisement would carry each VPN prefix, together with the MPLS 658 label(s) to be used to send packets to that stub link. As noted 659 above, these labels, as a purely local matter, could identify either 660 the route to each stub link, or only to the edge router itself, which 661 would then use its own forwarding mechanisms for egress packets. 663 Since there is already defined a particular mechanism for carrying 664 MPLS labels in BGP-4 using the Multiprotocol Extensions field 665 [Rekhter3], this would suggest that this mechanism should be 666 generalized for the purpose also of conveying VPN information; hence 667 it is proposed that that Draft be amended for this purpose. 669 The use of BGP-4 for VPN piggybacking is more complex in cases where 670 this is done on non-MPLS networks. In such a case, the piggybacked 671 advertisements must allow for the explicit identification of the 672 source of the advertisement. This is important for tunnel set up in 673 non-MPLS networks, where each edge router needs to know the identity 674 (i.e. IP address) of each of the other edge routers, in order to 675 initiate whatever signaling mechanism may be used for tunnel set-up. 677 At present there is no means by which the original source of a BGP 678 advertisement can be identified once that advertisement is 679 redistributed (e.g. from an intra-AS protocol like OSPF into BGP at a 680 border node, or from an edge router through a border router for 681 distribution outside the original AS). Since VPN support in non-MPLS 682 networks is an important requirement, it is proposed that whatever 683 BGP-4 mechanism is chosen for the purpose of VPN advertisements also 684 be amended to allow for explicit tagging with the IP address of the 685 original source of the advertisement. One possible means by which 686 this could be done may be to associate the VPN ID (coded as a 687 Community Attribute) with the /32 prefix (i.e. IP address) of the 688 edge router supporting the VPN. This issue is for further study. 690 Note that in the case where BGP advertisements are propagated across 691 AS boundaries, then each border router must cache the full set of 692 prefixes and associated label stacks of each advertised VPN. In such 693 a case, further work is also needed to control scoping of BGP 694 piggybacked advertisements. In particular, at AS boundaries, border 695 routers would generally need to be manually configured with VPN route 696 advertisement policies to determine whether such advertisements 697 should be propagated, and, if so, to which peer ASs. In general ASs 698 will also likely automatically reject VPN advertisements received 699 from peer ASs unless specifically configured to pass them. Some 700 administrative mechanism (e.g. manual procedures or some form of 701 directory communication, for instance) would be needed for this 702 purpose. 704 Note also that such scoping policy configurations would be needed not 705 only in each border router of each AS with one or more VPN 706 termination points, but also in each AS in the transit path between 707 them. This last may pose problems if the trust system includes the 708 terminating ASs, but excludes one or more of the transit ASs. These 709 problems expose a particular artifact of router piggybacking - while 710 VPN membership and reachability information is relevant only to the 711 particular edge routers concerned, router piggybacking necessarily 712 requires also the active participation of all intermediate routers 713 that need to process and propagate such advertisements. This may 714 impose significant burdens on the operation and administration of 715 such intermediate routers, as well as compromising the integrity of 716 the VPNs concerned. 718 7. MPLS Mappings 720 The earlier Draft [Heinanen] proposed a number of mechanisms for 721 facilitating VPN set up in MPLS networks. As noted above, most of 722 these mechanisms are subsets of more generic VPN mechanisms, and some 723 of the alternate mechanisms described above can also be applied to 724 MPLS networks. There are specific issues with respect to mappings 725 into MPLS networks due to the nature of the particular control and 726 data planes of MPLS. Furthermore, the operation of these data and 727 control planes is a function of whether or not the CPE router also 728 runs MPLS. These cases are considered separately. 730 7.1 CPE Router Runs MPLS 732 In this case the CPE router and ISP edge router exchange, using one 733 of the mechanisms discussed above, the set of address prefixes 734 associated with that stub site and then, concurrently or 735 subsequently, assign MPLS labels to each such prefix. Note that, as 736 discussed above, the edge router could decide, as a local matter, to 737 assign the same label to each such stub link, or distinct labels to 738 each, depending upon whether or not it wished to explicitly forward 739 egress packets. 741 If a CPE routers belongs concurrently to more than one VPN, then it 742 must label the (disjoint) prefixes of each VPN differently, to allow 743 for unambiguous routing at the edge router. Thereafter, the ISP edge 744 router uses whatever routing and label assignment mechanisms may be 745 used within its network to disseminate the prefixes, tagged with the 746 appropriate VPN ID, and the locally assigned MPLS label, to each 747 other peer Label Switching Router (LSR). 749 In the specific case where BGP-4 is used for piggybacking across the 750 core network, this implies that each edge router and border router in 751 the AS but not the intermediate LSRs - will receive the bindings of 752 VPN IDs, VPN prefixes and associated labels, together with the label 753 needed to forward traffic to the particular edge router from its BGP 754 peers. If border routers were to propagate this information further 755 across the core, they would then push into this label stack, 756 information to identify the explicit tunnel route to the particular 757 border router from its peer border routers. At a terminating edge 758 router, the edge router would maintain in its VPN specific Label 759 Information Base (LIB), the mappings of particular VPN prefixes to 760 the label stacks associated with each prefix. Note that in this 761 case, edge routers will know, and need know, only the route (i.e. 762 MPLS label stack) to each VPN prefix, and will not know the identity 763 of the edge router through which that prefix is reached. 765 Each edge router may also advertise, using either LDP or a 766 piggybacked routing protocol, a default label to be used by the CPE 767 across its stub links to send data into the VPN, unless this binding 768 was implicit (e.g. all traffic from a stub link only gets sent to one 769 particular VPN). 771 Note that all of these label stacks are disjoint from the labels used 772 for connectivity between the edge and border routers, through the 773 intermediate LSR within the AS MPLS network. This level of intra-AS 774 connectivity is a lower level than the BGP peering level; hence, 775 disjoint MPLS label allocation mechanisms (e.g. LDP following prefix 776 distribution using an intra-AS routing protocol) would be used to 777 determine connectivity to, and the appropriate label stacks for, edge 778 and border router connectivity across the AS. 780 Hence an edge or border router wishing to transmit to a particular 781 VPN stub link would need to first determine the destination VPN 782 prefix, and the VPN label stack associated with that prefix. 783 Subsequently, it would then determine the label switched path (LSP) 784 to the particular destination edge router, push the resultant label 785 stack onto the VPN label and transmit the packet. At the destination 786 edge router, the intra-AS routing label stack would be popped, and 787 the packet sent to the appropriate stub link using either the VPN 788 label, if explicitly tagged, or using a local forwarding mechanism, 789 if not. 791 7.2 CPE Router Does Not Run MPLS 793 This case would work exactly as described above, except that the ISP 794 edge router would proxy for the CPE router by assigning labels to 795 each CPE prefix. Packets sent to the stub link would be routed as 796 described above, except that at the destination edge router the label 797 stack would be removed and an untagged packet sent to the CPE router. 798 In this case, the edge router would also need some unambiguous means 799 of determining the destination VPN, where a particular stub site 800 supports multiple VPNs. Typically this will require disjoint address 801 spaces in each VPN. 803 Note that in either case that all border routers will need to 804 maintain label mappings for all prefixes associated with each VPN in 805 the AS. This is a consequence of the fact that BGP can, at present, 806 only advertise routes to particular NLRI prefixes and hence, cannot, 807 as discussed above, advertise only VPN to edge router bindings. It is 808 also, of course, obvious, that such information cannot in any sense 809 be aggregated. 811 7.3 Use of RSVP in MPLS Networks 813 There have been a number of proposals to use the Resource Reservation 814 Protocol (RSVP) to allocate labels within MPLS networks, either for 815 the purpose of setting up flow specific LSPs [Davie] or for 816 administrating traffic engineered tunnels across multiple ASs, as in 817 the PASTE proposal [Li]. In either case, VPN membership and, perhaps 818 also VPN reachability information, could be carried using such RSVP 819 based label allocation mechanisms, as with the use of the LDP, 820 described above. In particular, in the case of the PASTE proposal, 821 RSVP is used to set up and administer traffic engineered tunnels that 822 span potentially multiple service provider domains, and provide non- 823 default path forwarding. In such a case, router piggybacking may not 824 be possible, and hence RSVP may be the only protocol available in 825 which to piggyback VPN advertisements. This subject is for further 826 study. 828 8. Security Considerations 830 As noted above, VPN operation on MPLS networks relies upon the 831 implicit security of explicitly labeled LSPs. Unless a particular 832 edge router has been configured for membership into a particular VPN, 833 then no CPE router connected to that edge router should be able to 834 insert traffic into that VPN. Note, however, that this is only true 835 if each edge router in the network, and not just those participating 836 in the VPN, ensures that no CPE router can transmit packets with 837 label information that may cause it to be inserted, at some merge 838 point, into a LSP leading to the labeled VPN. As such, the trust 839 model for MPLS based VPNs must encompass all MPLS edge routers, and 840 not only those participating in the particular VPN. 842 The particular form of data security offered by MPLS based VPNs also 843 does not address other potential security concerns e.g. data 844 snooping, non- repudiation, etc. Such concerns can only be met 845 through more explicit security mechanisms e.g. IPSec. As noted 846 earlier, such mechanisms are required for any tunneling mechanism 847 operating on non-MPLS networks where paths are not explicitly 848 labeled. Note, however, that such security mechanisms - e.g. 849 bilateral IPSec peerings between two edge routers in a VPN - have the 850 advantage that the trust model need only include the relevant edge 851 routers, and not any of the intermediate routers (or administrative 852 domains). 854 Particular VPN configuration mechanisms have their own security 855 issues. In particular, piggybacking of VPN membership and routing 856 information in routing protocols would potentially expose such 857 information to all intermediate routing nodes. This may be a 858 particular issue where this mechanism is used to distribute VPN 859 information across multiple ASs or ISPs. Mechanisms to address this 860 problem may be worthy of study e.g. the use of encryption and 861 authentication mechanisms to protect such piggybacked information, 862 with the use of key distribution mechanisms to restrict access only 863 to trusted edge routers. 865 9. Intellectual Property Considerations 867 Cisco Systems has claimed potential intellectual property rights to 868 certain aspects of the mechanisms discussed in the earlier Draft, and 869 referred to here. Refer to [Heinanen] for the specific disclosure 870 notice. The nature, extent and impact of these claims are unknown to 871 the present authors. 873 10. Acknowledgements 875 Thanks to Tony Li, of Juniper Networks, for his helpful review and 876 feedback and to Anthony Alles, of Shasta Networks, for his assistance 877 in the generation of this Draft. 879 11. References 881 [Bates] Bates, T. "Multiprotocol Extensions for BGP-4", RFC 2283. 883 [Callon] Callon, R., et al "Multiprotocol Label Switching 884 Architecture", draft-ietf-mpls-arch-02.txt. 886 [Chandra] Chandra, R. and Traina, P. "BGP Communities Attribute", 887 RFC 1998. 889 [Coltun] Coltun, R. "The OSPF Opaque LSA Option", RFC 2370. 891 [Davie] Davie, B., et al - "Use of Label Switching with RSVP", 892 draft-ietf-mpls-rsvp-00.txt 894 [Hanks] Hanks, S., et al "Generic Routing Encapsulation over Ipv4 895 Networks", RFC 1702. 897 [Harkins] Harkins, D. and Carrel, D. "The Internet Key Exchange 898 (IKE)", draft-ietf-ipsec-isakmp-oakley-08.txt. 900 [Heinanen] Heinanen, J. and Rosen, E. "VPN Support with MPLS" 901 draft-heinanen-mpls-vpn-01.txt. 903 [Kent] Kent, S. and Atkinson, R. "Security Architecture for the 904 Internet Protocol", draft-ietf-ipsec-arch-sec-06.txt. 906 [Li] Li, T. and Rekhter, Y. - "Provider Architecture for 907 Differentiated Services and Traffic Engineering (PASTE)", draft-li- 908 paste-00.txt. 910 [Malkin] Malkin, G. "RIP Version 2 Carrying Additional 911 Information", RFC 1723. 913 [Moy] Moy, J. "OSPF Version 2", RFC 2328. 915 [Rekhter1] Rekhter, Y., et al "Address Allocation for Private 916 Internets", RFC 1918. 918 [Rekhter2] Rekhter, Y. and Li, T. "A Border Gateway Protocol 4 919 (BGP-4)", RFC 1771. 921 [Rekhter3] Rekhter, Y. and Rosen, E. "Carrying Label Information in 922 BGP-4", draft-ietf-mpls-bgp4-mpls-00.txt. 924 [Simpson] Simpson, W. "IP in IP Tunneling", RFC 1853. 926 [Valencia], Valencia, A., et al "Layer Two Tunneling Protocol 927 "L2TP"", draft-ietf-pppext-l2tp-11.txt. 929 11. Author Information 931 Juha Heinanen 932 Telia Finland, Inc. 933 Myyrmaentie 2 934 01600 VANTAA 935 Finland 936 Tel: +358 303 944 808 937 Email: jh@telia.fi 939 Bryan Gleeson 940 Shasta Networks 941 249 Humboldt Court 942 Sunnyvale CA 94089-1300 943 USA 944 Tel: +1 (408) 548 3711 945 Email: bgleeson@shastanets.com 947 Arthur Lin 948 Shasta Networks 949 249 Humboldt Court 950 Sunnyvale CA 94089-1300 951 USA 952 Tel: +1 (408) 548 3788 953 Email: alin@shastanets.com