idnits 2.17.1 draft-ietf-multi6-v4-multihoming-03.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 24. -- Found old boilerplate from RFC 3978, Section 5.5 on line 563. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 540. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 547. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 553. ** 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 (January 4, 2005) is 7052 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) -- Obsolete informational reference (is this intentional?): RFC 1519 (ref. '1') (Obsoleted by RFC 4632) -- Obsolete informational reference (is this intentional?): RFC 1771 (ref. '2') (Obsoleted by RFC 4271) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Abley 3 Internet-Draft ISC 4 Expires: July 5, 2005 K. Lindqvist 5 Netnod Internet Exchange 6 E. Davies 7 Independent Researcher 8 B. Black 9 Layer8 Networks 10 V. Gill 11 AOL 12 January 4, 2005 14 IPv4 Multihoming Practices and Limitations 15 draft-ietf-multi6-v4-multihoming-03 17 Status of this Memo 19 This document is an Internet-Draft and is subject to all provisions 20 of section 3 of RFC 3667. By submitting this Internet-Draft, each 21 author represents that any applicable patent or other IPR claims of 22 which he or she is aware have been or will be disclosed, and any of 23 which he or she become aware will be disclosed, in accordance with 24 RFC 3668. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as 29 Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on July 5, 2005. 44 Copyright Notice 46 Copyright (C) The Internet Society (2005). 48 Abstract 49 Multihoming is an essential component of service for many sites which 50 are part of the Internet. This document describes some 51 implementation strategies for multihoming with IPv4 and enumerates 52 features for comparison with other multihoming proposals 53 (particularly those related to IPv6). 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. IPv4 Multihoming Practices . . . . . . . . . . . . . . . . . . 4 60 3.1 Multihoming with BGP . . . . . . . . . . . . . . . . . . . 4 61 3.1.1 Addressing Considerations . . . . . . . . . . . . . . 4 62 3.1.2 AS Number Considerations . . . . . . . . . . . . . . . 6 63 3.2 Multiple Attachments to a Single Transit Provider . . . . 6 64 3.3 NAT- or RFC2260-based Multihoming . . . . . . . . . . . . 7 65 4. Features of IPv4 Multihoming . . . . . . . . . . . . . . . . . 7 66 4.1 Redundancy . . . . . . . . . . . . . . . . . . . . . . . . 7 67 4.2 Load Sharing . . . . . . . . . . . . . . . . . . . . . . . 7 68 4.3 Performance . . . . . . . . . . . . . . . . . . . . . . . 8 69 4.4 Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.5 Simplicity . . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.6 Transport-Layer Survivability . . . . . . . . . . . . . . 9 72 4.7 Impact on DNS . . . . . . . . . . . . . . . . . . . . . . 9 73 4.8 Packet Filtering . . . . . . . . . . . . . . . . . . . . . 9 74 4.9 Scalability . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.10 Impact on Routers . . . . . . . . . . . . . . . . . . . . 10 76 4.11 Impact on Hosts . . . . . . . . . . . . . . . . . . . . . 10 77 4.12 Interactions between Hosts and the Routing System . . . . 10 78 4.13 Operations and Management . . . . . . . . . . . . . . . . 10 79 4.14 Cooperation between Transit Providers . . . . . . . . . . 10 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 82 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 83 8. Informative References . . . . . . . . . . . . . . . . . . . . 10 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 85 Intellectual Property and Copyright Statements . . . . . . . . 13 87 1. Introduction 89 Multihoming is an important component of service for many sites which 90 are part of the Internet. Current IPv4 multihoming practices have 91 been added on to the Classless Inter Domain Routing (CIDR) 92 architecture [1], which assumes that routing table entries can be 93 aggregated based upon a hierarchy of customers and service providers. 95 Multihoming is a mechanism by which sites can satisfy a number of 96 high-level requirements, and is widely used in the IPv4 Internet. 97 There are some practical limitations, however, including concerns as 98 to how well the current practice will scale as the Internet continues 99 to grow, if at all. This document aims to document common IPv4 100 multihoming practices, and enumerate their features for comparison 101 with other multihoming approaches. 103 There are a number of different ways to route and manage traffic in 104 and out of a multihomed site: the majority rely on the routing policy 105 capabilities of the inter-domain routing protocol, the Border Gateway 106 Protocol, version 4 (BGP) [2]. This document also discusses a 107 multi-homing strategy which does not rely on the capabilities of BGP. 109 2. Terminology 111 A "site" is an entity autonomously operating a network using IP, and 112 in particular, determining the addressing plan and routing policy for 113 that network. This definition is intended to be equivalent to 114 'enterprise' as defined in [3]. 116 A "transit provider" operates a site that directly provides 117 connectivity to the Internet to one or more external sites. The 118 connectivity provided extends beyond the transit provider's own site 119 and it's own direct customer networks. A transit provider's site is 120 directly connected to the sites for which it provides transit. 122 A "multihomed" site is one with more than one transit provider. 123 "Site-multihoming" is the practice of arranging a site to be 124 multihomed. 126 The term "re-homing" denotes a transition of a site between two 127 states of connectedness due to a change in the connectivity between 128 the site and its transit providers' sites. 130 A "multi-attached" site is one with more than one point of layer-3 131 interconnection to a single transit provider. 133 Provider-Independent (PI) addresses are globally-unique addresses 134 which are not assigned by a transit provider, but are provided by 135 some other organisation, most usually a Regional Internet Registry 136 (RIR). 138 Provider-Aggregatable (PA) addresses are globally-unique addresses 139 assigned by a transit provider to a customer. The addresses are 140 considered "aggregatable" since the set of routes corresponding to 141 the PA addresses are usually covered by an aggregate route set 142 corresponding to the address space operated by the transit provider, 143 from which the assignment was made. 145 Note that the words "assign" and "allocate" have specific meanings in 146 Regional Internet Registry (RIR) address management policies, but are 147 used more loosely in this document. 149 3. IPv4 Multihoming Practices 151 3.1 Multihoming with BGP 153 The general approach for multihoming with BGP is to announce a set of 154 routes to two or more transit providers. This provides the rest of 155 the Internet with multiple paths back to the multihomed sites, and 156 each transit provider provides an additional possible path for the 157 site's outbound traffic. 159 3.1.1 Addressing Considerations 161 3.1.1.1 PI Addresses 163 The site uses PI addresses, and a set of routes covering those PI 164 addresses is announced or propagated by two or more transit 165 providers. 167 Using PI addresses has long been the preferred approach for IPv4 168 multihoming. Until the mid-1990s this was relatively easy to 169 accomplish, as the maximum generally accepted prefix length in the 170 global routing table was a /24, and little justification was needed 171 to obtain a /24 PI assignment. However, RIR address management 172 policies have become less liberal in this respect; not all RIRs 173 support the assignment of address blocks to small, multihomed 174 end-users, and those that do require justification for blocks as 175 large as a /24 which cannot be met by small sites. As a consequence, 176 PI addresses are not available to many sites who wish to multihome. 178 Each site that use PI addresses introduces an additional prefix into 179 the global routing system. Widespread multihoming in this manner 180 would present scaling concerns. 182 3.1.1.2 PA Addresses 184 The site uses PA addresses assigned by a single transit provider. 185 The set of routes covering those PA addresses (the "site route set") 186 is announced or propagated by one or more additional transit 187 providers. The transit provider which assigned the PA addresses (the 188 "primary transit provider") originates a set of routes which cover 189 the site route set. The primary transit provider often originates or 190 propagates the site route set as well as the covering aggregates. 192 The use of PA addresses is applicable to sites whose addressing 193 requirements are not sufficient to meet the requirements for PI 194 assignments by RIRs. In the case where the site route set is to be 195 announced or propagated by two or more different transit providers, 196 however, common operational practice still dictates minimum /24 197 prefixes which may be larger than the allocation available to small 198 sites. 200 There have been well-documented examples of sites filtering 201 long-prefix routes which are covered by a transit-providers 202 aggregate. If this practice were to become very widespread, it might 203 limit the effectiveness of multihoming using PA addresses. Limited 204 filtering of this kind can be tolerated, however, since the aggregate 205 announcements of the primary transit provider should be sufficient to 206 attract traffic from autonomous systems which do not accept the 207 covered site route set. The more traffic that follows the primary 208 transit provider's aggregate in the absence of the covered, 209 more-specific route, the greater the reliance on that primary transit 210 provider. In some cases this reliance might result in an effective 211 single point of failure. 213 Traffic following the primary transit provider's aggregate routes may 214 still be able to reach the multihomed site even in the case where the 215 connection between the primary transit provider and the site has 216 failed. The site route set will still be propagating through the 217 site's other transit providers, and if that route set reaches (and is 218 accepted by) the primary transit provider, connectivity for traffic 219 following the aggregate route will be preserved. 221 Sites which use PA addresses are usually obliged to renumber if they 222 decide not to retain connectivity to the primary transit provider. 223 While this is a common requirement for all sites using PA addresses 224 (and not just those that are multihomed), it is one that may have 225 more frequent impact on sites whose motivation to multihome is to 226 facilitate changes of ISP. A multihomed site using PA addresses can 227 still add or drop other service providers without having to renumber. 229 3.1.2 AS Number Considerations 231 3.1.2.1 Consistent Origin AS 233 A multihomed site may choose to announce routes to two or more 234 transit providers from a globally-unique Autonomous System (AS) 235 number assigned to the site. This causes the origin of the route to 236 appear consistent when viewed from all parts of the Internet. 238 3.1.2.2 Inconsistent Origin AS 240 A multihomed site may choose to use a private-use AS number [4] to 241 originate routes to transit providers. It is normal practice for 242 private-use AS numbers to be stripped from AS_PATH attributes before 243 they are allowed to propagate from transit providers towards peers, 244 and hence routes observed from other parts of the Internet may appear 245 to have inconsistent origins. 247 When using private-use AS numbers, collisions between the use of 248 individual numbers by different transit providers are possible. 249 These collisions are arguably best avoided by not using private-use 250 AS numbers for applications which involve routing across 251 administrative domain boundaries. 253 A multihomed site may request that their transit providers each 254 originate the site's routes from the transit providers' ASes. 255 Dynamic routing (for the purposes of withdrawing the site's route in 256 the event that connectivity to the site is lost) is still possible in 257 this case using the transit providers' internal routing systems to 258 trigger the externally-visible announcements. 260 Operational troubleshooting is facilitated by the use of a consistent 261 origin AS. This allows import policies to be based on a route's true 262 origin rather than on intermediate routing details which may 263 ultimately be transient (e.g. as transit providers are added and 264 dropped by the multihomed site). 266 3.2 Multiple Attachments to a Single Transit Provider 268 Multihoming can be achieved through multiple connections to a single 269 transit provider. This imposes no additional load on the global 270 routing table beyond that involved in the site being single-attached. 271 A site that has solved its multihoming needs in this way is commonly 272 referred to as "multi-attached". 274 It is not a requirement that the multiattached site exchange routing 275 information with its transit provider using BGP. However, some 276 mechanism for re-routing inbound and outbound traffic over remaining 277 circuits in the event of failure is required, and BGP is often used 278 for this purpose. 280 Multi-attached sites gain no advantages from using PI addresses or 281 (where BGP is used) globally-unique AS numbers, and have no need to 282 be able to justify address assignments of a particular minimum size. 283 However, multi-attachment does not protect a site from the failure of 284 the single transit provider. 286 3.3 NAT- or RFC2260-based Multihoming 288 This method uses PA addresses assigned by each transit provider that 289 the site is connected to. The addresses are either allocated to 290 individual hosts within the network according to [5], or the site 291 uses Network Address Translation (NAT) to translate the various 292 provider addresses into a single set of private-use addresses [3] 293 within the site. The site is effectively singlehomed to more than 294 one transit provider, and none of the transit providers need to make 295 any accommodations beyond that which they would do for a 296 non-multihomed customer. 298 This approach accommodates a wide range of sites, from residential 299 Internet users to very large enterprises, requires no PI addresses or 300 AS numbers, and imposes no additional load on the Internet's global 301 routing system. However, it does not address several common 302 motivations for multihoming, most notably transport-layer 303 survivability. 305 4. Features of IPv4 Multihoming 307 The following sections describe some of the features of the 308 approaches described in Section 3 in the context of the general goals 309 for multihoming architectures presented in [7]. Detailed 310 descriptions and rationale for these goals can be found in that 311 document. 313 4.1 Redundancy 315 All the methods described provide redundancy which can protect a site 316 from some single-point failures. The degree of protection which is 317 obtained depends on the choice of transit providers, and the methods 318 used to interconnect the site to those transit providers. 320 4.2 Load Sharing 322 All of the methods describe provide some measure of load sharing 323 capability. Outbound traffic can be shared across ISPs using 324 appropriate exit selection policies; inbound traffic can be 325 distributed using appropriate export policies designed to influence 326 the exit selection of remote sites sending traffic back towards the 327 multihomed site. 329 In the case of RFC2260/NAT multihoming, distribution of inbound 330 traffic is controlled by address selection on the host or NAT. 332 4.3 Performance 334 BGP-speaking sites can employ import policy which causes exit 335 selection to avoid paths that are known to be problematic. For 336 inbound traffic, sites can often employ route export policy which 337 affords different treatment of traffic towards particular address 338 ranges within their network. 340 It should be noted that this is not a comprehensive capability, and 341 there are in general many traffic engineering goals which can only be 342 loosely approximated using this approach. 344 In the case of RFC2260/NAT multihoming in the absence of BGP routing 345 information, management of outbound traffic in this way is not 346 possible. The path taken by inbound traffic for a particular session 347 can be controlled by source address selection on the host or NAT. 349 4.4 Policy 351 It is possible in some circumstances to route traffic of a particular 352 type (e.g. protocol) via particular transit providers if the devices 353 in the site which source or sink that traffic can be isolated to a 354 set of addresses for which special export policy can be applied. 356 An example of this capability is the grouping of budget, best-effort 357 Internet customers into a particular range of addresses covered by a 358 route which is announced preferentially over a single, low-quality 359 transit path. 361 In the case of RFC2260/NAT multihoming, policies such as those 362 described here can be accommodated by appropriate address selection 363 on the host or NAT. More flexible implementations may be possible 364 for sessions originated from the multihomed site by selecting an 365 appropriate source address on a host or NAT according to criteria 366 such as transport-layer protocols and addresses (ports). 368 4.5 Simplicity 370 The current methods used as multihoming solutions are not all without 371 complexity, but have proven to be sufficiently simple to be used. 372 They have the advantage of familiarity due to having been deployed 373 extensively. 375 4.6 Transport-Layer Survivability 377 The BGP-based multihoming practices all provide some degree of 378 session survivability for transport-layer protocols. Where path 379 convergence following a re-homing event takes a long time, however, 380 sessions may time out. 382 Transport-layer sessions will not, in general, survive over a 383 re-homing event when using RFC2260/NAT multihoming. Transport 384 protocols which support multiple volatile endpoint addresses may be 385 able to provide session stability; however, these transport protocols 386 are not in wide use. 388 In all the methods described in this document, new transport-layer 389 sessions are able to be created following a re-homing event. 391 4.7 Impact on DNS 393 These multihoming strategies impose no new requirements on the DNS. 395 4.8 Packet Filtering 397 These multihoming practices do not preclude filtering of packets with 398 inappropriate source or destination addresses at the administrative 399 boundary of the multihomed site. 401 4.9 Scalability 403 Current IPv4 multihoming practices are thought to contribute to 404 significant observed growth in the amount of state held in the global 405 inter-provider routing system; this is a concern both because of the 406 hardware requirements it imposes and also because of the impact on 407 the stability of the routing system. This issue is discussed in 408 greater detail in [6]. 410 Of the methods presented in this document, RFC2260/NAT multihoming 411 and multi-attaching to a single transit provider provide no 412 additional state to be held in the global routing system. The other 413 strategies all contribute to routing system state bloat. 415 Globally-unique AS numbers are a finite resource, and hence 416 widespread multihoming using strategies which require AS numbers to 417 be assigned might lead to increased resource contention. 419 4.10 Impact on Routers 421 For some of the multihoming approaches described in this document, 422 the routers at the boundary of the multihomed site are required to 423 participate in BGP sessions with transit provider routers. Other 424 routers within the site generally have no special requirements beyond 425 those in singlehomed sites. 427 4.11 Impact on Hosts 429 There are no requirements of hosts beyond those in singlehomed sites. 431 4.12 Interactions between Hosts and the Routing System 433 There are no requirements for interaction between routers and hosts 434 beyond those in singlehomed sites. 436 4.13 Operations and Management 438 There is extensive operational experience in managing IPv4-multihomed 439 sites. 441 4.14 Cooperation between Transit Providers 443 Transit providers who are asked to announce or propagate a PA prefix 444 covered by some other (primary) transit provider usually obtain 445 authorisation first. There is no technical requirement or common 446 contractural policy which requires this coordination to take place, 447 however. 449 5. Security Considerations 451 This document discusses current IPv4 multihoming practices, but 452 provides no analysis of the security implications of multihoming. 454 6. IANA Considerations 456 This document requests no action by the IANA. 458 7. Acknowledgements 460 Special acknowledgement goes to Loughney for proof-reading and 461 corrections. Thanks also goes to Pekka Savola and Iljitsch van 462 Beijnum for providing feedback and contributing text. 464 8 Informative References 466 [1] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless 467 Inter-Domain Routing (CIDR): an Address Assignment and 468 Aggregation Strategy", RFC 1519, September 1993. 470 [2] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 471 RFC 1771, March 1995. 473 [3] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. 474 Lear, "Address Allocation for Private Internets", BCP 5, RFC 475 1918, February 1996. 477 [4] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, 478 and registration of an Autonomous System (AS)", BCP 6, RFC 1930, 479 March 1996. 481 [5] Bates, T. and Y. Rekhter, "Scalable Support for Multi-homed 482 Multi-provider Connectivity", RFC 2260, January 1998. 484 [6] Huston, G., "Commentary on Inter-Domain Routing in the 485 Internet", RFC 3221, December 2001. 487 [7] Abley, J., Black, B. and V. Gill, "Goals for IPv6 488 Site-Multihoming Architectures", RFC 3582, August 2003. 490 Authors' Addresses 492 Joe Abley 493 Internet Systems Consortium, Inc. 494 950 Charter Street 495 Redwood City, CA 94063 496 USA 498 Phone: +1 650 423 1317 499 EMail: jabley@isc.org 501 Kurt Erik Lindqvist 502 Netnod Internet Exchange 503 Bellmansgatan 30 504 Stockholm S-118 47 505 Sweden 507 Phone: +46 8 615 85 70 508 EMail: kurtis@kurtis.pp.se 509 Elwyn B. Davies 510 Independent Researcher 511 Soham, Cambridgeshire CB7 5AW 512 UK 514 Phone: +44 7889 488 335 515 EMail: elwynd@dial.pipex.com 517 Benjamin Black 518 Layer8 Networks 520 EMail: ben@layer8.net 522 Vijay Gill 523 AOL 524 12100 Sunrise Valley Dr 525 Reston, VA 20191 526 US 528 Phone: +1 410 336 4796 529 EMail: vgill@vijaygill.com 531 Intellectual Property Statement 533 The IETF takes no position regarding the validity or scope of any 534 Intellectual Property Rights or other rights that might be claimed to 535 pertain to the implementation or use of the technology described in 536 this document or the extent to which any license under such rights 537 might or might not be available; nor does it represent that it has 538 made any independent effort to identify any such rights. Information 539 on the procedures with respect to rights in RFC documents can be 540 found in BCP 78 and BCP 79. 542 Copies of IPR disclosures made to the IETF Secretariat and any 543 assurances of licenses to be made available, or the result of an 544 attempt made to obtain a general license or permission for the use of 545 such proprietary rights by implementers or users of this 546 specification can be obtained from the IETF on-line IPR repository at 547 http://www.ietf.org/ipr. 549 The IETF invites any interested party to bring to its attention any 550 copyrights, patents or patent applications, or other proprietary 551 rights that may cover technology that may be required to implement 552 this standard. Please address the information to the IETF at 553 ietf-ipr@ietf.org. 555 Disclaimer of Validity 557 This document and the information contained herein are provided on an 558 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 559 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 560 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 561 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 562 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 563 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 565 Copyright Statement 567 Copyright (C) The Internet Society (2005). This document is subject 568 to the rights, licenses and restrictions contained in BCP 78, and 569 except as set forth therein, the authors retain all their rights. 571 Acknowledgment 573 Funding for the RFC Editor function is currently provided by the 574 Internet Society.