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/