idnits 2.17.1 draft-touch-l3vn-arch-00.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: ---------------------------------------------------------------------------- ** 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 Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 13 instances of too long lines in the document, the longest one being 9 characters in excess of 72. 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) -- Looks like a reference, but probably isn't: 'RFC 1918' on line 435 -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Downref: Normative reference to an Informational RFC: RFC 3022 (ref. '10') -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' ** Obsolete normative reference: RFC 1771 (ref. '14') (Obsoleted by RFC 4271) -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '17' ** Obsolete normative reference: RFC 2401 (ref. '18') (Obsoleted by RFC 4301) Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Joe Touch 3 draft-touch-l3vn-arch-00.txt Lars Eggert 4 Yu-Shun Wang 5 USC/ISI 6 Jun. 2002 7 Expires: Dec. 2002 9 An Architecture for Layer 3 Virtual Networks 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026 except for the right to 15 produce derivative works. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 To view the list Internet-Draft Shadow Directories, see 30 http://www.ietf.org/shadow.html 32 Abstract 34 This document describes an architecture for layer 3 (IP) virtual 35 networks. Virtual networks consist of virtual hosts and virtual 36 routers connected by virtual links (tunnels) just like a real 37 network. The focus of this draft is to extend the current Internet 38 architecture to support virtual networks. 40 1. Introduction 42 This document describes an architecture for layer 3 (IP) virtual 43 networks. Layer 3 virtual networks use only layer 3 protocols to 44 provide layer 3 connectivity within each virtual network. Virtual 45 networks consist of virtual hosts and virtual routers connected by 46 virtual links (tunnels). The architecture is based on the current 47 Internet architecture with some extensions and techniques required to 48 support virtual networks. The components in this architecture are 49 also examined against the current Internet standards. 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC 2119. 55 1.1 Concepts of Virtual Networks 57 The concepts and purposes of virtual networks in a physical network 58 are the same as virtual memory [1] in computer systems: 60 - Provide an abstract view of their real counterparts to 61 applications. 62 - Allow concurrent sharing of the physical resources among 63 multiple applications. 64 - Ensure isolation among different virtual entities. 66 Virtual networks are constructed by linking nodes with tunnels, which 67 encapsulates packets inside virtual networks with additional headers. 68 One feature unique to virtual networks is the capability to bypass 69 nodes not in the virtual networks. This property led to the early 70 adoption of virtual networks to incrementally deploy new protocols 71 such as multicast [2] and IPv6 [3]. It also enabled the recent 72 commercial deployment of virtual private networks (VPN) [4], and the 73 proliferation of peer-to-peer networks [5]. 75 1.2 Virtual Private Networks 77 Virtual Private Network (VPNs) are an important subset of virtual 78 networks. By tunneling the traffic, virtual networks provide 79 isolation among traffic belong to different virtual networks, also 80 between virtual networks and the underlying Internet. But tunneling 81 alone does not provide security. Other security mechanisms and 82 protocols, such as encryption, authentication, access control, and 83 policy management must be used to secure the nodes and traffic in 84 virtual networks. 86 This document does not discuss security measures and policy 87 management for virtual private networks. While they will certainly 88 influence how a virtual network is provisioned and managed, they 89 really should not affect the architecture of the virtual network. A 90 good virtual Internet architecture should be able to use existing 91 Internet mechanisms to achieve security. The modifications should not 92 exceed the changes made to the current Internet to accommodate 93 security. 95 1.3 Types of Virtual Networks - Open, Close, & Router Cloud 97 As with the real network, a "close" virtual network confines the 98 traffic to within the virtual network. An "open" virtual network 99 allows communications between nodes inside the virtual network with 100 nodes outside, either in another virtual network or in the underlying 101 Internet. Using virtual networks as router clouds is the third 102 category between "open" and "close". In this case, the virtual 103 network really acts like a transit network for packets from the 104 outside. 106 Normally, virtual networks are designed to be closed for isolation or 107 security purposes. The use of tunnel encapsulation also prevents 108 direct communication between the virtual network and the underlying 109 physical network. For packets passing through the virtual network as 110 a transit, it is sufficient to encapsulate them with the extra header 111 to direct these packets to their exit points in the virtual network. 112 For packet exchange between a node inside a virtual network and a 113 node in the real network, the boundary nodes need to perform NAT-like 114 operations to transform packets crossing the boundary. 116 2. Architecture of Virtual Networks 118 This section describes the architecture and components of layer 3 119 virtual networks. 121 2.1 Virtual Networks 123 The architecture of the layer 3 virtual networks is very simple, and 124 is the same as the real network. The architecture is defined below: 126 A virtual network consists of virtual hosts and virtual routers 127 connected by virtual links (tunnels) in an arbitrary topology. 128 Virtual hosts and virtual routers are RFC-conformant hosts and 129 routers inside a virtual network. While the Internet runs (mostly) 130 over layer 2 links, a layer 3 virtual network runs over layer 3 131 tunnels, uses only layer 3 protocols to provide layer 3 132 connectivity. 134 2.2 Virtual Hosts 136 Virtual hosts, like their real counterparts, are either packet 137 sources or sinks, but never packet transits inside a virtual network. 138 Virtual hosts MUST conform to the Internet Host Requirements [6][7]. 139 A virtual host can be located inside a real multihomed host or a 140 router in the underlying real network as discussed below. 142 2.2.1 Virtual Hosts in Multihomed Hosts 144 When a virtual host is inside a real host, the host becomes 145 multihomed because it has one host (home) for the real network and at 146 least another host (home) in the virtual network. 148 RFC 1122 specified two models for multihomed hosts: Strong End System 149 (ES) Model and Weak ES Model. The Strong ES model states that the 150 destination address of an incoming packet MUST match the address of 151 the physical interface through which it is received, and an outgoing 152 packet must be sent through the interface that corresponds to the 153 source address of the packet. The models are updated to include 154 virtual interfaces associated with tunnels in a virtual network in 155 addition to physical interfaces. 157 A multihomed host SHOULD follow the Strong ES model instead of the 158 Weak ES Model to ensure the isolation of the traffic in a virtual 159 network from those of the underlying network and other virtual 160 networks. 162 The multihomed host architecture also supports a host participating 163 in more than one virtual network. There might be administrative 164 reasons not to do so, but the architecture supports it. 166 Another requirement regarding multihomed hosts is the capability to 167 "route" outbound packets among the "homes". This also implies that a 168 multihomed host MUST be able to forward packets like a router. It 169 doesn't mean a multihomed host needs to run routing protocols like a 170 real router, but it must conform to the Router Requirements [8][9] 171 regarding packet forwarding operations. 173 2.2.2 Virtual Hosts in Real Routers 175 As described in Section 1.3, when a virtual network is open or acts 176 as a transit network, routers could act as virtual hosts inside a 177 virtual network. There are three possible communication patterns 178 depending on the entities involved and the type of virtual networks: 180 1. Virtual networks as transit clouds: 182 In this case, the edge nodes of the virtual network will 183 encapsulate the incoming packets from the real network with 184 additional headers to send them through the virtual network to 185 their corresponding exit points. Note that the real source and 186 destination are hidden from the nodes in the virtual network. 187 These packets appear to originate from one such edge node and 188 destined to another edge node. Though those edge nodes are 189 routers in the real network, they act as packet sources and 190 sinks inside the virtual networks. As far as the virtual 191 network is concerned, they really are just virtual hosts. 193 2. Communication between virtual network and physical network: 195 This requires the edge nodes between the virtual network and 196 the physical network to perform a NAT-like [10] operation on the 197 packets crossing the boundary to "elevate" or "transform" the 198 packets into the virtual network space. But to the virtual 199 network, those packets effectively originated from and destined 200 to those edge nodes, which makes them just like hosts in the 201 virtual network. 203 3. Inter virtual network communication 205 Strictly speaking, the edge nodes in this case are not virtual 206 hosts, but should be virtual routers. They perform the same 207 functionality as the border routers of the Internet AS's, 208 exchanging routing information among different virtual networks, 209 and forwarding packets across the boundary between different 210 virtual networks. 212 Note that this is only possible if the address spaces of the 213 connected virtual networks do not overlap. Otherwise, the 214 edge nodes will need to perform NAT-like translation on 215 packets crossing the boundary, and this will make the edge 216 nodes again behave like virtual hosts in the virtual network. 218 In all the cases, additional mechanisms and protocols are required to 219 handle the dissemination of address and routing information between 220 virtual networks and the physical networks, and the encapsulation and 221 decapsulation of the packets crossing the boundary of virtual 222 networks and the real network. The former can be done using one of 223 the exterior gateway routing protocols, the latter could be 224 implemented as a variation of NAT [10]. But neither should be 225 consider as part of the virtual network architecture because as far 226 as the virtual network is concerned, those mechanisms and protocols, 227 while non-trivial, are nothing more than "applications" using the 228 virtual network (generating and receiving packets). 230 2.3 Virtual Routers 232 Virtual routers are routers inside virtual networks. The fundamental 233 concepts of virtual routers described in this draft are very similar 234 to those described in [11]. Virtual routers work exactly the same way 235 in virtual networks as physical routers do in real networks, which 236 means they must also conform to the Internet router requirements 237 [8][9] except some constraints regarding the use of virtual links 238 instead of physical ones, and containment and isolation of the 239 routing information among virtual networks and between virtual 240 networks and the underlying physical networks. 242 The main functionality of virtual routers is to forward packets 243 inside a virtual network. The dissemination of reachability 244 information and the construction of the routing table can be achieved 245 either by static manual configurations or by running dynamic routing 246 protocols inside the virtual network. Like the real network, the 247 exchange of routing information in the case of dynamic routing 248 protocols must be limited within the boundary of a virtual network. 249 Any exchange crossing the boundary of virtual networks and real 250 networks must be treated with extreme care and can only be done when 251 the address spaces of different virtual networks do not overlap. 253 The main difference between a virtual router and a physical router is 254 the links they operate on. For virtual routers, links in a virtual 255 networks are actually point-to-point tunnels in the underlying 256 network. The dynamic routing protocols chosen for virtual networks 257 must be able to exchange routing information using the tunnels. This 258 would ensure the isolation and containment of the routing information 259 among different virtual networks and also the real network. For 260 routing protocols with special requirements regarding the properties 261 of the links, e.g., broadcast vs. point-to-point media, specific link 262 layer protocols, etc., the tunneling mechanisms might limit the 263 choice of routing protocols used in a virtual network. 265 2.4 Virtual Links 267 Virtual links are links among different (virtual) nodes in a virtual 268 network. Virtual links are often implemented as point-to-point 269 tunnels encapsulating packets with extra header(s). This is different 270 from physical links with broadcast media. The implication is that 271 some protocols, like multicast, might not work over virtual links 272 because they assume certain link properties. 274 2.5 End-to-End vs. Router-Cloud/Transit Virtual Networks 275 End-to-end virtual networks are virtual networks that extend to the 276 hosts, while router-cloud or transit-net virtual networks stop at the 277 edge routers. As described in Section 2.2.2, the router-cloud model 278 is actually a special case of the end-to-end virtual network in which 279 the virtual hosts sit inside real routers and the packets from the 280 real hosts will be converted when entering (encapsulation) and 281 leaving (decapsulation) the virtual network. Within the virtual 282 network, the source and destination addresses of the real hosts are 283 hidden from the virtual routers. As far as the virtual network is 284 concerned, edge routers are acting like sources and sinks of packets 285 inside the virtual network. 287 An alternative view of the router cloud model is to include the real 288 hosts connected from outside the router cloud as part of the virtual 289 network and try to management them altogether. These often result in 290 added complexity to the deployment and management of virtual networks 291 when what is really needed are for the edge nodes (of the virtual 292 network) to exchange reachability information for those hosts using 293 (but not inside) the virtual networks. 295 2.6 Layer "X" VPNs (where X > 1) 297 The following is a discussion of implementing virtual networks in 298 different layers of the network protocol stack. 300 2.6.1 Link Layer (L2) Virtual Networks 302 Different types of link-layer (L2) virtual networks [12] were 303 proposed to provide layer-2 connectivity, (or forward packets based 304 on layer-2 information and incoming links,) across the Internet. 305 While this can certainly be done, there are potential issues 306 regarding this approach: 308 1. Most layer-2 (LAN) protocols have latency bounds. Using LAN 309 protocols over wide area MAY breaks those specifications. 310 There MUST be mechanisms to detect when this will occur and 311 disable the L2 protocols, rather than allow inconsistencies 312 to exist. 314 2. Most LAN protocols assumes broadcast media while most virtual 315 networks use point-to-point tunnels. Some implementations of 316 L2 virtual networks use software copy to emulate broadcast. 317 The problem is that atomicity and ordering of broadcast 318 packets MUST be maintained in such implementations. Otherwise 319 the resulting virtual network is not broadcast-capable, which 320 MUST inhibit L2 protocols that rely on such capability. 322 3. There are no hierarchical structures in the address space of most 323 layer 2 protocols, and often no routing infrastructure and no 324 mechanisms to disseminate address lookup information in wide area 325 for the same reason. This means routing (reachability) and address 326 lookup within such virtual networks require additional protocols 327 and mechanisms. 329 To overcome the issues caused by using layer-2 protocols in an 330 environment they are not designed for, network engineers inevitably 331 have to reinvent many new mechanisms to circumcise those problems and 332 make the resulting frameworks unnecessarily complex. 334 Another issue is security. Most link layer protocols have no security 335 mechanisms, makes it necessary to use additional security mechanisms 336 in higher layers of the protocol stack. While this is not a 337 shortcoming of layer-2 virtual networks, it is an important factor 338 when security is required, e.g., virtual private networks. 340 2.6.2 Network Layer (L3) Virtual Networks 342 Network-layer virtual networks, or layer-3 virtual networks, assume 343 network-layer connectivity, and use only network-layer protocols to 344 provide layer-3 virtual networks. An example is virtual networks 345 constructed by using IP-IP tunnels. 347 Constructing virtual networks over layer 3 protocols have the 348 following advantages over other layers: 350 1. Layer 3 (IP) has global naming and addressing structure. 351 Many virtual networks in layers above L3 actually map their 352 node IDs to L3 addresses. 354 2. Layer 3 has routing protocols in the architecture. This 355 means a layer 3 virtual networks can just use the same 356 routing protocols within themselves. 358 As will be discussed in the next section, many virtual network 359 architectures in other layers often reinvent these functionalities of 360 layer 3. 362 2.6.3 Layer 4 (and above) Virtual Networks 364 The problem with implementing virtual networks on layer 4 to layer 7 365 is that they don't have naming/addressing and routing functionality. 366 An L4 (or L7) virtual network protocol often ends up reinventing 367 these functionalities, usually by either routing on L7 names or 368 providing a separate tag space so L7 names map to L3 addresses. 370 The drawbacks are twofold: 372 1. Reinvented protocols often incompletely recapitulate the 373 discovery of errors, and usually not as well-implemented 374 as the existing L3 protocols. 376 2. Similar functionalities at different layers could interfere 377 with each other, resulting in mis-routing, re-routing, or 378 dead-ends, etc. 380 3. Service 382 This section lists some of the services provided by virtual networks 383 to hosts and routers inside the virtual networks, and at the edge of 384 the virtual networks in the case of virtual networks as transit nets. 386 3.1 Addressing 388 Private IP addresses defined in RFC [13] SHOULD be used inside the 389 virtual network if it is a closed network isolated from the Internet. 390 Addresses assigned to the components within a virtual network must be 391 unique throughout the virtual network, and when communicating with 392 other virtual networks, the scope of uniqueness must be extended to 393 cover all the connected virtual networks. 395 While the isolated nature of virtual networks allows network 396 administrators to re-use real IP addresses in the virtual networks, 397 this will make it difficult or confusing to manage and differentiate 398 routing information for the real network versus the virtual ones when 399 they touch down on the same node(s). 401 3.2 IP Connectivity 403 A virtual network must provide IP connectivity to hosts and routers 404 inside. Packet forwarding must be transparent to the hosts just like 405 in the Internet.` 407 3.3 Routing 409 3.3.1 Within a Virtual Network 411 Inside a virtual network, the construction of routing tables on 412 virtual routers can be done by using static routes and manual 413 configurations, or by using dynamic routing protocols among the 414 virtual routers to exchange the reachability information. 416 No matter which approach is used, it is important to ensure that 417 layer 3 routing must work in a virtual network just as in the base 418 network. Failure of an existing routing mechanism in the virtual 419 network means there are problems in the virtual network architecture. 421 3.3.2 Between Multiple Virtual Networks 423 When the address spaces of multiple virtual networks do not overlap, 424 it is possible to run exterior routing protocols (e.g., BGP [14]) 425 among them to exchange routing information just like inter-AS routing 426 of the current Internet. 428 3.3.3 Between Virtual Networks and the Internet 430 Depending on the type and use of virtual networks, the routing 431 information exchange between a virtual network and the underlying 432 Internet is either out of scope, or no different from the practice of 433 the current Internet. 435 1. Closed virtual networks with private [RFC 1918] addresses: 436 This is often the case when the virtual network is isolated from the 437 underlying network. The intention is to have a "closed" abstract 438 network environment which does not support communication across the 439 boundary of virtual networks and the Internet. 441 2. Open virtual networks with valid Internet addresses: 442 While not a normal way of using virtual networks, virtual networks of 443 this type are the same as autonomous systems (AS's). Just run BGP or 444 other inter-domain routing protocols at the edge of the virtual networks. 446 3. Virtual networks as transit clouds: 447 As discussed in Section 2.2.2, and 2.5, a virtual network in this case 448 becomes a transit domain for the real network. It is necessary to 449 exchange reachability information among all the edge nodes of the 450 virtual network, and between the virtual network and the Internet. 451 Again, this is exactly the same as how routing exchange is done for 452 transit AS's in the Internet. 454 3.4 Security 456 As discussed in Section 1.2, security mechanisms and protocols 457 required to implement VPNs, while very complex and non-trivial to 458 deploy, are orthogonal to the architecture of virtual networks. 460 These security issues are currently being addressed in several IETF 461 working groups regarding the current Internet. Once they are 462 established and standardized, the virtual networks SHOULD be able to 463 utilize them, just like in the Internet. 465 3.5 QoS 467 For a virtual network to support QoS, the components of the virtual 468 network must be able to do the following: 470 1. Virtual routers can assure, enforce, and reserve bandwidth 471 constraints; and, 472 2. Virtual links (tunnels) can reserve and enforce bandwidth 473 requirements. 475 Virtual networks can support QoS to the extend that the components 476 can, and QoS in virtual nets works ONLY if QoS is continuously 477 deployed on all possible underlying network (physical networks, 478 Internet, etc.) paths. This is currently not the case now. QoS is 479 one of the few properties that virtual networks could just bypass the 480 parts of the physical networks that don't support it and still make 481 it work. 483 QoS in virtual networks also assumes that reservations on the 484 underlying network are then served as reservable services to the 485 higher layer virtual network. This kind of QoS mechanism does not 486 exist, though a 2-level variant was proposed [16]. 488 3.6 Multicast 490 Current deployment of multicast relies heavily on the broadcast 491 capability of the LAN protocols in the stub networks. Point-to-point 492 tunnels in the virtual networks break this assumption, and makes it 493 necessary to explicitly specify those tunnels in the multicast 494 routing configurations. 496 3.7 DHCP 498 3.8 MPLS 500 4. Issues 501 4.1 Provisioning 503 Other protocols and mechanisms are required to deploy a virtual 504 network: 506 Required: 508 - Resource discovery 509 - Link (tunnel) configuration 510 - Routing configuration 511 - Address allocation 512 - Membership management 514 Optional: 516 - Security policy management and enforcement 517 - QoS policy management and enforcement 519 4.2 Routing 521 There are situations where tunneling and security protocols interfere 522 with routing protocols within the virtual networks. Please refer to 523 the documents regarding different types of tunneling mechanisms, 524 security protocols, and routing algorithms to resolve the conflicts 525 [17]. 527 4.3 Architectural Components vs. Management Boundary 529 There are hosts and routers, servers and clients in the current 530 Internet architecture. The only place where management entities are 531 used to define network architecture is for inter-domain routing as 532 opposed to intra-domain routing. The same principle applies to 533 virtual networks. While a virtual network may extend cross several 534 administrative domains, same components in different domains still 535 perform the same functions. There is no difference architecture-wise 536 across management boundaries. 538 One example is the current trend [15] in the IETF in defining 539 different frameworks for privider-edge PPVPNs (PE-based PPVPNs) and 540 customer-edge PPVPNs (CE-based PPVPNs). Unless the provider-edge 541 routers behave differently from the customer-edge routers in a 542 virtual network, administrative boundary (or equipment placement) 543 along does not sufficiently define different architectures. 545 5. Security Consideration 547 This draft describes an architecture for virtual networks. Security 548 measures are required if the resulting virtual networks need to be 549 secure [17][18]. 551 Other security consideration are not discussed in this draft. 553 6. Conclusion 555 This draft describes an architecture for layer 3 (IP) virtual 556 networks, the components of virtual networks, and service provided by 557 these virtual networks. 559 Acknowledgments 561 The authors would like to thank the members of the X-Bone and 562 DynaBone projects at USC/ISI for their contributions to the ideas 563 behind this draft, notably Greg Finn and Amy S. Hughes. 565 References 567 [1] Denning, P. J., "Virtual Memory," ACM Computer Surveys, Vol. 2, 568 No. 3, September 1970, pp. 153-189. 570 [2] Eriksson, H., "MBone: The Multicast Backbone," Communications of 571 the ACM, August 1994, pp.54-60. 573 [3] 6-Bone web pages - http://www.6bone.net 575 [4] Scott, C., Wolfe, P., Erwin, M., Virtual Private Networks, 576 O'Reilly & Assoc., Sebastapol, CA, 1998. 578 [5] Oram, A. (Editor), Peer-to-Peer: Harnessing the Benefits of a 579 Disruptive Technology, O'Reilly, Sebastapol CA, 2001. 581 [6] Braden, R. (Editor), "Requirements for Internet Hosts -- 582 Communication Layers", RFC 1122, October 1989. 584 [7] Braden, R. (Editor), "Requirements for Internet Hosts -- 585 Application and Support", RFC 1123, October 1989. 587 [8] Baker, F. (Editor), "Requirements for IP Version 4 Routers," RFC 588 1812, June 1995. 590 [9] Senie, D., "Changing the Default for Directed Broadcasts in 591 Routers," RFC 2644, August 1999. 593 [10] Srisuresh, P., Egevang, K., "Traditional IP Network Address 594 Translator (Traditional NAT)," RFC 3022, January 2001. 596 [11] Knight, P. (Editor) et al., "Network based IP VPN Architecture 597 using Virtual Routers," (work in progress), February 2002. 599 [12] Kompella, K. et al., "Layer 2 VPNs Over Tunnels," (work in 600 progress), June 2001. 602 [13] Rekhter, Y., et al., "Address Allocation for Private Internets," 603 RFC 1918, February 1996. 605 [14] Rekhter, Y., Li, T. (Editors), "A Border Gateway Protocol 4 606 (BGP-4)," RFC 1771, March 1995. 608 [15] Callon, R. (Editor) et al., "A Framework for Layer 3 Provider 609 Provisioned Virtual Private Networks," (work in progress), April 610 2002. 612 [16] Terzis, A., Krawczyk, J., Wroclawski, J., Zhang, L., "RSVP 613 Operation Over IP Tunnels," RFC 2746, January 2000. 615 [17] Touch, J., Eggert, L., "Use of IPsec Transport Mode for Dynamic 616 Routing," (work in progress), June 2002. 618 [18] Kent, S., Atkinson, R., "Security Architecture for the Internet 619 Protocol," RFC 2401, November 1998. 621 Author Information 623 Joe Touch 624 Lars Eggert 625 Yu-Shun Wang 627 Information Sciences Institute 628 University of Southern California 629 4676 Admiralty Way, Suite 1001 630 Marina del Rey, CA 90292-6601 631 USA 632 Phone: +1 310 448-9151 633 Fax: +1 310 448-9300 635 URL: http://www.isi.edu/{touch,larse,yushunwa} 636 Email: {touch,larse,yushunwa}@isi.edu 638 Attribution and Disclaimer 640 Effort sponsored by the Defense Advanced Research Projects Agency 641 (DARPA) and Air Force Research Laboratory, Air Force Materiel Command, 642 USAF, under agreements number F30602-98-1-0200 entitled "X-Bone" and 643 number F30602-01-2-0529 entitled "DynaBone". The views and conclusions 644 contained herein are those of the authors and should not be interpreted 645 as necessarily representing the official policies or endorsements, 646 either expressed or implied, of the Defense Advanced Research Projects 647 Agency (DARPA), the Air Force Research Laboratory, or the U.S. 648 Government. 650 The views and conclusions contained herein are those of the authors and 651 should not be interpreted as necessarily representing the official 652 policies or endorsements, either expressed or implied, of the Defense 653 Advanced Research Projects Agency (DARPA), the Air Force Research 654 Laboratory, or the U.S. Government.