draft-ietf-idr-bgp4-experience-protocol-04.txt		draft-ietf-idr-bgp4-experience-protocol-05.txt
	INTERNET-DRAFT Danny McPherson		INTERNET-DRAFT Danny McPherson
	Arbor Networks		Arbor Networks
	Keyur Patel		Keyur Patel
	Cisco Systems		Cisco Systems
	Category Informational		Category Informational
	Expires: November 2004 May 2004		Expires: March 2005 September 2004
	Experience with the BGP-4 Protocol		Experience with the BGP-4 Protocol
	<draft-ietf-idr-bgp4-experience-protocol-04.txt>		<draft-ietf-idr-bgp4-experience-protocol-05.txt>
	Status of this Document		Status of this Document
	This document is an Internet-Draft and is in full conformance with		By submitting this Internet-Draft, I certify that any applicable
	all provisions of Section 10 of RFC2026.		patent or other IPR claims of which I am aware have been disclosed,
			and any of which I 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 Internet-
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		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/ietf/1id-abstracts.txt		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.
	The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		This document is an individual submission. Comments are solicited and
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		should be addressed to the author(s).
	document are to be interpreted as described in RFC 2119 [RFC 2119].
	This document is a product of an individual. Comments are solicited
	and should be addressed to the author(s).
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	=0C
	Abstract		Abstract
	The purpose of this memo is to document how the requirements for		The purpose of this memo 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).
	This report satisfies the requirement for "the second report", as		This report satisfies the requirement for "the second report", as
	described in Section 6.0 of RFC 1264. In order to fulfill the		described in Section 6.0 of RFC 1264. In order to fulfill the
	requirement, this report augments RFC 1773 and describes additional		requirement, this report augments RFC 1773 and describes additional
	knowledge and understanding gained in the time between when the		knowledge and understanding gained in the time between when the
	protocol was made a Draft Standard and when it was submitted for		protocol was made a Draft Standard and when it was submitted for
	Standard.		Standard.
	=0C
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. BGP-4 Overview . . . . . . . . . . . . . . . . . . . . . . . . 4		2. BGP-4 Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. A Border Gateway Protocol . . . . . . . . . . . . . . . . . 4		2.1. A Border Gateway Protocol . . . . . . . . . . . . . . . . . 4
	3. Management Information Base (MIB). . . . . . . . . . . . . . . 5		3. Management Information Base (MIB). . . . . . . . . . . . . . . 5
	4. Implementation Information . . . . . . . . . . . . . . . . . . 5		4. Implementation Information . . . . . . . . . . . . . . . . . . 5
	5. Operational Experience . . . . . . . . . . . . . . . . . . . . 5		5. Operational Experience . . . . . . . . . . . . . . . . . . . . 5
	6. TCP Awareness. . . . . . . . . . . . . . . . . . . . . . . . . 6		6. TCP Awareness. . . . . . . . . . . . . . . . . . . . . . . . . 6
	7. Metrics. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		7. Metrics. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	skipping to change at page 3, line 35		skipping to change at page 3, line 34
	12. Update Packing. . . . . . . . . . . . . . . . . . . . . . . . 12		12. Update Packing. . . . . . . . . . . . . . . . . . . . . . . . 12
	13. Limit Rate Updates. . . . . . . . . . . . . . . . . . . . . . 13		13. Limit Rate Updates. . . . . . . . . . . . . . . . . . . . . . 13
	13.1. Consideration of TCP Characteristics . . . . . . . . . . . 14		13.1. Consideration of TCP Characteristics . . . . . . . . . . . 14
	14. Ordering of Path Attributes . . . . . . . . . . . . . . . . . 14		14. Ordering of Path Attributes . . . . . . . . . . . . . . . . . 14
	15. AS_SET Sorting. . . . . . . . . . . . . . . . . . . . . . . . 15		15. AS_SET Sorting. . . . . . . . . . . . . . . . . . . . . . . . 15
	16. Control over Version Negotiation. . . . . . . . . . . . . . . 15		16. Control over Version Negotiation. . . . . . . . . . . . . . . 15
	17. Security Considerations . . . . . . . . . . . . . . . . . . . 15		17. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	17.1. TCP MD5 Signature Option . . . . . . . . . . . . . . . . . 16		17.1. TCP MD5 Signature Option . . . . . . . . . . . . . . . . . 16
	17.2. BGP Over IPSEC . . . . . . . . . . . . . . . . . . . . . . 16		17.2. BGP Over IPSEC . . . . . . . . . . . . . . . . . . . . . . 16
	17.3. Miscellaneous. . . . . . . . . . . . . . . . . . . . . . . 17		17.3. Miscellaneous. . . . . . . . . . . . . . . . . . . . . . . 17
	17.4. PTOMAINE and GROW. . . . . . . . . . . . . . . . . . . . . 17		18. PTOMAINE and GROW . . . . . . . . . . . . . . . . . . . . . . 17
	17.5. Internet Routing Registries (IRRs) . . . . . . . . . . . . 17		19. Internet Routing Registries (IRRs). . . . . . . . . . . . . . 17
	17.6. Regional Internet Registries (RIRs) and IRRs,		20. Regional Internet Registries (RIRs) and IRRs, A
	A Bit of History . . . . . . . . . . . . . . . . . . . . . . . . 18		Bit of History. . . . . . . . . . . . . . . . . . . . . . . . . . 18
	17.7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 19		21. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 19
	18. References. . . . . . . . . . . . . . . . . . . . . . . . . . 20		22. References. . . . . . . . . . . . . . . . . . . . . . . . . . 20
	19. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 21		22.1. Normative References . . . . . . . . . . . . . . . . . . . 20
	20. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 22		22.2. Informative References . . . . . . . . . . . . . . . . . . 21
			23. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 21
	=0C
	1. Introduction		1. Introduction
	The purpose of this memo is to document how the requirements for		The purpose of this memo 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).
	This report satisfies the requirement for "the second report", as		This report satisfies the requirement for "the second report", as
	described in Section 6.0 of RFC 1264. In order to fulfill the		described in Section 6.0 of RFC 1264. In order to fulfill the
	requirement, this report augments RFC 1773 and describes additional		requirement, this report augments RFC 1773 and describes additional
	skipping to change at page 4, line 39		skipping to change at page 4, line 37
	pruned and some policy decisions at the AS level may be enforced.		pruned and some policy decisions at the AS level may be enforced.
	The initial version of the BGP protocol was published in RFC 1105.		The initial version of the BGP protocol was published in RFC 1105.
	Since then BGP Versions 2, 3, and 4 have been developed and are		Since then BGP Versions 2, 3, and 4 have been developed and are
	specified in [RFC 1163], [RFC 1267], and [RFC 1771], respectively.		specified in [RFC 1163], [RFC 1267], and [RFC 1771], respectively.
	Changes since BGP-4 went to Draft Standard [RFC 1771] are listed in		Changes since BGP-4 went to Draft Standard [RFC 1771] are listed in
	Appendix N of [BGP4].		Appendix N of [BGP4].
	2.1. A Border Gateway Protocol		2.1. A Border Gateway Protocol
	The Initial Version of BGP [RFC 1105]. BGP version 2 is defined in		The Initial Version of BGP protocol was published in [RFC 1105]. BGP
	[RFC 1163]. BGP version 3 is defined in [RFC 1267]. BGP version 4		version 2 is defined in [RFC 1163]. BGP version 3 is defined in [RFC
	is defined in [RFC 1771] and [BGP4]. Appendices A, B, C, and D of		1267]. BGP version 4 is defined in [RFC 1771] and [BGP4].
	[BGP4] provide summaries of the changes between each iteration of the		Appendices A, B, C, and D of [BGP4] provide summaries of the changes
	BGP specification.		between each iteration of the BGP specification.
	=0C
	3. Management Information Base (MIB)		3. Management Information Base (MIB)
	The BGP-4 Management Information Base (MIB) has been published [BGP-		The BGP-4 Management Information Base (MIB) has been published [BGP-
	MIB]. The MIB was updated from previous versions documented in [RFC		MIB]. The MIB was updated from previous versions documented in [RFC
	1657] and [RFC 1269], respectively.		1657] and [RFC 1269], respectively.
	Apart from a few system variables, the BGP MIB is broken into two		Apart from a few system variables, the BGP MIB is broken into two
	tables: the BGP Peer Table and the BGP Received Path Attribute Table.		tables: the BGP Peer Table and the BGP Received Path Attribute Table.
	skipping to change at page 6, line 4		skipping to change at page 6, line 4
	This section discusses operational experience with BGP and BGP-4.		This section discusses operational experience with BGP and BGP-4.
	BGP has been used in the production environment since 1989, BGP-4		BGP has been used in the production environment since 1989, BGP-4
	since 1993. Production use of BGP includes utilization of all		since 1993. Production use of BGP includes utilization of all
	significant features of the protocol. The present production		significant features of the protocol. The present production
	environment, where BGP is used as the inter-autonomous system routing		environment, where BGP is used as the inter-autonomous system routing
	protocol, is highly heterogeneous. In terms of the link bandwidth it		protocol, is highly heterogeneous. In terms of the link bandwidth it
	varies from 56 Kbps to 10 Gbps. In terms of the actual routers that		varies from 56 Kbps to 10 Gbps. In terms of the actual routers that
	run BGP, it ranges from a relatively slow performance general purpose		run BGP, it ranges from a relatively slow performance general purpose
	CPUs to very high performance RISC network processors, and includes		CPUs to very high performance RISC network processors, and includes
	=0C
	both special purpose routers and the general purpose workstations		both special purpose routers and the general purpose workstations
	running various UNIX derivatives and other operating systems.		running various UNIX derivatives and other operating systems.
	In terms of the actual topologies it varies from very sparse to quite		In terms of the actual topologies it varies from very sparse to quite
	dense. The requirement for full-mesh IBGP topologies has been		dense. The requirement for full-mesh IBGP topologies has been
	largely remedied by BGP Route Reflection, Autonomous System		largely remedied by BGP Route Reflection, Autonomous System
	Confederations for BGP, and often some mix of the two. BGP Route		Confederations for BGP, and often some mix of the two. BGP Route
	Reflection was initially defined in [RFC 1966] and subsequently		Reflection was initially defined in [RFC 1966] and subsequently
	updated in [RFC 2796]. Autonomous System Confederations for BGP were		updated in [RFC 2796]. Autonomous System Confederations for BGP were
	initially defined in [RFC 1965] and subsequently updated in [RFC		initially defined in [RFC 1965] and subsequently updated in [RFC
	skipping to change at page 7, line 4		skipping to change at page 7, line 4
	BGP employs TCP [RFC 793] as it's Transport Layer protocol. As such,		BGP employs TCP [RFC 793] as it's Transport Layer protocol. As such,
	all characteristics inherent to TCP are inherited by BGP.		all characteristics inherent to TCP are inherited by BGP.
	For example, due to TCP's behavior, bandwidth capabilities may not be		For example, due to TCP's behavior, bandwidth capabilities may not be
	realized due to TCP's slow start algorithms, and slow-start restarts		realized due to TCP's slow start algorithms, and slow-start restarts
	of connections, etc..		of connections, etc..
	7. Metrics		7. Metrics
	This section discusses different metrics used within the BGP		This section discusses different metrics used within the BGP
	=0C
	protocol. BGP has a separate metric parameter for IBGP and EBGP. This		protocol. BGP has a separate metric parameter for IBGP and EBGP. This
	allows policy based metrics to overwrite the distance based metrics;		allows policy based metrics to overwrite the distance based metrics;
	allowing each autonomous systems to define their independent policies		allowing each autonomous systems to define their independent policies
	in Intra-AS as well as Inter-AS. BGP Multi Exit Discriminator (MED)		in Intra-AS as well as Inter-AS. BGP Multi Exit Discriminator (MED)
	is used as a metric by EBGP peers (i.e., inter-domain) while Local		is used as a metric by EBGP peers (i.e., inter-domain) while Local
	Preference (LOCAL_PREF) is used by IBGP peers (i.e., intra-domain).		Preference (LOCAL_PREF) is used by IBGP peers (i.e., intra-domain).
	7.1. MULTI_EXIT_DISC (MED)		7.1. MULTI_EXIT_DISC (MED)
	BGP version 4 re-defined the old INTER-AS metric as a MULTI_EXIT_		BGP version 4 re-defined the old INTER-AS metric as a MULTI_EXIT_
	skipping to change at page 8, line 4		skipping to change at page 8, line 4
	generated from multiple locations in an AS in order to accommodate		generated from multiple locations in an AS in order to accommodate
	stability, redundancy and other network design goals. When MEDs are		stability, redundancy and other network design goals. When MEDs are
	derived from IGP metrics associated with said aggregates the MED		derived from IGP metrics associated with said aggregates the MED
	value advertised to peers can result in very suboptimal routing.		value advertised to peers can result in very suboptimal routing.
	The MED was purposely designed to be a "weak" metric that would only		The MED was purposely designed to be a "weak" metric that would only
	be used late in the best-path decision process. The BGP working		be used late in the best-path decision process. The BGP working
	group was concerned that any metric specified by a remote operator		group was concerned that any metric specified by a remote operator
	would only affect routing in a local AS if no other preference was		would only affect routing in a local AS if no other preference was
	specified. A paramount goal of the design of the MED was to ensure		specified. A paramount goal of the design of the MED was to ensure
	=0C
	that peers could not "shed" or "absorb" traffic for networks that		that peers could not "shed" or "absorb" traffic for networks that
	they advertise.		they advertise.
	7.1.1. MEDs and Potatoes		7.1.1. MEDs and Potatoes
	In a situation where traffic flows between a pair of destinations,		In a situation where traffic flows between a pair of destinations,
	each connected to two transit networks, each of the transit networks		each connected to two transit networks, each of the transit networks
	has the choice of either sending the traffic to the closest peering		has the choice of either sending the traffic to the closest peering
	to other transit provider or passing traffic to the peering which		to other transit provider or passing traffic to the peering which
	advertises the least cost through the other provider. The former		advertises the least cost through the other provider. The former
	method is called "hot potatoe routing" because like a hot potatoe		method is called "hot potato routing" because like a hot potato held
	held in bare hands, whoever has it tries to get rid of it quickly.		in bare hands, whoever has it tries to get rid of it quickly. Hot
	Hot potatoe routing is accomplished by not passing the EGBP learned		potato routing is accomplished by not passing the EGBP learned MED
	MED into IBGP. This minimizes transit traffic for the provider		into IBGP. This minimizes transit traffic for the provider routing
	routing the traffic. Far less common is "cold potatoe routing" where		the traffic. Far less common is "cold potato routing" where the
	the transit provider uses their own transit capacity to get the		transit provider uses their own transit capacity to get the traffic
	traffic to the point in the adjacent transit provider advertised as		to the point in the adjacent transit provider advertised as being
	being closest to the destination. Cold potatoe routing is		closest to the destination. Cold potato routing is accomplished by
	accomplished by passing the EBGP learned MED into IBGP.		passing the EBGP learned MED into IBGP.
	If one transit provider uses hot potatoe routing and another uses		If one transit provider uses hot potato routing and another uses cold
	cold potatoe, traffic between the two tends to be symetric.		potato, traffic between the two tends to be symetric. Depending on
	Depending on the business relationships, if one provider has more		the business relationships, if one provider has more capacity or a
	capacity or a significantly less congested transit network, then that		significantly less congested transit network, then that provider may
	provider may use cold potatoe routing. An example of widespread use		use cold potato routing. An example of widespread use of cold potato
	of cold potatoe routing was the NSF funded NSFNET backbone and NSF		routing was the NSF funded NSFNET backbone and NSF funded regional
	funded regional networks in the mid 1990s.		networks in the mid 1990s.
	In some cases a provider may use hot potatoe routing for some		In some cases a provider may use hot potato routing for some
	destinations for a given peer AS and cold potatoe routing for others.		destinations for a given peer AS and cold potato routing for others.
	An example of this is the different treatment of commercial and		An example of this is the different treatment of commercial and
	research traffic in the NSFNET in the mid 1990s. Then again, this		research traffic in the NSFNET in the mid 1990s. Then again, this
	might best be described as 'mashed potatoe routing', a term which		might best be described as 'mashed potato routing', a term which
	reflects the complexity of router configurations in use at the time.		reflects the complexity of router configurations in use at the time.
	Seemingly more intuitive references that fall outside the vegetable		Seemingly more intuitive references that fall outside the vegetable
	kingdom refer to cold potatoe routing as "best exit routing", and hot		kingdom refer to cold potato routing as "best exit routing", and hot
	potatoe routing as "closest exit routing", though vegetable.		potato routing as "closest exit routing".
	7.1.2. Sending MEDs to BGP Peers		7.1.2. Sending MEDs to BGP Peers
	[BGP4] allows MEDs received from any EBGP peers by a BGP speaker to		[BGP4] allows MEDs received from any EBGP peers by a BGP speaker to
	=0C
	be passed to its IBGP peers. Although advertising MEDs to IBGP peers		be passed to its IBGP peers. Although advertising MEDs to IBGP peers
	is not a required behavior, it is a common default. MEDs received		is not a required behavior, it is a common default. MEDs received
	from EBGP peers by a BGP speaker MUST NOT be sent to other EBGP		from EBGP peers by a BGP speaker SHOULD NOT be sent to other EBGP
	peers.		peers.
	Note that many implementations provide a mechanism to derive MED		Note that many implementations provide a mechanism to derive MED
	values from IGP metrics in order to allow BGP MED information to		values from IGP metrics in order to allow BGP MED information to
	reflect the IGP topologies and metrics of the network when		reflect the IGP topologies and metrics of the network when
	propagating information to adjacent autonomous systems.		propagating information to adjacent autonomous systems.
	7.1.3. MED of Zero Versus No MED		7.1.3. MED of Zero Versus No MED
	[BGP4] requires that an implementation must provide a mechanism that		[BGP4] requires that an implementation must provide a mechanism that
	skipping to change at page 10, line 4		skipping to change at page 10, line 4
	non-deterministic behavior, and as such, may often be undesirable.		non-deterministic behavior, and as such, may often be undesirable.
	8. Local Preference		8. Local Preference
	The LOCAL_PREF attribute was added so a network operator could easily		The LOCAL_PREF attribute was added so a network operator could easily
	configure a policy that overrode the standard best path determination		configure a policy that overrode the standard best path determination
	mechanism without independently configuring local preference policy		mechanism without independently configuring local preference policy
	on each router.		on each router.
	One shortcoming in the BGP-4 specification was a suggestion for a		One shortcoming in the BGP-4 specification was a suggestion for a
	=0C
	default value of LOCAL_PREF to be assumed if none was provided.		default value of LOCAL_PREF to be assumed if none was provided.
	Defaults of 0 or the maximum value each have range limitations, so a		Defaults of 0 or the maximum value each have range limitations, so a
	common default would aid in the interoperation of multi-vendor		common default would aid in the interoperation of multi-vendor
	routers in the same AS (since LOCAL_PREF is a local administration		routers in the same AS (since LOCAL_PREF is a local administration
	attribute, there is no interoperability drawback across AS		attribute, there is no interoperability drawback across AS
	boundaries).		boundaries).
	[BGP4] requires that LOCAL_PREF be sent to IBGP Peers and must not be		[BGP4] requires that LOCAL_PREF be sent to IBGP Peers and must not be
	sent to EBGP Peers. Although no default value for LOCAL_PREF is		sent to EBGP Peers. Although no default value for LOCAL_PREF is
	defined, the common default value is 100.		defined, the common default value is 100.
	skipping to change at page 11, line 4		skipping to change at page 11, line 4
	paramount concern, avoiding extensive hand configuration of routing		paramount concern, avoiding extensive hand configuration of routing
	policies needs to be examined more carefully in future BGP-like		policies needs to be examined more carefully in future BGP-like
	protocols.		protocols.
	9. Internal BGP In Large Autonomous Systems		9. Internal BGP In Large Autonomous Systems
	While not strictly a protocol issue, one other concern has been		While not strictly a protocol issue, one other concern has been
	raised by network operators who need to maintain autonomous systems		raised by network operators who need to maintain autonomous systems
	with a large number of peers. Each speaker peering with an external		with a large number of peers. Each speaker peering with an external
	router is responsible for propagating reachability and path		router is responsible for propagating reachability and path
	=0C
	information to all other transit and border routers within that AS.		information to all other transit and border routers within that AS.
	This is typically done by establishing internal BGP connections to		This is typically done by establishing internal BGP connections to
	all transit and border routers in the local AS.		all transit and border routers in the local AS.
	Note that the number of BGP peers that can be fully meshed depends on		Note that the number of BGP peers that can be fully meshed depends on
	a number of factors, to include number of prefixes in the routing		a number of factors, to include number of prefixes in the routing
	system, number of unique path, stability of the system, and perhaps		system, number of unique path, stability of the system, and perhaps
	most importantly, implementation efficiency. As a result, although		most importantly, implementation efficiency. As a result, although
	it's difficult to define "a large number of peers", there is always		it's difficult to define "a large number of peers", there is always
	some practical limit.		some practical limit.
	skipping to change at page 12, line 4		skipping to change at page 12, line 4
	BGP Route Flap Damping is defined in [RFC 2439]. BGP Route Flap		BGP Route Flap Damping is defined in [RFC 2439]. BGP Route Flap
	Damping defines a mechanism to help reduce the amount of routing		Damping defines a mechanism to help reduce the amount of routing
	information passed between BGP peers, and subsequently, the load on		information passed between BGP peers, and subsequently, the load on
	these peers, without adversely affecting route convergence time for		these peers, without adversely affecting route convergence time for
	relatively stable routes.		relatively stable routes.
	None of the current implementations of BGP Route Flap Damping store		None of the current implementations of BGP Route Flap Damping store
	route history by unique NRLI and AS Path although it is listed as		route history by unique NRLI and AS Path although it is listed as
	mandatory in RFC 2439. A potential result of failure to consider		mandatory in RFC 2439. A potential result of failure to consider
	=0C
	each AS Path separately is an overly aggressive suppression of		each AS Path separately is an overly aggressive suppression of
	destinations in a densely meshed network, with the most severe		destinations in a densely meshed network, with the most severe
	consequence being suppression of a destination after a single		consequence being suppression of a destination after a single
	failure. Because the top tier autonomous systems in the Internet are		failure. Because the top tier autonomous systems in the Internet are
	densely meshed, these adverse consequences are observed.		densely meshed, these adverse consequences are observed.
	Route changes are announced using BGP UPDATE messages. The greatest		Route changes are announced using BGP UPDATE messages. The greatest
	overhead in advertising UPDATE messages happens whenever route		overhead in advertising UPDATE messages happens whenever route
	changes to be announced are inefficiently packed. As discussed in a		changes to be announced are inefficiently packed. As discussed in a
	later section, announcing routing changes sharing common attributes		later section, announcing routing changes sharing common attributes
	skipping to change at page 13, line 4		skipping to change at page 13, line 4
	It may be desirable for an implementation to provide a knob that		It may be desirable for an implementation to provide a knob that
	permits advertisement of "inactive" BGP routes.		permits advertisement of "inactive" BGP routes.
	It may be also desirable for an implementation to provide a knob that		It may be also desirable for an implementation to provide a knob that
	allows a BGP speaker to advertise BGP routes that were not selected		allows a BGP speaker to advertise BGP routes that were not selected
	by decision process.		by decision process.
	12. Update Packing		12. Update Packing
	Multiple unfeasible routes can be advertised in a single BGP Update		Multiple unfeasible routes can be advertised in a single BGP Update
	=0C
	message. In addition, one or more feasible routes can be advertised		message. In addition, one or more feasible routes can be advertised
	in a single Update message so long as all prefixes share a common		in a single Update message so long as all prefixes share a common
	attribute set.		attribute set.
	The BGP4 protocol permits advertisement of multiple prefixes with a		The BGP4 protocol permits advertisement of multiple prefixes with a
	common set of path attributes to be advertised in a single update		common set of path attributes to be advertised in a single update
	message, this is commonly referred to as "update packing". When		message, this is commonly referred to as "update packing". When
	possible, update packing is recommended as it provides a mechanism		possible, update packing is recommended as it provides a mechanism
	for more efficient behavior in a number of areas, to include:		for more efficient behavior in a number of areas, to include:
	skipping to change at page 14, line 5		skipping to change at page 14, line 5
	parameter that determines the minimum time that must be elapse		parameter that determines the minimum time that must be elapse
	between the advertisement of routes to a particular destination from		between the advertisement of routes to a particular destination from
	a single BGP speaker. This value is set on a per BGP peer basis.		a single BGP speaker. This value is set on a per BGP peer basis.
	Due to the fact that BGP relies on TCP as the Transport protocol, TCP		Due to the fact that BGP relies on TCP as the Transport protocol, TCP
	can prevent transmission of data due to empty windows. As a result,		can prevent transmission of data due to empty windows. As a result,
	multiple Updates may be spaced closer together than orginally queued.		multiple Updates may be spaced closer together than orginally queued.
	Although this is not a common occurrence, implementations should be		Although this is not a common occurrence, implementations should be
	aware of this.		aware of this.
	=0C
	13.1. Consideration of TCP Characteristics		13.1. Consideration of TCP Characteristics
	If a TCP receiver is processing input more slowly than the sender or		If a TCP receiver is processing input more slowly than the sender or
	if the TCP connection rate is the limiting factor, a form of		if the TCP connection rate is the limiting factor, a form of
	backpressure is observed by the TCP sending application. When the		backpressure is observed by the TCP sending application. When the
	TCP buffer fills, the sending application will either block on the		TCP buffer fills, the sending application will either block on the
	write or receive an error on the write. Common errors in either		write or receive an error on the write. Common errors in either
	early implementations or an occasional naive new implementation are		early implementations or an occasional naive new implementation are
	to either set options to block on the write or set options for non-		to either set options to block on the write or set options for non-
	blocking writes and then treat the errors due to a full buffer as		blocking writes and then treat the errors due to a full buffer as
	skipping to change at page 15, line 5		skipping to change at page 15, line 5
	instability.		instability.
	14. Ordering of Path Attributes		14. Ordering of Path Attributes
	The BGP protocol suggests that BGP speakers sending multiple prefixes		The BGP protocol suggests that BGP speakers sending multiple prefixes
	per an UPDATE message should sort and order path attributes according		per an UPDATE message should sort and order path attributes according
	to Type Codes. This would help their peers to quickly identify sets		to Type Codes. This would help their peers to quickly identify sets
	of attributes from different update messages which are semantically		of attributes from different update messages which are semantically
	different.		different.
	=0C
	Implementers may find it useful to order path attributes according to		Implementers may find it useful to order path attributes according to
	Type Code so that sets of attributes with identical semantics can be		Type Code so that sets of attributes with identical semantics can be
	more quickly identified.		more quickly identified.
	15. AS_SET Sorting		15. AS_SET Sorting
	AS_SETs are commonly used in BGP route aggregation. They reduce the		AS_SETs are commonly used in BGP route aggregation. They reduce the
	size of AS_PATH information by listing AS numbers only once		size of AS_PATH information by listing AS numbers only once
	regardless of any number of times it might appear in process of		regardless of any number of times it might appear in process of
	aggregation. AS_SETs are usually sorted in increasing order to		aggregation. AS_SETs are usually sorted in increasing order to
	skipping to change at page 16, line 5		skipping to change at page 16, line 5
	BGP a provides flexible and extendable mechanism for authentication		BGP a provides flexible and extendable mechanism for authentication
	and security. The mechanism allows to support schemes with various		and security. The mechanism allows to support schemes with various
	degree of complexity. BGP sessions are authenticated based on the IP		degree of complexity. BGP sessions are authenticated based on the IP
	address of a peer. In addition, all BGP sessions are authenticated		address of a peer. In addition, all BGP sessions are authenticated
	based on the autonomous system number advertised by a peer.		based on the autonomous system number advertised by a peer.
	Since BGP runs over TCP and IP, BGP's authentication scheme may be		Since BGP runs over TCP and IP, BGP's authentication scheme may be
	augmented by any authentication or security mechanism provided by		augmented by any authentication or security mechanism provided by
	either TCP or IP.		either TCP or IP.
	=0C
	17.1. TCP MD5 Signature Option		17.1. TCP MD5 Signature Option
	[RFC 2385] defines a way in which the TCP MD5 signature option can be		[RFC 2385] defines a way in which the TCP MD5 signature option can be
	used to validate information transmitted between two peers. This		used to validate information transmitted between two peers. This
	method prevents any third party from injecting information (e.g., a		method prevents any third party from injecting information (e.g., a
	TCP Reset) into the datastream, or modifying the routing information		TCP Reset) into the datastream, or modifying the routing information
	carried between two BGP peers.		carried between two BGP peers.
	TCP MD5 is not ubiquitously deployed at the moment, especially in		TCP MD5 is not ubiquitously deployed at the moment, especially in
	inter- domain scenarios, largely because of key distribution issues.		inter- domain scenarios, largely because of key distribution issues.
	skipping to change at page 17, line 5		skipping to change at page 17, line 5
	IPSEC does, however, offer several options for exchanging session		IPSEC does, however, offer several options for exchanging session
	keys, which may be useful on inter-domain configurations. These		keys, which may be useful on inter-domain configurations. These
	options are being explored in many deployments, although no		options are being explored in many deployments, although no
	definitive solution has been reached on the issue of key exchange for		definitive solution has been reached on the issue of key exchange for
	BGP in IPSEC.		BGP in IPSEC.
	It should be noted that since BGP runs over TCP and IP, BGP is		It should be noted that since BGP runs over TCP and IP, BGP is
	vulnerable to the same denial of service or authentication attacks		vulnerable to the same denial of service or authentication attacks
	that are present in any other TCP based protocol.		that are present in any other TCP based protocol.
	=0C
	17.3. Miscellaneous		17.3. Miscellaneous
	Another issue any routing protocol faces is providing evidence of the		Another issue any routing protocol faces is providing evidence of the
	validity and authority of the routing information carried within the		validity and authority of the routing information carried within the
	routing system. This is currently the focus of several efforts at		routing system. This is currently the focus of several efforts at
	the moment, including efforts to define the threats which can be used		the moment, including efforts to define the threats which can be used
	against this routing information in BGP [draft-murphy, attack tree],		against this routing information in BGP [draft-murphy, attack tree],
	and efforts at developing a means to provide validation and authority		and efforts at developing a means to provide validation and authority
	for routing information carried within BGP [SBGP] [soBGP].		for routing information carried within BGP [SBGP] [soBGP].
	In addition, the Routing Protocol Security Requirements (RPSEC)		In addition, the Routing Protocol Security Requirements (RPSEC)
	working group has been chartered within the Routing Area of the IETF		working group has been chartered within the Routing Area of the IETF
	in order to discuss and assist in addressing issues surrounding		in order to discuss and assist in addressing issues surrounding
	routing protocol security. It is the intent that this work within		routing protocol security. It is the intent that this work within
	RPSEC will result in feedback to BGPv4 and future enhancements to the		RPSEC will result in feedback to BGPv4 and future enhancements to the
	protocol where appropriate.		protocol where appropriate.
	17.4. PTOMAINE and GROW		18. PTOMAINE and GROW
	The Prefix Taxonomy (PTOMAINE) working group, recently replaced by		The Prefix Taxonomy (PTOMAINE) working group, recently replaced by
	the Global Routing Operations (GROW) working group, is chartered to		the Global Routing Operations (GROW) working group, is chartered to
	consider and measure the problem of routing table growth, the effects		consider and measure the problem of routing table growth, the effects
	of the interactions between interior and exterior routing protocols,		of the interactions between interior and exterior routing protocols,
	and the effect of address allocation policies and practices on the		and the effect of address allocation policies and practices on the
	global routing system. Finally, where appropriate, GROW will also		global routing system. Finally, where appropriate, GROW will also
	document the operational aspects of measurement, policy, security and		document the operational aspects of measurement, policy, security and
	VPN infrastructures.		VPN infrastructures.
	One such item GROW is currently studying is the effects of route		One such item GROW is currently studying is the effects of route
	aggregation and the inability to aggregate over multiple provider		aggregation and the inability to aggregate over multiple provider
	boundaries due to inadequate provider coordination.		boundaries due to inadequate provider coordination.
	It is the intent that this work within GROW will result in feedback		It is the intent that this work within GROW will result in feedback
	to BGPv4 and future enhancements to the protocol as necessary.		to BGPv4 and future enhancements to the protocol as necessary.
	17.5. Internet Routing Registries (IRRs)		19. Internet Routing Registries (IRRs)
	Many organizations register their routing policy and prefix		Many organizations register their routing policy and prefix
	origination in the various distributed databases of the Internet		origination in the various distributed databases of the Internet
	Routing Registry. These databases provide access to the information		Routing Registry. These databases provide access to the information
	using the RPSL language as defined in [RFC 2622]. While registered		using the RPSL language as defined in [RFC 2622]. While registered
	=0C
	information may be maintained and correct for certain providers, the		information may be maintained and correct for certain providers, the
	lack of timely or correct data in the various IRR databases has		lack of timely or correct data in the various IRR databases has
	prevented wide-spread use of this resource.		prevented wide-spread use of this resource.
	17.6. Regional Internet Registries (RIRs) and IRRs, A Bit of History		20. Regional Internet Registries (RIRs) and IRRs, A Bit of History
	The NSFNET program used EGP and then BGP to provide external routing		The NSFNET program used EGP and then BGP to provide external routing
	information. It was the NSF policy of offering differing pricing and		information. It was the NSF policy of offering differing pricing and
	providing a different level of support to the Research and Education		providing a different level of support to the Research and Education
	(RE) networks and the Commercial (CO) networks that led to BGP's		(RE) networks and the Commercial (CO) networks that led to BGP's
	initial policy requirements. CO networks were not able to use the		initial policy requirements. CO networks were not able to use the
	NSFNET backbone to reach other CO networks, in addition to being		NSFNET backbone to reach other CO networks, in addition to being
	charged more. The rationelle was that commercial users of the NSFNET		charged more. The rationale was that commercial users of the NSFNET
	with business with research entities should subsidize the RE		with business with research entities should subsidize the RE
	community. Recognition that the Internet was evolving away from a		community. Recognition that the Internet was evolving away from a
	hierarchical network to a mesh of peers led to changes from EGP and		hierarchical network to a mesh of peers led to changes from EGP and
	BGP-1 that eliminated any assumptions of hierarchy.		BGP-1 that eliminated any assumptions of hierarchy.
	Enforcement of NSF policy was accomplished through maintenance of the		Enforcement of NSF policy was accomplished through maintenance of the
	NSF Policy Routing Database (PRDB). The PRDB not only contained each		NSF Policy Routing Database (PRDB). The PRDB not only contained each
	networks designation as CO or RE, but also contained a list of the		networks designation as CO or RE, but also contained a list of the
	preferred exit points to the NSFNET to reach each network. This was		preferred exit points to the NSFNET to reach each network. This was
	the basis for setting what would later be called BGP LOCAL_PREF on		the basis for setting what would later be called BGP LOCAL_PREF on
	skipping to change at page 19, line 4		skipping to change at page 19, line 4
	networking community had long seen the PRDB as too US centric.		networking community had long seen the PRDB as too US centric.
	Through Reseaux IP Europeens (RIPE) the Europeans had created an open		Through Reseaux IP Europeens (RIPE) the Europeans had created an open
	format in RIPE-181 and had been maintaining an open database used for		format in RIPE-181 and had been maintaining an open database used for
	address and AS registry more than policy. The initial conversion of		address and AS registry more than policy. The initial conversion of
	the PRDB was to RIPE-181 format and tools were converted to make use		the PRDB was to RIPE-181 format and tools were converted to make use
	of this format. The collection of databases was termed the Internet		of this format. The collection of databases was termed the Internet
	Routing Registry, with the RIPE database and US NSF funded Routing		Routing Registry, with the RIPE database and US NSF funded Routing
	Arbitrator (RA) being the inital components of the IRR.		Arbitrator (RA) being the inital components of the IRR.
	A need to extend RIPE-181 was recognized and RIPE agreed to allow the		A need to extend RIPE-181 was recognized and RIPE agreed to allow the
	=0C
	extensions to be defined within the IETF in the RPS WG. The result		extensions to be defined within the IETF in the RPS WG. The result
	was the RPSL language. Other work products of the RPS WG provided an		was the RPSL language. Other work products of the RPS WG provided an
	authentication framework and means to widely distribute the database		authentication framework and means to widely distribute the database
	in a controlled manner and synchronize the many repositories. Freely		in a controlled manner and synchronize the many repositories. Freely
	available tools were provided primarily by RIPE, Merit, and ISI, the		available tools were provided primarily by RIPE, Merit, and ISI, the
	most comprehensive set from ISI. The efforts of the IRR participants		most comprehensive set from ISI. The efforts of the IRR participants
	has been severely hampered by providers unwilling to keep information		has been severely hampered by providers unwilling to keep information
	in the IRR up to date. The larger of these providers have been		in the IRR up to date. The larger of these providers have been
	vocal, claiming that the database entry, simple as it may be, are an		vocal, claiming that the database entry, simple as it may be, are an
	administrative burden and some acknowledge that doing so provides a		administrative burden and some acknowledge that doing so provides a
	skipping to change at page 19, line 28		skipping to change at page 19, line 26
	of the Internet to routing based attack or accidental injection of		of the Internet to routing based attack or accidental injection of
	faulty routing information.		faulty routing information.
	There have been numerous cases of accidental disruption of Internet		There have been numerous cases of accidental disruption of Internet
	routing which were avoided by providers using the IRR but highly		routing which were avoided by providers using the IRR but highly
	detrimental to non-users. As filters have had to be relaxed due to		detrimental to non-users. As filters have had to be relaxed due to
	the erosion of the IRR to less complete coverage, these types of		the erosion of the IRR to less complete coverage, these types of
	disruptions have continued to occur very infrequently, but have had		disruptions have continued to occur very infrequently, but have had
	increasingly widespread impact.		increasingly widespread impact.
	17.7. Acknowledgements		21. Acknowledgements
	We would like to thank Paul Traina and Yakov Rekhter for authoring		We would like to thank Paul Traina and Yakov Rekhter for authoring
	previous versions of this document and providing valuable input on		previous versions of this document and providing valuable input on
	this update as well. We would also like to explicitly acknowledge		this update as well. We would also like to explicitly acknowledge
	Curtis Villamizar for providing both text and thorough reviews.		Curtis Villamizar for providing both text and thorough reviews.
	Thanks to Russ White, Jeffrey Haas, Sean Mentzer, Mitchell Erblich		Thanks to Russ White, Jeffrey Haas, Sean Mentzer, Mitchell Erblich
	and Jude Ballard for supplying their usual keen eye.		and Jude Ballard for supplying their usual keen eye.
	Finally, we'd like to think the IDR WG for general and specific input		Finally, we'd like to think the IDR WG for general and specific input
	that contributed to this document.		that contributed to this document.
	=0C		22. References
	18. References
	[RFC 793] Postel, J., "Transmission Control Protocol", RFC 793,
	September 1981.
	[RFC 1105] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol
	BGP", RFC 1105, June 1989.
	[RFC 1163] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol
	BGP", RFC 1105, June 1990.
	[RFC 1264] Hinden, R., "Internet Routing Protocol Standardization
	Criteria", RFC 1264, October 1991.
	[RFC 1267] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol 3
	(BGP-3)", RFC 1105, October 1991.
	[RFC 1269] Willis, S., and Burruss, J., "Definitions of Managed		22.1. Normative References
	Objects for the Border Gateway Protocol (Version 3)",
	RFC 1269, October 1991.
	[RFC 1519] Fuller, V., Li. T., Yu J., and K. Varadhan, "Classless		[RFC 1519] Fuller, V., Li. T., Yu J., and K. Varadhan, "Classless
	Inter-Domain Routing (CIDR): an Address Assignment and		Inter-Domain Routing (CIDR): an Address Assignment and
	Aggregation Strategy", RFC 1519, September 1993.		Aggregation Strategy", RFC 1519, September 1993.
	[RFC 1656] Traina, P., "BGP-4 Protocol Document Roadmap and
	Implementation Experience", RFC 1656, July 1994.
	[RFC 1657] Willis, S., Burruss, J., Chu, J., " Definitions of
	Managed Objects for the Fourth Version of the Border
	Gateway Protocol (BGP-4) using SMIv2", RFC 1657, July
	1994.
	[RFC 1771] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4
	(BGP-4)", RFC 1771, March 1995.
	[RFC 1772] Rekhter, Y., and P. Gross, Editors, "Application of the
	Border Gateway Protocol in the Internet", RFC 1772, March
	1995.
	[RFC 1773] Traina, P., "Experience with the BGP-4 protocol", RFC
	1773, March 1995.
	[RFC 1966] Bates, T., Chandra, R., "BGP Route Reflection: An		[RFC 1966] Bates, T., Chandra, R., "BGP Route Reflection: An
	alternative to full mesh IBGP", RFC 1966, June 1996.		alternative to full mesh IBGP", RFC 1966, June 1996.
	[RFC 2385] Heffernan, A., "Protection of BGP Sessions via the TCP		[RFC 2385] Heffernan, A., "Protection of BGP Sessions via the TCP
	=0C
	MD5 Signature Option", RFC 2385, August 1998.		MD5 Signature Option", RFC 2385, August 1998.
	[RFC 2439] Villamizar, C. and Chandra, R., "BGP Route Flap Damping",		[RFC 2439] Villamizar, C. and Chandra, R., "BGP Route Flap Damping",
	RFC 2439, November 1998.		RFC 2439, November 1998.
	[RFC 2622] C. Alaettinoglu et al., "Routing Policy Specification
	Language", RFC 2622, June 1999.
	[RFC 2796] Bates, T., Chandra, R., and Chen, E, "Route Reflection -		[RFC 2796] Bates, T., Chandra, R., and Chen, E, "Route Reflection -
	An Alternative to Full Mesh IBGP", RFC 2796, April 2000.		An Alternative to Full Mesh IBGP", RFC 2796, April 2000.
	[RFC 3065] Traina, P., McPherson, D., and Scudder, J, "Autonomous		[RFC 3065] Traina, P., McPherson, D., and Scudder, J, "Autonomous
	System Confederations for BGP", RFC 3065, Febuary 2001.		System Confederations for BGP", RFC 3065, Febuary 2001.
	[RFC 3345] McPherson, D., Gill, V., Walton, D., and Retana, A, "BGP		[RFC 3345] McPherson, D., Gill, V., Walton, D., and Retana, A, "BGP
	Persistent Route Oscillation Condition", RFC 3345,		Persistent Route Oscillation Condition", RFC 3345,
	August 2002.		August 2002.
	[BGP4-ANALYSIS] "BGP-4 Protocol Analysis", Internet-Draft, Work in		[BGP4-ANALYSIS] "BGP-4 Protocol Analysis", Internet-Draft, Work in
	Progress.		Progress.
	[BGP4-IMPL] "BGP 4 Implementation Report ", Internet-Draft, Work		[BGP4-IMPL] "BGP 4 Implementation Report ", Internet-Draft, Work
	in Progress.		in Progress.
	[BGP4] Rekhter, Y., T. Li., and Hares. S, Editors, "A Border		[BGP4] Rekhter, Y., T. Li., and Hares. S, Editors, "A Border
	Gateway Protocol 4 (BGP-4)", BGP Draft, Work in Progress.		Gateway Protocol 4 (BGP-4)", BGP Draft, Work in Progress.
			[RFC 1657] Willis, S., Burruss, J., Chu, J., " Definitions of
			Managed Objects for the Fourth Version of the Border
			Gateway Protocol (BGP-4) using SMIv2", RFC 1657, July
			1994.
	[SBGP] "Secure BGP", Internet-Draft, Work in Progress.		[SBGP] "Secure BGP", Internet-Draft, Work in Progress.
	[soBGP] "Secure Origin BGP", Internet-Draft, Work in Progress.		[soBGP] "Secure Origin BGP", Internet-Draft, Work in Progress.
	19. Authors' Addresses		[RFC 793] Postel, J., "Transmission Control Protocol", RFC 793,
			September 1981.
			22.2. Informative References
			[RFC 1105] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol
			BGP", RFC 1105, June 1989.
			[RFC 1163] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol
			BGP", RFC 1105, June 1990.
			[RFC 1264] Hinden, R., "Internet Routing Protocol Standardization
			Criteria", RFC 1264, October 1991.
			[RFC 1267] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol 3
			(BGP-3)", RFC 1105, October 1991.
			[RFC 1269] Willis, S., and Burruss, J., "Definitions of Managed
			Objects for the Border Gateway Protocol (Version 3)",
			RFC 1269, October 1991.
			[RFC 1656] Traina, P., "BGP-4 Protocol Document Roadmap and
			Implementation Experience", RFC 1656, July 1994.
			[RFC 1771] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4
			(BGP-4)", RFC 1771, March 1995.
			[RFC 1772] Rekhter, Y., and P. Gross, Editors, "Application of the
			Border Gateway Protocol in the Internet", RFC 1772, March
			1995.
			[RFC 1773] Traina, P., "Experience with the BGP-4 protocol", RFC
			1773, March 1995.
			[RFC 2622] C. Alaettinoglu et al., "Routing Policy Specification
			Language", RFC 2622, June 1999.
			23. Authors' Addresses
	Danny McPherson		Danny McPherson
	Arbor Networks		Arbor Networks
	Email: danny@arbor.net		Email: danny@arbor.net
	Keyur Patel		Keyur Patel
	Cisco Systems		Cisco Systems
	Email: keyupate@cisco.com		Email: keyupate@cisco.com
	=0C		Intellectual Property Statement
	20. Full Copyright Statement		The IETF takes no position regarding the validity or scope of any
			Intellectual Property Rights or other rights that might be claimed to
			pertain to the implementation or use of the technology described in
			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
			made any independent effort to identify any such rights. Information
			on the procedures with respect to rights in RFC documents can be
			found in BCP 78 and BCP 79.
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copies of IPR disclosures made to the IETF Secretariat and any
			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
			such proprietary rights by implementers or users of this
			specification can be obtained from the IETF on-line IPR repository at
			http://www.ietf.org/ipr.
	This document and translations of it may be copied and furnished to		The IETF invites any interested party to bring to its attention any
	others, and derivative works that comment on or otherwise explain it		copyrights, patents or patent applications, or other proprietary
	or assist in its implementation may be prepared, copied, published		rights that may cover technology that may be required to implement
	and distributed, in whole or in part, without restriction of any		this standard. Please address the information to the IETF at
	kind, provided that the above copyright notice and this paragraph are		ietf-ipr@ietf.org.
	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		Disclaimer of Validity
	revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		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
			Internet Society.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/