idnits 2.17.1 draft-ietf-idr-rfc3065bis-06.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 565. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 535. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 542. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 548. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (February 2007) is 6277 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 normative reference: RFC 1965 (Obsoleted by RFC 3065) ** Obsolete normative reference: RFC 3065 (Obsoleted by RFC 5065) -- Obsolete informational reference (is this intentional?): RFC 1863 (Obsoleted by RFC 4223) -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 2796 (Obsoleted by RFC 4456) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Paul Traina 2 Blissfully Retired 3 Danny McPherson 4 Arbor Networks 5 John Scudder 6 Juniper Networks 7 Expires: August 2007 February 2007 9 Autonomous System Confederations for BGP 10 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 The Border Gateway Protocol (BGP) is an inter-autonomous system 42 routing protocol designed for Transmission Control Protocol/Internet 43 Protocol (TCP/IP) networks. BGP requires that all BGP speakers 44 within a single autonomous system (AS) must be fully meshed. This 45 represents a serious scaling problem that has been well documented in 46 a number of proposals. 48 This document describes an extension to BGP which may be used to 49 create a confederation of autonomous systems that is represented as a 50 single autonomous system to BGP peers external to the confederation, 51 thereby removing the "full mesh" requirement. The intention of this 52 extension is to aid in policy administration and reduce the 53 management complexity of maintaining a large autonomous system. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Specification of Requirements . . . . . . . . . . . . . . . 4 59 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. AS_CONFED Segment Type Extension . . . . . . . . . . . . . . . 6 62 4. Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.1. AS_PATH Modification Rules. . . . . . . . . . . . . . . . . 7 64 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 8 65 5.1. Common Administrative Issues. . . . . . . . . . . . . . . . 9 66 5.2. MED and LOCAL_PREF Handling . . . . . . . . . . . . . . . . 9 67 5.3. AS_PATH and Path Selection. . . . . . . . . . . . . . . . . 10 68 6. Compatability Considerations . . . . . . . . . . . . . . . . . 10 69 7. Deployment Considerations. . . . . . . . . . . . . . . . . . . 11 70 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 11 71 9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 12 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 11. References. . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 75 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 76 12. Appendix A: Aggregate Routing Information . . . . . . . . . . 15 77 13. Appendix B: Changes From RFC 3065 . . . . . . . . . . . . . . 15 78 14. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 15 80 1. Introduction 82 As currently defined, BGP requires that all BGP speakers within a 83 single AS must be fully meshed. The result is that for n BGP 84 speakers within an AS n*(n-1)/2 unique IBGP sessions are required. 85 This "full mesh" requirement clearly does not scale when there are a 86 large number of IBGP speakers within the autonomous system, as is 87 common in many networks today. 89 This scaling problem has been well documented and a number of 90 proposals have been made to alleviate this [RFC 1863, RFC 2796]. 91 This document presents another alternative alleviating the need for a 92 "full mesh" and is known as "Autonomous System Confederations for 93 BGP", or simply, "BGP Confederations". It has also been observed 94 that BGP Confederations may provide improvements in routing policy 95 control. 97 This document is a revision of [RFC 3065], which is itself a revision 98 to [RFC 1965]. It includes editorial changes, terminology 99 clarifications and more explicit protocol specifications based on 100 extensive implementation and deployment experience with BGP 101 Confederations. 103 1.1. Specification of Requirements 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC 2119]. 109 1.2. Terminology 111 AS Confederation 113 A collection of autonomous systems represented and advertised 114 as a single AS number to BGP speakers that are not members of 115 the local BGP confederation. 117 AS Confederation Identifier 119 An externally visible autonomous system number that identifies 120 a BGP confederation as a whole. 122 Member Autonomous System (Member-AS) 124 An autonomous system that is contained in a given AS 125 confederation. Note that "Member Autonomous System" and 126 "Member-AS" are used entirely interchangeably throughout 127 this document. 129 Member-AS Number 131 An autonomous system number identifier visible only within 132 a BGP confederation, and used to represent a Member-AS 133 within that confederation. 135 2. Discussion 137 It may be useful to subdivide autonomous systems with a very large 138 number of BGP speakers into smaller domains for purposes of 139 controlling routing policy via information contained in the BGP 140 AS_PATH attribute. For example, one may choose to consider all BGP 141 speakers in a geographic region as a single entity. 143 In addition to potential improvements in routing policy control, if 144 techniques such as those presented here or in [RFC 2796] are not 145 employed, [BGP-4] requires BGP speakers in the same autonomous system 146 to establish a full mesh of TCP connections among all speakers for 147 the purpose of exchanging exterior routing information. In 148 autonomous systems the number of intra-domain connections that need 149 to be maintained by each border router can become significant. 151 Subdividing a large autonomous system allows a significant reduction 152 in the total number of intra-domain BGP connections, as the 153 connectivity requirements simplify to the model used for inter-domain 154 connections. 156 Unfortunately, subdividing an autonomous system may increase the 157 complexity of routing policy based on AS_PATH information for all 158 members of the Internet. Additionally, this division increases the 159 maintenance overhead of coordinating external peering when the 160 internal topology of this collection of autonomous systems is 161 modified. 163 Therefore, division of an autonomous system into separate systems may 164 adversely affect optimal routing of packets through the Internet. 166 However, there is usually no need to expose the internal topology of 167 this divided autonomous system, which means it is possible to regard 168 a collection of autonomous systems under a common administration as a 169 single entity or autonomous system, when viewed from outside the 170 confines of the confederation of autonomous systems itself. 172 3. AS_CONFED Segment Type Extension 174 Currently, BGP specifies that the AS_PATH attribute is a well-known 175 mandatory attribute that is composed of a sequence of AS path 176 segments. Each AS path segment is represented by a triple . 179 In [BGP-4], the path segment type is a 1-octet long field with the 180 two following values defined: 182 Value Segment Type 184 1 AS_SET: unordered set of autonomous systems a route in 185 the UPDATE message has traversed 187 2 AS_SEQUENCE: ordered set of autonomous systems a route 188 in the UPDATE message has traversed 190 This document specifies two additional segment types: 192 3 AS_CONFED_SEQUENCE: ordered set of Member Autonomous 193 Systems in the local confederation that the UPDATE message 194 has traversed 196 4 AS_CONFED_SET: unordered set of Member Autonomous Systems 197 in the local confederation that the UPDATE message has 198 traversed 200 4. Operation 202 A member of a BGP confederation MUST use its AS Confederation 203 Identifier in all transactions with peers that are not members of its 204 confederation. This AS confederation identifier is the "externally 205 visible" AS number and this number is used in OPEN messages and 206 advertised in the AS_PATH attribute. 208 A member of a BGP confederation MUST use its Member-AS Number in all 209 transactions with peers that are members of the same confederation as 210 the local BGP speaker. 212 A BGP speaker receiving an AS_PATH attribute containing an autonomous 213 system matching its own AS Confederation Identifier SHALL treat the 214 path in the same fashion as if it had received a path containing its 215 own AS number. 217 A BGP speaker receiving an AS_PATH attribute containing an 218 AS_CONFED_SEQUENCE or AS_CONFED_SET which contains its own Member-AS 219 Number SHALL treat the path in the same fashion as if it had received 220 a path containing its own AS number. 222 4.1. AS_PATH Modification Rules 224 When implementing BGP Confederations Section 5.1.2 of [BGP-4] is 225 replaced with the following text: 227 When a BGP speaker propagates a route which it has learned from 228 another BGP speaker's UPDATE message, it SHALL modify the route's 229 AS_PATH attribute based on the location of the BGP speaker to which 230 the route will be sent: 232 a) When a given BGP speaker advertises the route to another BGP 233 speaker located in its own Member-AS, the advertising speaker 234 SHALL NOT modify the AS_PATH attribute associated with the 235 route. 237 b) When a given BGP speaker advertises the route to a BGP speaker 238 located in a neighboring autonomous system that is a member of 239 the local confederation, the advertising speaker SHALL update 240 the AS_PATH attribute as follows: 242 1) if the first path segment of the AS_PATH is of type 243 AS_CONFED_SEQUENCE, the local system SHALL prepend its own 244 Member-AS Number as the last element of the sequence (put 245 it in the leftmost position). 247 2) if the first path segment of the AS_PATH is not of type 248 AS_CONFED_SEQUENCE the local system SHALL prepend a new path 249 segment of type AS_CONFED_SEQUENCE to the AS_PATH, including 250 its own Member-AS Number in that segment. 252 c) When a given BGP speaker advertises the route to a BGP speaker 253 located in a neighboring autonomous system that is not a member of 254 the local confederation, the advertising speaker SHALL update the 255 AS_PATH attribute as follows: 257 1) if any path segments of the AS_PATH are of the type 258 AS_CONFED_SEQUENCE or AS_CONFED_SET, those segments MUST 259 be removed from the AS_PATH attribute, leaving the sanitized 260 AS_PATH attribute to be operated on by steps 2 or 3. 262 2) if the first path segment of the remaining AS_PATH is of type 263 AS_SEQUENCE, the local system SHALL prepend its own 264 AS Confederation Identifier as the last element of the sequence 265 (put it in the leftmost position). 267 3) if there are no path segments following the removal of the 268 first AS_CONFED_SET/AS_CONFED_SEQUENCE segments, or if the 269 first path segment of the remaining AS_PATH is not of type 270 AS_SEQUENCE the local system SHALL prepend a new path segment 271 of type AS_SEQUENCE to the AS_PATH, including its own AS 272 Confederation Identifier in that segment. 274 When a BGP speaker originates a route: 276 a) the originating speaker SHALL include an empty AS_PATH attribute 277 in all UPDATE messages sent to BGP speakers residing within the 278 same Member-AS. (An empty AS_PATH attribute is one whose length 279 field contains the value zero). 281 b) the originating speaker SHALL include its own Member-AS Number in 282 an AS_CONFED_SEQUENCE segment of the AS_PATH attribute of all 283 UPDATE messages sent to BGP speakers located in neighboring 284 Member Autonomous Systems that are members of the local 285 confederation (i.e., the originating speaker's Member-AS Number 286 will be the only entry in the AS_PATH attribute). 288 c) the originating speaker SHALL include its own AS Confederation 289 Identifier in an AS_SEQUENCE segment of the AS_PATH attribute of 290 all UPDATE messages sent to BGP speakers located in neighboring 291 autonomous systems that are not members of the local 292 confederation. (In this case, the originating speaker's AS 293 Confederation Identifier will be the only entry in the AS_PATH 294 attribute). 296 5. Error Handling 298 A BGP speaker MUST NOT transmit updates containing AS_CONFED_SET or 299 AS_CONFED_SEQUENCE attributes to peers that are not members of the 300 local confederation. 302 It is an error for a BGP speaker to receive an update message with an 303 AS_PATH attribute which contains AS_CONFED_SEQUENCE or AS_CONFED_SET 304 segments from a neighbor which is not located in the same 305 confederation. If a BGP speaker receives such an update message, it 306 SHALL treat the message as having a malformed AS_PATH according to 307 the procedures of [BGP-4] Section 6.3 ("UPDATE message error 308 handling"). 310 It is a error for a BGP speaker to receive an update message from a 311 confederation peer which is not in the same Member-AS that does not 312 have AS_CONFED_SEQUENCE as the first segment. If a BGP speaker 313 receives such an update message, it SHALL treat the message as having 314 a malformed AS_PATH according to the procedures of [BGP-4] Section 315 6.3 ("Update message error handling"). 317 5.1. Common Administrative Issues 319 It is reasonable for Member Autonomous Systems of a confederation to 320 share a common administration and IGP information for the entire 321 confederation. It is also reasonable for each Member-AS to run an 322 independent IGP. In the latter case, the NEXT_HOP may need to be set 323 using policy (i.e., by default it is unchanged). 325 5.2. MED and LOCAL_PREF Handling 327 It SHALL be legal for a BGP speaker to advertise an unchanged 328 NEXT_HOP and MULTI_EXIT_DISC (MED) attribute to peers in a 329 neighboring Member-AS of the local confederation. 331 MEDs of two routes SHOULD only be compared if the first autonomous 332 systems in the first AS_SEQUENCE in both routes are the same - i.e., 333 skip all the autonomous systems in the AS_CONFED_SET and 334 AS_CONFED_SEQUENCE. An implementation MAY provide the ability to 335 configure path selection such that MEDs of two routes are comparable 336 if the first autonomous systems in the AS_PATHs are the same, 337 regardless of AS_SEQUENCE or AS_CONFED_SEQUENCE in the AS_PATH. 339 An implementation MAY compare MEDs received from a Member-AS via 340 multiple paths. An implementation MAY compare MEDs from different 341 Member Autonomous Systems of the same confederation. 343 In addition, the restriction against sending the LOCAL_PREF attribute 344 to peers in a neighboring autonomous system within the same 345 confederation is removed. 347 5.3. AS_PATH and Path Selection 349 Path selection criteria for information received from members inside 350 a confederation MUST follow the same rules used for information 351 received from members inside the same autonomous system, as specified 352 in [BGP-4]. 354 In addition, the following rules SHALL be applied: 356 1) If the AS_PATH is internal to the local confederation (i.e., there 357 are only AS_CONFED_* segments) consider the neighbor AS to be the 358 local AS. 360 2) Otherwise, if the first segment in the path which is not an 361 AS_CONFED_SEQUENCE or AS_CONFED_SET is an AS_SEQUENCE, consider 362 the neighbor AS to be the leftmost AS_SEQUENCE AS. 364 3) When comparing routes using AS_PATH length, CONFED_SEQUENCE and 365 CONFED_SETs SHOULD NOT be counted. 367 4) When comparing routes using the internal (iBGP learned) versus 368 external (eBGP learned) rules, treat a route that is learned from 369 a peer which is in the same confederation (not necessarily the 370 same Member-AS) as "internal". 372 6. Compatability Considerations 374 All BGP speakers participating as member of a confederation MUST 375 recognize the AS_CONFED_SET and AS_CONFED_SEQUENCE segment type 376 extensions to the AS_PATH attribute. 378 Any BGP speaker not supporting these extensions will generate a 379 NOTIFICATION message specifying an "UPDATE Message Error" and a sub- 380 code of "Malformed AS_PATH". 382 This compatibility issue implies that all BGP speakers participating 383 in a confederation MUST support BGP confederations. However, BGP 384 speakers outside the confederation need not support these extensions. 386 7. Deployment Considerations 388 BGP confederations have been widely deployed throughout the Internet 389 for a number of years and are supported by multiple vendors. 391 Improper configuration of BGP confederations can cause routing 392 information within an AS to be duplicated unnecessarily. This 393 duplication of information will waste system resources, cause 394 unnecessary route flaps, and delay convergence. 396 Care should be taken to manually filter duplicate advertisements 397 caused by reachability information being relayed through multiple 398 Member Autonomous Systems based upon the topology and redundancy 399 requirements of the confederation. 401 Additionally, confederations (as well as route reflectors), by 402 excluding different reachability information from consideration at 403 different locations in a confederation, have been shown [RFC 3365] to 404 cause permanent oscillation between candidate routes when using the 405 tie breaking rules required by BGP [BGP-4]. Care must be taken when 406 selecting MED values and tie breaking policy to avoid these 407 situations. 409 One potential way to avoid this is by configuring inter-Member-AS IGP 410 metrics higher than intra-Member-AS IGP metrics and/or using other 411 tie breaking policies to avoid BGP route selection based on 412 incomparable MEDs. 414 8. Security Considerations 416 This extension to BGP does not change the underlying security issues 417 inherent in the existing BGP protocol, such as those described in 418 [RFC 2385] and [BGP-VULN]. 420 9. Acknowledgments 422 The general concept of BGP confederations was taken from IDRP's 423 Routing Domain Confederations [ISO 10747]. Some of the introductory 424 text in this document was taken from [RFC 2796]. 426 The authors would like to acknowledge Jeffrey Haas for his extensive 427 feedback on this document. We'd also like to thank Bruce Cole, 428 Srihari Ramachandra, Alex Zinin, Naresh Kumar Paliwal, Jeffrey Haas, 429 Cengiz Alaettinoglu, Mike Hollyman and Bruno Rijsman for their 430 feedback and suggestions. 432 Finally, we'd like to acknowledge Ravi Chandra and Yakov Rekhter for 433 providing constructive and valuable feedback on earlier versions of 434 this specification. 436 10. IANA Considerations 438 This spefication introduces no new IANA considerations and therefore 439 requires no actions on the part of IANA. 441 11. References 443 11.1. Normative References 445 [BGP-4] Rekhter, Y., Li, T., and Hares, S., "A Border Gateway 446 Protocol 4", RFC 4271. 448 [RFC 1965] Traina, P. "Autonomous System Confederations for BGP", 449 RFC 1965, June 1996. 451 [RFC 3065] Traina, P., McPherson, D. and Scudder, J., "Autonomous 452 System Confederations for BGP", RFC 3065, February 2001. 454 11.2. Informative References 456 [ISO 10747] Kunzinger, C., Editor, "Inter-Domain Routing Protocol", 457 ISO/IEC 10747, October 1993. 459 [RFC 1863] Haskin, D., "A BGP/IDRP Route Server alternative to a 460 full mesh routing", RFC 1863, October 1995. 462 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 463 Requirement Levels", RFC 2119, March 1997. 465 [RFC 2385] Heffernan, A., "Protection of BGP Sessions via the TCP 466 MD5 Signature Option", RFC 2385, August 1998. 468 [RFC 2796] Bates, T., Chandra, R. and E. Chen, "BGP Route Reflection 469 An Alternative to Full Mesh IBGP", RFC 2796, April 2000. 471 [RFC 3365] McPherson, D., Gill, V., Walton, D., Retana, A., "Border 472 Gateway Protocol (BGP) Persistent Route Oscillation Condition", 473 RFC 3345, August 2002. 475 [BGP-VULN] Murphy, S., "BGP Security Vulnerabilities Analysis", 476 Internet-Draft, "Work in Progress". 478 12. Appendix A: Aggregate Routing Information 480 As a practical matter, aggregation as discussed in [BGP-4] section 481 9.2.2.2 is not generally employed within confederations. However, in 482 the event that such aggregation is performed within a confederation, 483 the rules of [BGP-4] should be followed, making the necessary 484 substitutions between AS_SET and AS_CONFED_SET and similarly, 485 AS_SEQUENCE and AS_CONFED_SEQUENCE. Confederation-type segments 486 (AS_CONFED_SET and AS_CONFED_SEQUENCE) MUST be kept separate from 487 non-confederation segments (AS_SET and AS_SEQUENCE). An 488 implementation could also choose to provide a form of aggregation 489 wherein non-confederation segments are aggregated as discussed in 490 [BGP-4] section 9.2.2.2 and confederation-type segments are not 491 aggregated. 493 Support for aggregation of confederation-type segments is not 494 mandatory. 496 13. Appendix B: Changes From RFC 3065 498 The primary trigger for an update to RFC 3065 was regarding issues 499 associated with AS path segment handling, in particular what to do 500 when interacting with BGP peers external to a confederation and to 501 ensure AS_CONFED_[SET|SEQUENCE] segment types are not propagated to 502 peers outside of a confederation. 504 As such, the "Error Handling" section above was added and applies not 505 only to explicitly call attention to BGP Confederation speakers, but 506 to all BGP speakers. 508 Other changes are mostly trivial and surrounding some clarification 509 and consistency in terminology and denoting that 510 AS_CONFED_[SET|SEQUENCE] Segment Type handling should be just as it 511 is in the base BGP specification [BGP-4]. 513 14. Authors' Addresses 514 Paul Traina 515 Blissfully Retired 516 Email: bgp-confederations st04.pst.org 518 Danny McPherson 519 Arbor Networks 520 EMail: danny@arbor.net 522 John G. Scudder 523 Juniper Networks 524 EMail: jgs@juniper.net 526 Intellectual Property Statement 528 The IETF takes no position regarding the validity or scope of any 529 Intellectual Property Rights or other rights that might be claimed to 530 pertain to the implementation or use of the technology described in 531 this document or the extent to which any license under such rights 532 might or might not be available; nor does it represent that it has 533 made any independent effort to identify any such rights. Information 534 on the procedures with respect to rights in RFC documents can be 535 found in BCP 78 and BCP 79. 537 Copies of IPR disclosures made to the IETF Secretariat and any 538 assurances of licenses to be made available, or the result of an 539 attempt made to obtain a general license or permission for the use of 540 such proprietary rights by implementers or users of this 541 specification can be obtained from the IETF on-line IPR repository at 542 http://www.ietf.org/ipr. 544 The IETF invites any interested party to bring to its attention any 545 copyrights, patents or patent applications, or other proprietary 546 rights that may cover technology that may be required to implement 547 this standard. Please address the information to the IETF at 548 ietf-ipr@ietf.org. 550 Copyright Statement 552 Copyright (C) The IETF Trust (2007). 554 This document is subject to the rights, licenses and restrictions 555 contained in BCP 78, and except as set forth therein, the authors 556 retain all their rights. 558 This document and the information contained herein are provided on an 559 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 560 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 561 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 562 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 563 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 564 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 565 PURPOSE. 567 Acknowledgment 569 Funding for the RFC Editor function is provided by the IETF 570 Administrative Support Activity (IASA).