draft-ietf-idr-bgp-analysis-05.txt | draft-ietf-idr-bgp-analysis-06.txt | |||
---|---|---|---|---|
INTERNET-DRAFT D. Meyer | INTERNET-DRAFT D. Meyer | |||
draft-ietf-idr-bgp-analysis-05.txt K. Patel | draft-ietf-idr-bgp-analysis-06.txt K. Patel | |||
Category Informational | Category Informational | |||
Expires: December 2004 June 2004 | Expires: February 2005 August 2004 | |||
BGP-4 Protocol Analysis | BGP-4 Protocol Analysis | |||
<draft-ietf-idr-bgp-analysis-05.txt> | <draft-ietf-idr-bgp-analysis-06.txt> | |||
Status of this Document | Status of this Memo | |||
This document is an Internet-Draft and is subject to all provisions | Status of this Memo | |||
of Section 10 of RFC2026. | ||||
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 become aware will be | ||||
disclosed, in accordance with RFC 3668. | ||||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as | |||
Drafts. | Internet-Drafts. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six | |||
and may be updated, replaced, or obsoleted by other documents at any | months and may be updated, replaced, or obsoleted by other | |||
time. It is inappropriate to use Internet-Drafts as reference | documents at any time. It is inappropriate to use | |||
material or to cite them other than as "work in progress." | Internet-Drafts as reference material or to cite them other than | |||
as "work in progress." | ||||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/1id-abstracts.html | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html | http://www.ietf.org/shadow.html. | |||
This document is a product of the IDR Working Group WG. Comments | This document is a product of the IDR Working Group WG. Comments should be | |||
should be addressed to the authors, or the mailing list at | addressed to the authors, or the mailing list at idr@ietf.org. | |||
idr@ietf.org. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2004). All Rights Reserved. | Copyright (C) The Internet Society (2004). All Rights Reserved. | |||
Abstract | Abstract | |||
The purpose of this report is to document how the requirements for | The purpose of this report is to document how the requirements for | |||
advancing a routing protocol from Draft Standard to full Standard | advancing a routing protocol from Draft Standard to full Standard | |||
have been satisfied by Border Gateway Protocol version 4 (BGP-4). | have been satisfied by Border Gateway Protocol version 4 (BGP-4). | |||
skipping to change at page 2, line 39 | skipping to change at page 3, line 27 | |||
6.1.1. CPU utilization. . . . . . . . . . . . . . . . . . . . . 9 | 6.1.1. CPU utilization. . . . . . . . . . . . . . . . . . . . . 9 | |||
6.1.2. Memory requirements. . . . . . . . . . . . . . . . . . . 10 | 6.1.2. Memory requirements. . . . . . . . . . . . . . . . . . . 10 | |||
7. BGP Policy Expressiveness and its Implications . . . . . . . . 11 | 7. BGP Policy Expressiveness and its Implications . . . . . . . . 11 | |||
7.1. Existence of Unique Stable Routings . . . . . . . . . . . . 12 | 7.1. Existence of Unique Stable Routings . . . . . . . . . . . . 12 | |||
7.2. Existence of Stable Routings. . . . . . . . . . . . . . . . 13 | 7.2. Existence of Stable Routings. . . . . . . . . . . . . . . . 13 | |||
8. Applicability. . . . . . . . . . . . . . . . . . . . . . . . . 14 | 8. Applicability. . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 15 | 9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | |||
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 | 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 | |||
12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 17 | 12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
12.1. Informative References . . . . . . . . . . . . . . . . . . 17 | 12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . . 18 | ||||
13. Author's Addresses. . . . . . . . . . . . . . . . . . . . . . 19 | 13. Author's Addresses. . . . . . . . . . . . . . . . . . . . . . 19 | |||
14. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 19 | ||||
15. Intellectual Property . . . . . . . . . . . . . . . . . . . . 20 | ||||
16. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 20 | ||||
1. Introduction | 1. Introduction | |||
BGP-4 is an inter-autonomous system routing protocol designed for | BGP-4 is an inter-autonomous system routing protocol designed for | |||
TCP/IP internets. Version 1 of the BGP-4 protocol was published in | TCP/IP internets. Version 1 of the BGP-4 protocol was published in | |||
[RFC1105]. Since then BGP versions 2, 3, and 4 have been developed. | [RFC1105]. Since then BGP versions 2, 3, and 4 have been developed. | |||
Version 2 was documented in [RFC1163]. Version 3 is documented in | Version 2 was documented in [RFC1163]. Version 3 is documented in | |||
[RFC1267]. Version 4 is documented in the [BGP4] (version 4 of BGP | [RFC1267]. Version 4 is documented in the [BGP4] (version 4 of BGP | |||
will hereafter be referred to as BGP). The changes between versions | will hereafter be referred to as BGP). The changes between versions | |||
are explained in Appendix A of [BGP4]. Possible applications of BGP | are explained in Appendix A of [BGP4]. Possible applications of BGP | |||
skipping to change at page 2, line 96 | skipping to change at page 5, line 14 | |||
Path attributes provide BGP with flexibility and extensibility. Path | Path attributes provide BGP with flexibility and extensibility. Path | |||
attributes are partitioned into well-known and optional. The | attributes are partitioned into well-known and optional. The | |||
provision for optional attributes allows experimentation that may | provision for optional attributes allows experimentation that may | |||
involve a group of BGP routers without affecting the rest of the | involve a group of BGP routers without affecting the rest of the | |||
Internet. New optional attributes can be added to the protocol in | Internet. New optional attributes can be added to the protocol in | |||
much the same way that new options are added to, say, the Telnet | much the same way that new options are added to, say, the Telnet | |||
protocol [RFC854]. | protocol [RFC854]. | |||
One of the most important path attributes is the Autonomous System | One of the most important path attributes is the Autonomous System | |||
Path, or AS_PATH. Autonomous System's (AS) reachability information | Path, or AS_PATH. As the reachability information traverses the | |||
traverses the Internet, this information is augmented by the list of | Internet, this (AS_PATH) information is augmented by the list of | |||
autonomous systems that have been traversed thus far, forming the | autonomous systems that have been traversed thus far, forming the | |||
AS_PATH. The AS_PATH allows straightforward suppression of the | AS_PATH. The AS_PATH allows straightforward suppression of the | |||
looping of routing information. In addition, the AS_PATH serves as a | looping of routing information. In addition, the AS_PATH serves as a | |||
powerful and versatile mechanism for policy-based routing. | powerful and versatile mechanism for policy-based routing. | |||
BGP enhances the AS_PATH attribute to include sets of autonomous | BGP enhances the AS_PATH attribute to include sets of autonomous | |||
systems as well as lists via the AS_SET attribute. This extended | systems as well as lists via the AS_SET attribute. This extended | |||
format allows generated aggregate routes to carry path information | format allows generated aggregate routes to carry path information | |||
from the more specific routes used to generate the aggregate. It | from the more specific routes used to generate the aggregate. It | |||
should be noted however, that as of this writing, AS_SETs are rarely | should be noted however, that as of this writing, AS_SETs are rarely | |||
skipping to change at page 2, line 257 | skipping to change at page 9, line 4 | |||
Immediately after the initial BGP connection setup, BGP peers | Immediately after the initial BGP connection setup, BGP peers | |||
exchange complete set of routing information. If we denote the total | exchange complete set of routing information. If we denote the total | |||
number of routes in the Internet by N, the total path attributes (for | number of routes in the Internet by N, the total path attributes (for | |||
all N routes) received from a peer as A, and assume that the networks | all N routes) received from a peer as A, and assume that the networks | |||
are uniformly distributed among the autonomous systems, then the | are uniformly distributed among the autonomous systems, then the | |||
worst case amount of bandwidth consumed during the initial exchange | worst case amount of bandwidth consumed during the initial exchange | |||
between a pair of BGP speakers (P) is | between a pair of BGP speakers (P) is | |||
BW = O((N + A) * P) | BW = O((N + A) * P) | |||
The following table illustrates the typical amount of bandwidth | ||||
consumed during the initial exchange between a pair of BGP-4 speakers | ||||
based on the above assumptions (ignoring bandwidth consumed by the | ||||
BGP-4 Header). For purposes of the estimates here, we will calculate | ||||
BW = (((4 * N) + A) * P). | ||||
BGP-4 was created specifically to reduce the size of the set of NLRI | BGP-4 was created specifically to reduce the size of the set of NLRI | |||
entries which have to be carried and exchanged by border routers. | entries which have to be carried and exchanged by border routers. | |||
The aggregation scheme, defined in [RFC1519],describes the provider- | The aggregation scheme, defined in [CIDR],describes the provider- | |||
based aggregation scheme in use in today's Internet. | based aggregation scheme in use in today's Internet. | |||
Due to the advantages of advertising a few large aggregate blocks | Due to the advantages of advertising a few large aggregate blocks | |||
instead of many smaller class-based individual networks, it is | instead of many smaller class-based individual networks, it is | |||
difficult to estimate the actual reduction in bandwidth and | difficult to estimate the actual reduction in bandwidth and | |||
processing that BGP-4 has provided over BGP-3. If we simply | processing that BGP-4 has provided over BGP-3. If we simply | |||
enumerate all aggregate blocks into their individual class-based | enumerate all aggregate blocks into their individual class-based | |||
networks, we would not take into account "dead" space that has been | networks, we would not take into account "dead" space that has been | |||
reserved for future expansion. The best metric for determining the | reserved for future expansion. The best metric for determining the | |||
success of BGP's aggregation is to sample the number NLRI entries in | success of BGP's aggregation is to sample the number NLRI entries in | |||
the globally connected Internet today and compare it to projected | the globally connected Internet today and compare it to projected | |||
growth rates before BGP was deployed. | growth rates before BGP was deployed. | |||
At the time of this writing, the full set of exterior routes carried | At the time of this writing, the full set of exterior routes carried | |||
by BGP is approximately 120,000 network entries [ROUTEVIEWS]. | by BGP is approximately 134,000 network entries [ROUTEVIEWS]. | |||
6.1.1. CPU utilization | 6.1.1. CPU utilization | |||
An important and fundamental feature of BGP is that BGP's CPU | An important and fundamental feature of BGP is that BGP's CPU | |||
utilization depends only on the stability of its network which | utilization depends only on the stability of its network which | |||
relates to BGP in terms of BGP UPDATE message announcments. If the | relates to BGP in terms of BGP UPDATE message announcments. If the | |||
BGP network is stable: all the BGP routers within its network are in | BGP network is stable: all the BGP routers within its network are in | |||
the steady state; then the only link bandwidth and router CPU cycles | the steady state; then the only link bandwidth and router CPU cycles | |||
consumed by BGP are due to the exchange of the BGP KEEPALIVE | consumed by BGP are due to the exchange of the BGP KEEPALIVE | |||
messages. The KEEPALIVE messages are exchanged only between peers. | messages. The KEEPALIVE messages are exchanged only between peers. | |||
The suggested frequency of the exchange is 30 seconds. The KEEPALIVE | The suggested frequency of the exchange is 30 seconds. The KEEPALIVE | |||
messages are quite short (19 octets), and require virtually no | messages are quite short (19 octets), and require virtually no | |||
processing. As a result, the bandwidth consumed by the KEEPALIVE | processing. As a result, the bandwidth consumed by the KEEPALIVE | |||
messages is about 5 bits/sec. Operational experience confirms that | messages is about 5 bits/sec. Operational experience confirms that | |||
the overhead (in terms of bandwidth and CPU) associated with the | the overhead (in terms of bandwidth and CPU) associated with the | |||
KEEPALIVE messages should be viewed as negligible. | KEEPALIVE messages should be viewed as negligible. | |||
During the periods of network instability, BGP routers within the | During the periods of network instability, BGP routers within the | |||
network are generating routing updates that are exchanged using the | network are generating routing updates that are exchanged using the | |||
BGP UPDATE messages. The greatest overhead per UPDATE message occurs | BGP UPDATE messages. The greatest overhead per UPDATE message occurs | |||
when each UPDATE message contains only a single network. It should | when each UPDATE message contains only a single network. It should be | |||
pointed out that in practice routing changes exhibit strong locality | pointed out that in practice routing changes exhibit strong locality | |||
with respect to the route attributes. That is, routes that change | with respect to the route attributes. That is, routes that change | |||
are likely to have common route attributes. In this case, multiple | are likely to have common route attributes. In this case, multiple | |||
networks can be grouped into a single UPDATE message, thus | networks can be grouped into a single UPDATE message, thus | |||
significantly reducing the amount of bandwidth required (see also | significantly reducing the amount of bandwidth required (see also | |||
Appendix F.1 of [BGP4]). | Appendix F.1 of [BGP4]). | |||
6.1.2. Memory requirements | 6.1.2. Memory requirements | |||
To quantify the worst case memory requirements for BGP, we denote the | To quantify the worst case memory requirements for BGP, we denote the | |||
skipping to change at page 2, line 573 | skipping to change at page 17, line 12 | |||
protocol to provide authentication and security for its routing | protocol to provide authentication and security for its routing | |||
information; some of which include [SBGP] and [SOBGP]. | information; some of which include [SBGP] and [SOBGP]. | |||
11. IANA Considerations | 11. IANA Considerations | |||
This document presents an analysis of the BGP protocol and hence | This document presents an analysis of the BGP protocol and hence | |||
presents no new IANA considerations. | presents no new IANA considerations. | |||
12. References | 12. References | |||
12.1. Informative References | 12.1. Normative References | |||
[BGP4] Rekhter, Y., T. Li., and S. Hares, Editors, "A | [BGP4] Rekhter, Y., T. Li., and S. Hares, Editors, "A | |||
Border Gateway Protocol 4 (BGP-4)", | Border Gateway Protocol 4 (BGP-4)", | |||
draft-ietf-idr-bgp4-20.txt. Work in progress. | draft-ietf-idr-bgp4-20.txt. Work in progress. | |||
[CIDR] Fuller, V., Li, T., Yu, J., and K. Varadhan, | [CIDR] Fuller, V., Li, T., Yu, J., and K. Varadhan, | |||
"Classless Inter-Domain Routing (CIDR): an Address | "Classless Inter-Domain Routing (CIDR): an Address | |||
Assignment and Aggregation Strategy", RFC 1519, | Assignment and Aggregation Strategy", RFC 1519, | |||
September, 1993. | September, 1993. | |||
[RFC791] "INTERNET PROTOCOL", DARPA INTERNET PROGRAM | [RFC791] "INTERNET PROTOCOL", DARPA INTERNET PROGRAM | |||
PROTOCOL SPECIFICATION, RFC 791, September, | PROTOCOL SPECIFICATION, RFC 791, September, | |||
1981. | 1981. | |||
[RFC1997] Chandra. R, and T. Li, "BGP Communities | ||||
Attribute", RFC 1997, August, 1996. | ||||
[RFC2842] Chandra, R. and J. Scudder, "Capabilities | ||||
Advertisement with BGP-4", RFC 2842, May 2000. | ||||
[RFC3345] McPherson, D., Gill, V., Walton, D., and | ||||
A. Retana, "Border Gateway Protocol (BGP) Persistent | ||||
Route Oscillation Condition", RFC 3345, | ||||
August, 2002. | ||||
[BTSH] Gill, V., Heasley, J., and D. Meyer, "The BGP TTL | ||||
Security Hack (BTSH)", draft-gill-btsh-02.txt. | ||||
Work in progress. | ||||
[RFC2385] Heffernan, A., "Protection of BGP Sessions via | ||||
the TCP MD5 Signature Option", RFC 2385, | ||||
August, 1998. | ||||
[RFC3562] Leech, M., "Key Management Considerations for | ||||
the TCP MD5 Signature Option", RFC 3562, | ||||
July, 2003. | ||||
[soBGP] White, R., "Architecture and Deployment Considerations for | ||||
Secure Origin BGP (soBGP)", Internet-Draft, Work in Progress. | ||||
[BGP_VULN] Murphy, S., "BGP Security Vulnerabilities Analysis", | ||||
draft-ietf-idr-bgp-vuln-00.txt. work in progress | ||||
[SBGP] Lynn, C., Mikkelson, J., and K. Seo, "Secure BGP S-BGP", | ||||
Internet-Draft, Work in Progress. | ||||
12.2. Informative References | ||||
[RFC854] Postel, J. and J. Reynolds, "TELNET PROTOCOL | [RFC854] Postel, J. and J. Reynolds, "TELNET PROTOCOL | |||
SPECIFICATION", RFC 854, May, 1983. | SPECIFICATION", RFC 854, May, 1983. | |||
[RFC1105] Lougheed, K., and Y. Rekhter, "Border Gateway | [RFC1105] Lougheed, K., and Y. Rekhter, "Border Gateway | |||
Protocol BGP", RFC 1105, June 1989. | Protocol BGP", RFC 1105, June 1989. | |||
[RFC1163] Lougheed, K., and Rekhter, Y, "Border Gateway | [RFC1163] Lougheed, K., and Rekhter, Y, "Border Gateway | |||
Protocol BGP", RFC 1105, June 1990. | Protocol BGP", RFC 1105, June 1990. | |||
[RFC1264] Hinden, R., "Internet Routing Protocol | [RFC1264] Hinden, R., "Internet Routing Protocol | |||
Standardization Criteria", RFC 1264, October 1991. | Standardization Criteria", RFC 1264, October 1991. | |||
[RFC1267] Lougheed, K., and Rekhter, Y, "Border Gateway | [RFC1267] Lougheed, K., and Rekhter, Y, "Border Gateway | |||
Protocol 3 (BGP-3)", RFC 1105, October 1991. | Protocol 3 (BGP-3)", RFC 1105, October 1991. | |||
[RFC1519] Fuller, V., Li. T., Yu J., and K. Varadhan, | ||||
"Classless Inter-Domain Routing (CIDR): an | ||||
Address Assignment and Aggregation Strategy", RFC | ||||
1519, September 1993. | ||||
[RFC1771] Rekhter, Y., and T. Li, "A Border Gateway | [RFC1771] Rekhter, Y., and T. Li, "A Border Gateway | |||
Protocol 4 (BGP-4)", RFC 1771, March 1995. | Protocol 4 (BGP-4)", RFC 1771, March 1995. | |||
[RFC1772] Rekhter, Y., and P. Gross, Editors, "Application | [RFC1772] Rekhter, Y., and P. Gross, Editors, "Application | |||
of the Border Gateway Protocol in the Internet", | of the Border Gateway Protocol in the Internet", | |||
RFC 1772, March 1995. | RFC 1772, March 1995. | |||
[RFC1774] Traina, P., "BGP-4 protocol analysis", | [RFC1774] Traina, P., "BGP-4 protocol analysis", | |||
RFC 1774, March, 1995. | RFC 1774, March, 1995. | |||
[RFC1997] Chandra. R, and T. Li, "BGP Communities | ||||
Attribute", RFC 1997, August, 1996. | ||||
[RFC2622] Alaettinoglu, C., et. al., "Routing Policy | [RFC2622] Alaettinoglu, C., et. al., "Routing Policy | |||
Specification Language (RPSL)" RFC 2622, May, | Specification Language (RPSL)" RFC 2622, May, | |||
1998. | 1998. | |||
[RFC2842] Chandra, R. and J. Scudder, "Capabilities | ||||
Advertisement with BGP-4", RFC 2842, May 2000. | ||||
[RFC3345] McPherson, D., Gill, V., Walton, D., and | ||||
A. Retana, "Border Gateway Protocol (BGP) Persistent | ||||
Route Oscillation Condition", RFC 3345, | ||||
August, 2002. | ||||
[BTSH] Gill, V., Heasley, J., and D. Meyer, "The BGP TTL | ||||
Security Hack (BTSH)", draft-gill-btsh-02.txt. | ||||
Work in progress. | ||||
[RFC2385] Heffernan, A., "Protection of BGP Sessions via | ||||
the TCP MD5 Signature Option", RFC 2385, | ||||
August, 1998. | ||||
[RFC3562] Leech, M., "Key Management Considerations for | ||||
the TCP MD5 Signature Option", RFC 3562, | ||||
July, 2003. | ||||
[RFC2406] Kent, S., Atkinson, R., "IP Encapsulating Security | [RFC2406] Kent, S., Atkinson, R., "IP Encapsulating Security | |||
Payload (ESP)", RFC 2406, November, 1998. | Payload (ESP)", RFC 2406, November, 1998. | |||
[ROUTEVIEWS] Meyer, D., "The Route Views Project", | [ROUTEVIEWS] Meyer, D., "The Route Views Project", | |||
http://www.routeviews.org | http://www.routeviews.org | |||
[SBGP] Lynn, C., Mikkelson, J., and K. Seo, "Secure BGP S-BGP", | ||||
Internet-Draft, Work in Progress. | ||||
[soBGP] White, R., "Architecture and Deployment Considerations for | ||||
Secure Origin BGP (soBGP)", Internet-Draft, Work in Progress. | ||||
[BGP_VULN] Murphy, S., "BGP Security Vulnerabilities Analysis", | ||||
draft-ietf-idr-bgp-vuln-00.txt. work in progress | ||||
13. Author's Addresses | 13. Author's Addresses | |||
David Meyer | David Meyer | |||
Email: dmm@1-4-5.net | Email: dmm@1-4-5.net | |||
Keyur Patel | Keyur Patel | |||
Cisco Systems | Cisco Systems | |||
Email: keyupate@cisco.com | Email: keyupate@cisco.com | |||
14. Full Copyright Statement | Intellectual Property Statement | |||
Copyright (C) The Internet Society (2004). This document is subject | ||||
to the rights, licenses and restrictions contained in BCP 78 and | ||||
except as set forth therein, the authors retain all their rights. | ||||
This document and translations of it may be copied and furnished to | ||||
others, and derivative works that comment on or otherwise explain it | ||||
or assist in its implementation may be prepared, copied, published | ||||
and distributed, in whole or in part, without restriction of any | ||||
kind, provided that the above copyright notice and this paragraph are | ||||
included on all such copies and derivative works. However, this | ||||
document itself may not be modified in any way, such as by removing | ||||
the copyright notice or references to the Internet Society or other | ||||
Internet organizations, except as needed for the purpose of | ||||
developing Internet standards in which case the procedures for | ||||
copyrights defined in the Internet Standards process must be | ||||
followed, or as required to translate it into languages other than | ||||
English. | ||||
The limited permissions granted above are perpetual and will not be | ||||
revoked by the Internet Society or its successors or assigns. | ||||
This document and the information contained herein is provided on an | ||||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | ||||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | ||||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | ||||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | ||||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
15. Intellectual Property | ||||
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |||
pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
this document or the extent to which any license under such rights | this document or the extent to which any license under such rights | |||
might or might not be available; nor does it represent that it has | might or might not be available; nor does it represent that it has | |||
made any independent effort to identify any such rights. Information | made any independent effort to identify any such rights. Information | |||
on the procedures with respect to rights in RFC documents can be | on the procedures with respect to rights in RFC documents can be | |||
found in BCP 78 and BCP 79. | found in BCP 78 and BCP 79. | |||
Copies of IPR disclosures made to the IETF Secretariat and any | Copies of IPR disclosures made to the IETF Secretariat and any | |||
assurances of licenses to be made available, or the result of an | assurances of licenses to be made available, or the result of an | |||
attempt made to obtain a general license or permission for the use of | attempt made to obtain a general license or permission for the use of | |||
such proprietary rights by implementers or users of this | such proprietary rights by implementers or users of this | |||
specification can be obtained from the IETF on-line IPR repository at | specification can be obtained from the IETF on-line IPR repository at | |||
http://www.ietf.org/ipr. | http://www.ietf.org/ipr. | |||
The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
this standard. Please address the information to the IETF at ietf- | this standard. Please address the information to the IETF at | |||
ipr@ietf.org. | ietf-ipr@ietf.org. | |||
16. Acknowledgement | Disclaimer of Validity | |||
This document and the information contained herein are provided on an | ||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | ||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | ||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | ||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | ||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
Copyright Statement | ||||
Copyright (C) The Internet Society (2004). This document is subject | ||||
to the rights, licenses and restrictions contained in BCP 78, and | ||||
except as set forth therein, the authors retain all their rights. | ||||
Acknowledgment | ||||
Funding for the RFC Editor function is currently provided by the | Funding for the RFC Editor function is currently provided by the | |||
Internet Society. | Internet Society. | |||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |