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/