idnits 2.17.00 (12 Aug 2021) /tmp/idnits25816/draft-ietf-l3vpn-rt-constrain-02.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 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 536. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 543. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 549. ** 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. 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 : ---------------------------------------------------------------------------- ** 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.) 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 (June 22, 2005) is 6170 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) -- Looks like a reference, but probably isn't: 'AFI' on line 293 -- Looks like a reference, but probably isn't: 'SAFI' on line 293 ** Obsolete normative reference: RFC 2796 (ref. '2') (Obsoleted by RFC 4456) == Outdated reference: draft-ietf-l3vpn-rfc2547bis has been published as RFC 4364 == Outdated reference: draft-ietf-idr-route-filter has been published as RFC 5291 == Outdated reference: draft-ietf-idr-bgp4 has been published as RFC 4271 ** Obsolete normative reference: RFC 2858 (ref. '6') (Obsoleted by RFC 4760) == Outdated reference: draft-ietf-idr-bgp-ext-communities has been published as RFC 4360 == Outdated reference: draft-ietf-idr-restart has been published as RFC 4724 == Outdated reference: draft-ietf-l2vpn-vpls-bgp has been published as RFC 4761 Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L3VPN Working Group P. Marques 3 Internet-Draft R. Bonica 4 Expires: December 24, 2005 Juniper Networks 5 L. Fang 6 AT&T 7 L. Martini 8 R. Raszuk 9 K. Patel 10 J. Guichard 11 Cisco Systems, Inc. 12 June 22, 2005 14 Constrained VPN Route Distribution 15 draft-ietf-l3vpn-rt-constrain-02 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 27 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 35 http://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 December 24, 2005. 42 Copyright Notice 44 Copyright (C) The Internet Society (2005). 46 Abstract 48 This document defines MP-BGP procedures that allow BGP speakers to 49 exchange Route Target reachability information. This information can 50 be used to build a route distribution graph in order to limit the 51 propagation of VPN NLRI (such as VPN-IPv4, VPN-IPv6 or L2-VPN NLRI) 52 between different autonomous systems or distinct clusters of the same 53 autonomous system. 55 Table of Contents 57 1. Specification of Requirements . . . . . . . . . . . . . . . 3 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. NLRI Distribution . . . . . . . . . . . . . . . . . . . . . 6 60 3.1 Inter-AS VPN Route Distribution . . . . . . . . . . . . . 6 61 3.2 Intra-AS VPN Route Distribution . . . . . . . . . . . . . 7 62 4. Route Target membership NLRI advertisements . . . . . . . . 10 63 5. Capability Advertisement . . . . . . . . . . . . . . . . . . 11 64 6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 7. Deployment Considerations . . . . . . . . . . . . . . . . . 13 66 8. Security Considerations . . . . . . . . . . . . . . . . . . 14 67 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 69 10.1 Normative References . . . . . . . . . . . . . . . . . . 16 70 10.2 Informative References . . . . . . . . . . . . . . . . . 16 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 72 Intellectual Property and Copyright Statements . . . . . . . 19 74 1. Specification of Requirements 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC 2119 [1]. 80 2. Introduction 82 In BGP/MPLS IP VPNs, PE routers use Route Target (RT) extended 83 communities to control the distribution of routes into VRFs. Within 84 a given iBGP mesh, PE routers need only to hold routes marked with 85 Route Targets pertaining to VRFs that have local CE attachments. 87 It is common, however, for an autonomous system to use route 88 reflection [2] in order to simplify the process of bringing up a new 89 PE router in the network and to limit the size of the iBGP peering 90 mesh. 92 In such a scenario, as well as when VPNs may have members in more 93 than one autonomous system, the number of routes carried by the 94 inter-cluster or inter-as distribution routers is an important 95 consideration. 97 In order to limit the VPN routing information that is maintained at a 98 given route reflector, RFC2547bis [3] suggests, in section 4.3.3., 99 the use of "Cooperative Route Filtering" [4] between route 100 reflectors. This proposal extends the RFC2547bis [3] ORF work to 101 include support for multiple autonomous systems, and asymmetric VPN 102 topologies such as hub-and-spoke. 104 While it would be possible to extend the encoding currently defined 105 for the extended-community ORF in order to achieve this purpose, BGP 106 itself already has all the necessary machinery for dissemination of 107 arbitrary information in a loop free fashion, both within a single 108 autonomous system, as well as across multiple autonomous systems. 110 This document builds on the model described in RFC2547bis [3] and on 111 concept of cooperative route filtering by adding the ability to 112 propagate Route Target membership information between iBGP meshes. 113 It is designed to supersede "cooperative route filtering" for VPN 114 related applications. 116 By using MP-BGP UPDATE messages to propagate Route Target membership 117 information it is possible to reuse all this machinery including 118 route reflection, confederations and inter-as information loop 119 detection. 121 Received Route Target membership information can then be used to 122 restrict advertisement of VPN NLRI to peers that have advertised 123 their respective Route Targets, effectively building a route 124 distribution graph. In this model, VPN NLRI routing information 125 flows in the inverse direction of Route Target membership 126 information. 128 This mechanism is applicable to any BGP NLRI that controls the 129 distribution of routing information based on Route Targets, such as 130 BGP L2VPNs [?] and VPLS [9]. 132 Throughout this document, the term NLRI, which originally expands to 133 "Network Layer Reachability Information" is used to describe routing 134 information carried via MP-BGP updates without any assumption of 135 semantics. 137 An NLRI consisting of {origin-as#, route-target} will be referred to 138 as RT membership information for the purpose of the explanation in 139 this document. 141 3. NLRI Distribution 143 3.1 Inter-AS VPN Route Distribution 145 In order to better understand the problem at hand, it is helpful to 146 divide it in its inter-AS and intra-AS components. Figure 1 147 represents an arbitrary graph of autonomous systems (a through j) 148 interconnected in an ad-hoc fashion. The following discussion 149 ignores the complexity of intra-AS route distribution. 151 +----------------------------------+ 152 | +---+ +---+ +---+ | 153 | | a | -- | b | -- | c | | 154 | +---+ +---+ +---+ | 155 | | | | 156 | | | | 157 | +---+ +---+ +---+ +---+ | 158 | | d | -- | e | -- | f | -- | j | | 159 | +---+ +---+ +---+ +---+ | 160 | / | | 161 | / | | 162 | +---+ +---+ +---+ | 163 | | g | -- | h | -- | i | | 164 | +---+ +---+ +---+ | 165 +----------------------------------+ 167 Figure 1: Topology of autonomous systems 169 Lets consider the simple case of a VPN with CE attachments in ASes a 170 and i using a single Route Target to control VPN route distribution. 171 Ideally we would like to build a flooding graph for the respective 172 VPN routes that would not include nodes (c, g, h, j). Nodes (c, j) 173 are leafs ASes that do not require this information while nodes (g, 174 h) are not in the shortest inter-as path between (e) and (i) and thus 175 should be excluded via standard BGP path selection. 177 In order to achieve this we will rely on ASa and ASi generating a 178 NLRI consisting of {origin-as#, route-target} ( RT membership 179 information ). Receipt of such an advertisement by one of the ASes 180 in the network will signal the need to distribute VPN routes 181 containing this Route Target community to the peer that advertised 182 this route. 184 Using RT membership information that includes both route-target and 185 originator AS number, allows BGP speakers to use standard path 186 selection rules concerning as-path length (and other policy 187 mechanisms) to prune duplicate paths in the RT membership information 188 flooding graph, while maintaining the information required to reach 189 all autonomous systems advertising the Route Target. 191 In the example above, AS e needs to maintain a path to AS a in order 192 to flood VPN routing information originating from AS i and vice- 193 versa. It should however, as default policy, prune less preferred 194 paths such as the longer path to ASi with as-path (g h i). 196 Extending the example above to include AS j as a member of the VPN 197 distribution graph would cause AS f to advertise 2 RT Membership NLRI 198 to AS e, one containing origin AS i and one containing origin AS j. 199 While advertising a single path would be sufficient to guarantee that 200 VPN information flows to all VPN member ASes, this is not enough for 201 the desired path selection choices. In the example above, assume (f 202 j) is selected and advertised. Where that to be the case the 203 information concerning the path (f i), which is necessary to prune 204 the arc (e g h i) from the route distribution graph, would be 205 missing. 207 As with other approaches for building distribution graphs, the 208 benefits of this mechanism are directly proportional to how "sparse" 209 the VPN membership is. Standard RFC2547 inter-AS behavior can be 210 seen as a dense-mode approach, to make the analogy with multicast 211 routing protocols. 213 3.2 Intra-AS VPN Route Distribution 215 As indicated above, the inter-AS VPN route distribution graph, for a 216 given route-target, is constructed by creating a directed arc on the 217 inverse direction of received Route Target membership UPDATEs 218 containing an NLRI of the form {origin-as#, route-target}. 220 Inside the BGP topology of a given autonomous-system, as far as 221 external RT membership information is concerned (route-targets where 222 the as# is not the local as), it is easy to see that standard BGP 223 route selection and advertisement rules [5] will allow a transit AS 224 to create the necessary flooding state. 226 Consider a IPv4 NLRI prefix, sourced by a single AS, which is 227 distributed via BGP within a given transit AS. BGP protocol rules 228 guarantee that a BGP speaker has a valid route that can be used for 229 forwarding of data packets for that destination prefix, in the 230 inverse path of received routing updates. 232 By the same token, and given that a {origin-as#, route-target} key 233 provides uniqueness between several ASes that may be sourcing this 234 route-target, BGP route selection and advertisement procedures 235 guarantee that a valid VPN route distribution path exists to the 236 origin of the Route Target membership information advertisement. 238 Route Target membership information that is originated within the 239 autonomous-system however requires more careful examination. Several 240 PE routers within a given autonomous-system may source the same NLRI 241 {origin-as#, route-target}, thus default route advertisement rules 242 are no longer sufficient to guarantee that within the given AS each 243 node in the distribution graph has selected a feasible path to each 244 of the PEs that import the given route-target. 246 When processing RT membership NLRIs received from internal iBGP 247 peers, it is necessary to consider all available iBGP paths for a 248 given RT prefix, when building the outbound route filter, and not 249 just the best path. 251 In addition, when advertising Route Target membership information 252 sourced by the local autonomous system to an iBGP peer, a BGP speaker 253 shall modify its procedure to calculate the BGP attributes such that: 255 i. When advertising RT membership NLRI to a route-reflector 256 client, the Originator attribute shall be set to the router-id of 257 the advertiser and the Next-hop attribute shall be set of the 258 local address for that session. 260 ii. When advertising a RT membership NLRI to a non client peer, 261 if the best path as selected by path selection procedure described 262 in section 9.1 of the base BGP specification [5] is a route 263 received from a non-client peer, and there is an alternative path 264 to the same destination from a client, the attributes of the 265 client path are advertised to the peer. 267 The first of these route advertisement rules is designed such that 268 the originator of RT membership NLRI does not drop a RT membership 269 NLRI which is reflected back to it, thus allowing the route reflector 270 to use this RT membership NLRI in order to signal the client that it 271 should distribute VPN routes with the specific target torwards the 272 reflector. 274 The second rule makes it such that any BGP speaker present in an iBGP 275 mesh can signal the interest of its route reflection clients in 276 receiving VPN routes for that target. 278 These procedures assume that the autonomous-system route reflection 279 topology is configured such that IPv4 unicast routing would work 280 correctly. For instance, route reflection clusters must be 281 contiguous. 283 An alternative solution to the procedure given above would have been 284 to source different routes per PE, such as NLRI of the form {origina- 285 tor-id, route-target}, and aggregate them at the edge of the network. 286 The solution adopted is considered to be advantageous over the former 287 given that it requires less routing-information within a given AS. 289 4. Route Target membership NLRI advertisements 291 Route Target membership NLRI is advertised in BGP UPDATE messages 292 using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [6]. The 293 [AFI, SAFI] value pair used to identify this NLRI is (AFI=1, 294 SAFI=132). 296 The Next Hop field of MP_REACH_NLRI attribute shall be interpreted as 297 an IPv4 address, whenever the length of NextHop address is 4 octets, 298 and as a IPv6 address, whenever the length of the NextHop address is 299 16 octets. 301 The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix 302 of 0 to 96 bits encoded as defined in section 4 of [6]. 304 This prefix is structured as follows: 306 +-------------------------------+ 307 | origin as (4 octets) | 308 +-------------------------------+ 309 | route target (8 octets) | 310 + + 311 | | 312 +-------------------------------+ 314 Except for the default route target, which is encoded as a 0 length 315 prefix, the minimum prefix length is 32 bits. As the origin-as field 316 cannot be interpreted as a prefix. 318 Route targets can then be expressed as prefixes, where for instance, 319 a prefix would encompass all route target extended communities 320 assigned by a given Global Administrator [7]. 322 The default route target can be used to indicate to a peer the 323 willingness to receive all VPN route advertisements such as, for 324 instance, the case of a route reflector speaking to one of its PE 325 router clients. 327 5. Capability Advertisement 329 A BGP speaker that wishes to exchange Route Target membership 330 information must use the Multiprotocol Extensions Capability Code as 331 defined in RFC 2858 [6], to advertise the corresponding (AFI, SAFI) 332 pair. 334 A BGP speaker MAY participate in the distribution of Route Target 335 information while not using the learned information for purposes of 336 VPN NLRI output route filtering, although the latter is discouraged. 338 6. Operation 340 A VPN NLRI route should be advertised to a peer that participates in 341 the exchange of Route Target membership information if that peer has 342 advertised either the default Route Target membership NLRI or a Route 343 Target membership NLRI containing any of the targets contained in the 344 extended communities attribute of the VPN route in question. 346 When a BGP speaker receives a BGP UPDATE that advertises or withdraws 347 a given Route Target membership NLRI, it should examine the RIB-OUTs 348 of VPN NLRIs and re-evaluate the advertisement status of routes that 349 match the Route Target in question. 351 A BGP speaker should generate the minimum set of BGP VPN route 352 updates necessary to transition between the previous and current 353 state of the route distribution graph that is derived from Route 354 Target membership information. 356 An an hint that initial RT membership exchange is complete 357 implementations SHOULD generate an End-of-RIB marker, as defined in 358 [8], for the Route Target membership (afi, safi). Regardless of 359 whether graceful-restart is enabled on the BGP session. This allows 360 the receiver to know when it has received the full contents of the 361 peers membership information. The exchange of VPN NLRI should follow 362 the receipt of the End-of-RIB markers. 364 If a BGP speaker chooses to delay the advertisement of BGP VPN route 365 updates until it receives this End-of-RIB marker, it MUST limit that 366 delay to an upper bound. By default, a 60 second value should be 367 used. 369 7. Deployment Considerations 371 This mechanism reduces the scaling requirements that are imposed on 372 route reflectors by limiting the number of VPN routes and events that 373 a reflector has to process to the VPN routes used by its direct 374 clients. By default, a reflector must scale in terms of the total 375 number of VPN routes present on the network. 377 This also means that its is now possible to reduce the load imposed 378 on a given reflector by dividing the PE routers present on its 379 cluster into a new set of clusters. This is a localized 380 configuration change that need not affect any system outside this 381 cluster. 383 The effectiveness of RT-based filtering depends on how sparse the VPN 384 membership is. 386 The same policy mechanisms applicable to other NLRIs are also 387 applicable to RT membership information. This gives a network 388 operator the option of controlling which VPN routes get advertised in 389 an inter-domain border by filtering the acceptable RT membership 390 advertisements inbound. 392 For instance, in the inter-as case, it is likely that a given VPN is 393 connected to only a subset of all participating ASes. The only 394 current mechanism to limit the scope of VPN route flooding is through 395 manual filtering on the EBGP border routers. With the current 396 proposal such filtering can be performed based on the dynamic Route 397 Target membership information. 399 In some inter-as deployments not all RTs used for a given VPN have 400 external significance. For example, a VPN can use an hub RT and a 401 spoke RT internally to an autonomous-system. The spoke RT does not 402 have meaning outside this AS and so it may be stripped at an external 403 border router. The same policy rules that result in extended 404 community filtering can be applied to RT membership information in 405 order to avoid advertising an RT membership NLRI for the spoke-RT in 406 the example above. 408 Throughout this document, we assume that autonomous-systems agree on 409 an RT assignment convention. RT translation at the external border 410 router boundary, is considered to be a local implementation decision, 411 as it should not affect inter-operability. 413 8. Security Considerations 415 This document does not alter the security properties of BGP-based 416 VPNs. However it should be taken into consideration that output 417 route filters built from RT membership information NLRI are not 418 intended for security purposes. When exchanging routing information 419 between separate administrative domains, it is a good practice to 420 filter all incoming and outgoing NLRIs by some other means in 421 addition to RT membership information. Implementations SHOULD also 422 provide means to filter RT membership information. 424 9. Acknowledgments 426 This proposal is based on the extended community route filtering 427 mechanism defined in [4]. 429 Ahmed Guetari was instrumental in defining requirements for this 430 proposal. 432 The authors would also like to thank Yakov Rekhter, Dan Tappan, Dave 433 Ward, John Scudder, and Jerry Ash for their comments and suggestions. 435 10. References 437 10.1 Normative References 439 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 440 Levels", BCP 14, RFC 2119, March 1997. 442 [2] Bates, T., Chandra, R., and E. Chen, "BGP Route Reflection - An 443 Alternative to Full Mesh IBGP", RFC 2796, April 2000. 445 [3] Rosen, E., "BGP/MPLS IP VPNs", draft-ietf-l3vpn-rfc2547bis-03 446 (work in progress), October 2004. 448 [4] Chen, E. and Y. Rekhter, "Cooperative Route Filtering Capability 449 for BGP-4", draft-ietf-idr-route-filter-11 (work in progress), 450 December 2004. 452 [5] Rekhter, Y., "A Border Gateway Protocol 4 (BGP-4)", 453 draft-ietf-idr-bgp4-26 (work in progress), October 2004. 455 [6] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol 456 Extensions for BGP-4", RFC 2858, June 2000. 458 [7] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 459 Communities Attribute", draft-ietf-idr-bgp-ext-communities-08 460 (work in progress), February 2005. 462 [8] Sangli, S., Rekhter, Y., Fernando, R., Scudder, J., and E. Chen, 463 "Graceful Restart Mechanism for BGP", draft-ietf-idr-restart-10 464 (work in progress), June 2004. 466 10.2 Informative References 468 [9] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service", 469 draft-ietf-l2vpn-vpls-bgp-05 (work in progress), April 2005. 471 Authors' Addresses 473 Pedro Marques 474 Juniper Networks 475 1194 N. Mathilda Ave. 476 Sunnyvale, CA 94089 477 US 479 Email: roque@juniper.net 480 Ronald Bonica 481 Juniper Networks 482 1194 N. Mathilda Ave. 483 Sunnyvale, CA 94089 484 US 486 Email: rbonica@juniper.net 488 Luyuan Fang 489 AT&T 490 200 Laurel Avenue, Room C2-3B35 491 Middletown, NJ 07748 492 US 494 Email: luyuanfang@att.com 496 Luca Martini 497 Cisco Systems, Inc. 498 9155 East Nichols Avenue, Suite 400 499 Englewood, CO 80112 500 US 502 Email: lmartini@cisco.com 504 Robert Raszuk 505 Cisco Systems, Inc. 506 170 West Tasman Dr 507 San Jose, CA 95134 508 US 510 Email: rraszuk@cisco.com 512 Keyur Patel 513 Cisco Systems, Inc. 514 170 West Tasman Dr 515 San Jose, CA 95134 516 US 518 Email: keyupate@cisco.com 519 Jim Guichard 520 Cisco Systems, Inc. 521 300 Beaver Brook Road 522 Boxborough, MA 01719 523 US 525 Email: jguichar@cisco.com 527 Intellectual Property Statement 529 The IETF takes no position regarding the validity or scope of any 530 Intellectual Property Rights or other rights that might be claimed to 531 pertain to the implementation or use of the technology described in 532 this document or the extent to which any license under such rights 533 might or might not be available; nor does it represent that it has 534 made any independent effort to identify any such rights. Information 535 on the procedures with respect to rights in RFC documents can be 536 found in BCP 78 and BCP 79. 538 Copies of IPR disclosures made to the IETF Secretariat and any 539 assurances of licenses to be made available, or the result of an 540 attempt made to obtain a general license or permission for the use of 541 such proprietary rights by implementers or users of this 542 specification can be obtained from the IETF on-line IPR repository at 543 http://www.ietf.org/ipr. 545 The IETF invites any interested party to bring to its attention any 546 copyrights, patents or patent applications, or other proprietary 547 rights that may cover technology that may be required to implement 548 this standard. Please address the information to the IETF at 549 ietf-ipr@ietf.org. 551 Disclaimer of Validity 553 This document and the information contained herein are provided on an 554 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 555 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 556 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 557 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 558 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 559 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 561 Copyright Statement 563 Copyright (C) The Internet Society (2005). This document is subject 564 to the rights, licenses and restrictions contained in BCP 78, and 565 except as set forth therein, the authors retain all their rights. 567 Acknowledgment 569 Funding for the RFC Editor function is currently provided by the 570 Internet Society.