idnits 2.17.1 draft-palet-multi6-scenarios-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 557. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 534. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 541. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 547. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 563), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 44. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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.) -- The document date (July 12, 2004) is 7227 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Palet 3 Internet-Draft M. Diaz 4 Expires: January 10, 2005 C. Olvera 5 A. Vives 6 Consulintel 7 E. Fleischman 8 Boeing 9 D. Lanciani 10 July 12, 2004 12 Analysis of IPv6 Multihoming Scenarios 13 draft-palet-multi6-scenarios-00.txt 15 Status of this Memo 17 This document is an Internet-Draft and is subject to all provisions 18 of section 3 of RFC 3667. By submitting this Internet-Draft, each 19 author represents that any applicable patent or other IPR claims of 20 which he or she is aware have been or will be disclosed, and any of 21 which he or she become aware will be disclosed, in accordance with 22 RFC 3668. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at http:// 35 www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on January 10, 2005. 42 Copyright Notice 44 Copyright (C) The Internet Society (2004). All Rights Reserved. 46 Abstract 48 Multihoming seems to be one of the key pieces for the deployment of 49 IPv6 in the enterprise scenario, but is becoming a frequent 50 requirement in all kinds of networks. In addition, other factors 51 including the deployment of broadband networks, the increase in the 52 variety of access technologies, the increase in the demand for 53 resilience/redundancy, etc., in non-enterprise environments, for 54 example in SOHO/home, necessarily imply the increase of IPv6 55 multihoming demand for a number of scenarios, which are described in 56 this memo. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Multihoming Motivations . . . . . . . . . . . . . . . . . . . 3 62 2.1 Technical motivations . . . . . . . . . . . . . . . . . . 3 63 2.2 Non-technical motivations . . . . . . . . . . . . . . . . 4 64 3. Multihoming Scenarios . . . . . . . . . . . . . . . . . . . . 4 65 3.1 Internet Service Provider (ISP) . . . . . . . . . . . . . 4 66 3.2 IX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.3 Enterprise . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.4 University/Campus . . . . . . . . . . . . . . . . . . . . 6 69 3.5 Security, Defense and Emergency . . . . . . . . . . . . . 6 70 3.6 SOHO and Home . . . . . . . . . . . . . . . . . . . . . . 7 71 3.7 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 3.8 Add-hoc . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 3.9 Mesh . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 4. Special Services and Applications within the Multihoming 75 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 4.1 GRIDs and other temporary networks . . . . . . . . . . . . 9 77 4.2 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 4.3 Multihomed devices . . . . . . . . . . . . . . . . . . . . 9 79 4.4 Renumbering . . . . . . . . . . . . . . . . . . . . . . . 9 80 4.5 Real Time Traffic . . . . . . . . . . . . . . . . . . . . 9 81 4.6 Specific protocols/applications . . . . . . . . . . . . . 10 82 4.7 Others . . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 85 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 86 8. Informative References . . . . . . . . . . . . . . . . . . . . 10 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 88 Intellectual Property and Copyright Statements . . . . . . . . 13 90 1. Introduction 92 The term multihoming refers to the practice of having a network 93 connected to more than one ISP (connectivity provider, transit 94 provider, upstream provider, etc.). 96 A device can also be multihomed (e.g. host-centric multihoming), 97 when it has more than one interface, and each of the interfaces is 98 attached to different networks (may be within a multihomed network). 100 In addition to that, in IPv6, each interface can have multiple 101 addresses, which also means than even with a single interface, a host 102 can be multihomed. 104 Multihoming provides certain degree of resilience/redundancy against 105 failures (link, hardware, protocols, others) and also enables 106 features such as load balancing. Moreover, multihoming can be used 107 in order to differentiate traffic based on policy, for non-technical 108 reasons, such as cost associated with different flows, time of the 109 day, etc. For highly distributed enterprises, it can also occur as 110 an aid to address that enterprise's geographical distribution, and as 111 a traffic engineering mechanism to improve local performance such as 112 latency and hop count reductions for real time protocols. 114 The scope of this document is to provide a brief description of the 115 motivations for multihoming and an analysis of different scenarios 116 where IPv6 multihoming could be relevant. 118 2. Multihoming Motivations 120 Considering the goals for requiring multihoming described in [1], as 121 well as other frequent issues, we can classify the motivations as 122 both technical and non-technical. 124 2.1 Technical motivations 126 The technical motivations are intended to provide resilience for the 127 multihomed networks. 129 1. Redundancy: In order to protect the network against failures. 130 These failures could be either in the multihomed network itself, 131 or in the upstream (e.g. provider) network. The failures can be 132 of very different types, including and not limited to: Link 133 failures (physical, logical, configuration, ...), hardware 134 failures (interfaces, routers, other equipment), protocol 135 failures (routing protocol, others). 137 2. Load sharing/balancing: In order to distribute the inbound and/or 138 outbound traffic (e.g. between multiple providers). 140 3. Performance: As a traffic engineering mechanism to dampen the 141 affects of upstream hub congestion through the use of 142 "complementary" providers (e.g., in case the local Internet 143 Exchanges are congested), avoiding for example, the traffic being 144 forwarded thru longer routes than logically required. 146 Some of these technical motivations could be partially solved by 147 multi-attaching the network to the same ISP (i.e. load balancing), 148 either in the same point-of-presence (POP) or via geographically 149 separated POPs. Resilience can also be increased by using different 150 routers, instead of just different interfaces. But in any case, load 151 balancing alone doesn't provide a complete protection from failures 152 in the upstream provider. For this reason, many sites may choose to 153 attach to multiple ISPs (i.e. multihoming) so that a failure within 154 the ISP will not necessarily isolate that site from the Internet as a 155 whole. 157 2.2 Non-technical motivations 159 A network can require multihoming for non-technical reasons. 160 Financial considerations may influence the deployment, such as 161 different cost or fees associated with with different traffic flows 162 (with different priorities), or differing costs at different times of 163 the day use, destination networks, accumulated bandwidth used, etc. 165 Political motivations may exist such as the desire to be able to 166 quickly change the provider, without renumbering. This motivation 167 could stem from a wide variety of considerations including service 168 charges, improved SLA, ISP bankruptcy, etc. 170 Another non-technical motivation, which occurs very frequently in 171 some scenarios (e.g. research and educations networks), is 172 acceptable usage policy, where commodity traffic is not accepted, in 173 general. 175 3. Multihoming Scenarios 177 Different networking scenarios provide different multihoming cases or 178 scenarios, which may have different peculiarities and requirements. 179 They are listed below with no specific order or priority. 181 3.1 Internet Service Provider (ISP) 183 An ISP is naturally multihomed when connected to two or more upstream 184 providers. Actually this is a very common case, especially for 185 medium and large ISPs. 187 In this scenario, the ISP will usually have its own address pool, in 188 a provider independent fashion, allocated from a Regional Internet 189 Registry (RIR). A multihomed ISP uses routing protocols to advertise 190 its address space to several upstream providers. 192 Some small ISPs only use one upstream provider, so in this case, 193 multihoming will not apply. 195 The National Research and Education Networks (NRENs) can be 196 considered, from the multihoming perspective, as ISPs, because they 197 are usually connected to several upstream providers, but they also 198 have their own addressing space (allocated from a RIR). 200 3.2 IX 202 Can an IX be multihomed, for example if they are layer 3 transit 203 providers, distributed IXs ???. 205 TBD. 207 3.3 Enterprise 209 The size of any given enterprise network is a function of the size of 210 the corporation it supports. Enterprise networks can therefore range 211 from being small to being enormous. Larger enterprises may link 212 together multiple buildings within a campus, multiple campuses within 213 a region, multiple regions within a country, as well as have sites of 214 various sizes within multiple countries. A few corporations even 215 have corporate sites located within every country of the world. 216 These sites may themselves be linked together via public (e.g., ISP) 217 or private (e.g., dark fiber, satellite communications, modem 218 connections over telephone networks) means. A distinction therefore 219 needs to be made between a large corporation's private use of public 220 (ISP) networking facilities to privately link together disparate 221 parts of that corporation and that same corporation's public POPs to 222 the worldwide Internet. The former is solely known (or, at least, it 223 should be solely known) to the corporation and the supplier, the 224 latter is advertised to the worldwide Internet infrastructure as the 225 standard mechanism by which that corporation can be accessed. This 226 distinction is important because the security mechanisms protecting 227 these different uses (e.g., firewalls) are often very distinct from 228 each other. 230 Medium and large corporations are frequently attached to several 231 ISPs, often for multihoming and load balancing reasons. Highly 232 distributed corporations often have additional motivations for 233 connectivity to multiple ISPs stemming from traffic engineering and 234 performance considerations, particularly if real time traffic (e.g. 236 VoIP) is being internally supported. 238 This kind of networks usually require a high resilience, because any 239 outage, even when minimal, could mean a very high cost, that could 240 justify the adoption of a multihoming solution even if this is 241 expensive. 243 Medium and small enterprise networks could fall in the category of 244 Enterprise or in the SOHO one, which is very dependent on the 245 specific resilience requirements. 247 3.4 University/Campus 249 In principle, it seems that a University or Campus network fits in 250 the same category as the enterprise network, except that its policies 251 and security systems are very different, particularly because the 252 university will not go out of business if the information contained 253 within its computers becomes compromised. 255 Is also important to recognize one more special non-technical 256 requirement. Often they are connected in addition to commercial ISPs 257 to non-commercial ISPs (NRENs), which don't allow commodity traffic, 258 and consequently the network must control traffic based on policy. 260 3.5 Security, Defense and Emergency 262 Military networks differ from university and corporate networks in 263 that their computers and the networks themselves operate at specific 264 classification levels. In military jargon, these are known as "Red 265 networks". Each red network instance operates at a specific 266 classification level (e.g., secret, sensitive-but-unclassified, 267 etc.). Red networks operating at different classification levels may 268 have disjoint (i.e., unrelated) address spaces from each other. In 269 some military environments, Red networks are conveyed over physical 270 media that can be protected. This is in contrast to Black networks, 271 whose media cannot be similarly protected (e.g., wireless 272 transmissions). Packets from Red networks may be conveyed over Black 273 networks if the Red packets are first encrypted. In some cases, the 274 encrypted Red packet may be encapsulated within an appropriate IP 275 header of the Black network. 277 But from the multihoming perspective, in principle, it seems that 278 security and military networks fit into the same category as the 279 enterprise network (for instance, as different networks for the Red 280 and Black ones, and both could be also multihomed). 282 This is also the case for civil and emergency networks, for example 283 those used in airports, or by police/law enforcement, fireman, health 284 care, etc. and specially in the avenue of catastrophic events. 286 The importance of multihoming here is related to the need of high 287 reliability, because the failure could potentially increase the risk 288 for human life. 290 3.6 SOHO and Home 292 A Small Office/Home Office or Home, can fall into the category of a 293 managed or unmanaged network. Usually there is a minimum management 294 of the network, that could be done in-house, or as part of the 295 service provided by the ISP, external consultants or systems 296 integrators. 298 Is becoming very frequent the case where different ISPs provide 299 service to the same SOHO/Home network, by means of different access 300 networks (xDSL, Cable, Wireless, PLC/BPL, etc.). 302 A SOHO/Home network was usually a very small network with a single 303 subnet, but this is also rapidly changing, and several subnets will 304 be more frequently present in this scenario. 306 Some times this network can be part of an enterprise network, and 307 consequently managed, usually connected via a VPN to the corporate 308 network, so in this case, the multihoming could depend on the VPN 309 access itself. But is also the case when different hosts or 310 different applications need to chose either the VPN (for example 311 email or corporate applications), or the ISP (for example regular web 312 access); in this case the multihoming case is the same as in the 313 enterprise network scenario (the VPN behaves as a separate ISP). 315 Today, the complete resilience of this network is already required, 316 even if the solution cost is usually still too high. We can envision 317 that the requirement for multihoming will become more frequent, 318 specially considering the increase of tele-work and the usage of 319 Internet for voice and video applications. 321 So the SOHO/Home network is positioned to enjoy the greatest benefit 322 from multihoming. Although those networks typically do not have 323 access to "enterprise-class" links with guaranteed uptime (or any 324 guarantee at all) it is not uncommon for multiple providers to offer 325 technologically diverse residential services in a single area. 326 Multihoming to two or more such services (e.g., DSL, cable, 327 satellite, BPL/PLC, etc.) can dramatically increase the resistance of 328 a SOHO/Home network to external single points of failure. Resilience 329 in those networks is becoming an important issue in the face of 330 residential VoIP deployment. While it is unlikely that an enterprise 331 environment will be without any conventional phone lines in the near 332 future, residential consumers are already experimenting with 333 Internet-only phone service. It will become critical to deliver 334 reliability approaching that of conventional phone lines if we are to 335 maintain E911 service, fire alarm monitoring, and similar life safety 336 functions at their current levels of effectiveness. While such 337 reliability may be delivered by a single provider in select areas, 338 multihoming should allow a larger set of consumers to set and meet 339 their own standards through multiple attachment. 341 SOHO/Home networks may ultimately support life safety functions 342 (e.g., health care, detectors, surveillance, etc.). The required 343 reliability to monitor a smoke detector while a family sleeps is as 344 least as great as that required by an enterprise where the most 345 serious consequence of a network failure is likely financial. 347 In some cases, a host-centric multihoming approach could be 348 sufficient for this scenario. This could be the case when single 349 devices are directly connected to several access networks, for 350 example for safety or security reasons. 352 3.7 3GPP 354 Is this the same as the mobility case ???. 356 Can a GGSN be multi-homed ???. 358 As IPv6 allows to have multiple addresses in each interface, the 3GPP 359 terminal with a single interface can be multihomed using multiple 360 IPv6 addresses with a single radio connection. Furthermore some 3GPP 361 terminals are available with more than one interface (3GPP and WLAN) 362 can be multihomed using one or several IP addresses in each 363 interface. 365 Similarly, a GGSN can have multiple IPv6 addresses per interface and 366 several upstream links. 368 3.8 Add-hoc 370 is this a special case ???. what about managed ad-hoc networks for 371 the military domain ? 373 3.9 Mesh 375 Mesh networks are those that use its nodes as routers so that every 376 node does not have to hear every other node directly (as in the 377 classic ad-hoc case). It is more likely in this case that the entire 378 network may touch more than one "external" provider, and consequently 379 is multihomed. 381 4. Special Services and Applications within the Multihoming Scenarios 383 In addition to the generic scenarios, there are some special 384 situations, services or applications, that could be parallel to any 385 of the previously described cases, and should be considered in order 386 to have a complete perspective for each of the above mentioned 387 scenarios. 389 4.1 GRIDs and other temporary networks 391 An organization with his own network and addressing being connected 392 to a bigger network, for example in a GRID situation, in a temporary 393 or quasi-permanent basis. This can be also the example for research 394 institutions that often connect their networks to other networks and 395 may receive new addressing space creating a multi-homing situation. 397 4.2 Mobility 399 A mobile host or a mobile network can be simultaneously moving and 400 still be attached to more than just one ISP. For example when 401 connected simultaneously to a GPRS or 3GPP networks and a WISP (WLAN 402 ISP). 404 Much more text needed here !. 406 4.3 Multihomed devices 408 Cellular phones with for example 3GPP and WLAN interfaces, laptops 409 with 3GPP and Ethernet or even WLAN, all those are good examples of 410 multihomed devices. This seems to be same as the host-centric 411 multihoming case, but could also be related to the mobility scenario. 413 4.4 Renumbering 415 When a network is being renumbered, temporarily, during the 416 renumbering process itself, it may become a multihomed network. 418 4.5 Real Time Traffic 420 The increase of the usage data networks and Internet for real time 421 traffic (VoIP, video/audio streaming, videoconferencing, etc.). 423 For example, the impact of the penetration of VoIP for residential 424 usage (SOHO, home), could bring situations where the conventional 425 phone lines disappear, while several access networks connect those 426 sites. In this case, multihoming is much more critical to maintain 427 the level of service required for emergency (e.g. E911, medical, 428 security, ...) and similar life facilities that today depend on the 429 telephone. 431 This is also specially relevant for rural areas, which today don't 432 have copper connectivity, but are already attached to Internet by 433 other means (satellite, PLC, WLAN, etc.). 435 Of course this could be also true for other kind of networks, like 436 enterprise, emergency, etc. 438 4.6 Specific protocols/applications 440 Content Delivery Networks (CDNs), Internet Data Centers (IDC), DNS, 441 DHCP, RA, ????. 443 TBD. 445 4.7 Others 447 any ??? TBD. 449 5. Security Considerations 451 This memo does not generate any new security considerations. 453 6. IANA Considerations 455 This document requests no action for IANA. 457 [[Note to RFC-editor: this section can be removed upon publication.]] 459 7. Acknowledgements 461 The authors would like to acknowledge the inputs from Jim Bound, 462 Munechika Sumikawa, Antonio Tapiador, and the European Commission 463 support in the co-funding of the Euro6IX project, where this work is 464 being developed. 466 8 Informative References 468 [1] Abley, J., Black, B. and V. Gill, "Goals for IPv6 469 Site-Multihoming Architectures", RFC 3582, August 2003. 471 Authors' Addresses 473 Jordi Palet Martinez 474 Consulintel 475 San Jose Artesano, 1 476 Alcobendas - Madrid 477 E-28108 - Spain 479 Phone: +34 91 151 81 99 480 Fax: +34 91 151 81 98 481 EMail: jordi.palet@consulintel.es 483 Miguel Angel Diaz Fernandez 484 Consulintel 485 San Jose Artesano, 1 486 Alcobendas - Madrid 487 E-28108 - Spain 489 Phone: +34 91 151 81 99 490 Fax: +34 91 151 81 98 491 EMail: miguelangel.diaz@consulintel.es 493 Cesar Olvera 494 Consulintel 495 San Jose Artesano, 1 496 Alcobendas - Madrid 497 E-28108 - Spain 499 Phone: +34 91 151 81 99 500 Fax: +34 91 151 81 98 501 EMail: cesar.olvera@consulintel.es 503 Alvaro Vives Martinez 504 Consulintel 505 San Jose Artesano, 1 506 Alcobendas - Madrid 507 E-28108 - Spain 509 Phone: +34 91 151 81 99 510 Fax: +34 91 151 81 98 511 EMail: alvaro.vives@consulintel.es 512 Eric Fleischman 513 Boeing 515 Phone: 516 Fax: 517 EMail: eric.fleischman@boeing.com 519 Dan Lanciani 521 Phone: 522 Fax: 523 EMail: ddl@danlan.com 525 Intellectual Property Statement 527 The IETF takes no position regarding the validity or scope of any 528 Intellectual Property Rights or other rights that might be claimed to 529 pertain to the implementation or use of the technology described in 530 this document or the extent to which any license under such rights 531 might or might not be available; nor does it represent that it has 532 made any independent effort to identify any such rights. Information 533 on the procedures with respect to rights in RFC documents can be 534 found in BCP 78 and BCP 79. 536 Copies of IPR disclosures made to the IETF Secretariat and any 537 assurances of licenses to be made available, or the result of an 538 attempt made to obtain a general license or permission for the use of 539 such proprietary rights by implementers or users of this 540 specification can be obtained from the IETF on-line IPR repository at 541 http://www.ietf.org/ipr. 543 The IETF invites any interested party to bring to its attention any 544 copyrights, patents or patent applications, or other proprietary 545 rights that may cover technology that may be required to implement 546 this standard. Please address the information to the IETF at 547 ietf-ipr@ietf.org. 549 Disclaimer of Validity 551 This document and the information contained herein are provided on an 552 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 553 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 554 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 555 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 556 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 557 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 559 Copyright Statement 561 Copyright (C) The Internet Society (2004). This document is subject 562 to the rights, licenses and restrictions contained in BCP 78, and 563 except as set forth therein, the authors retain all their rights. 565 Acknowledgment 567 Funding for the RFC Editor function is currently provided by the 568 Internet Society.