< draft-ietf-grow-as-path-prepending-03.txt		draft-ietf-grow-as-path-prepending-04.txt >
	Network Working Group M. McBride		Network Working Group M. McBride
	Internet-Draft Futurewei		Internet-Draft Futurewei
	Intended status: Best Current Practice D. Madory		Updates: 7454, 8195 (if approved) D. Madory
	Expires: August 12, 2021 Kentik		Intended status: Best Current Practice Kentik
	J. Tantsura		Expires: January 9, 2022 J. Tantsura
	Apstra		Microsoft
	R. Raszuk		R. Raszuk
	Bloomberg LP		NTT Network Innovations
	H. Li		H. Li
	HPE		HPE
	J. Heitz		J. Heitz
	Cisco		Cisco
	February 8, 2021		G. Mishra
			Verizon Inc.
			July 8, 2021
	AS Path Prepending		AS Path Prepending
	draft-ietf-grow-as-path-prepending-03		draft-ietf-grow-as-path-prepending-04
	Abstract		Abstract
	AS Path Prepending provides a tool to manipulate the BGP AS_Path		AS Path Prepending provides a tool to manipulate the BGP AS_Path
	attribute through prepending multiple entries of an AS. AS Path		attribute through prepending multiple entries of an AS. AS Path
	Prepending is used to deprioritize a route or alternate path. By		Prepending is used to deprioritize a route or alternate path. By
	prepending the local ASN multiple times, ASs can make advertised AS		prepending the local ASN multiple times, ASs can make advertised AS
	paths appear artificially longer. Excessive AS Path Prepending has		paths appear artificially longer. Excessive AS Path Prepending has
	caused routing issues in the internet. This document provides		caused routing issues in the internet. This document provides
	guidance,to the internet community, with how best to utilize AS Path		guidance with the use of AS Path Prepending, including alternative
	Prepending in order to avoid negatively affecting the internet.		solutions, in order to avoid negatively affecting the internet.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	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."
	This Internet-Draft will expire on August 12, 2021.		This Internet-Draft will expire on January 9, 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 26 ¶		skipping to change at page 2, line 26 ¶
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Excessive Prepending . . . . . . . . . . . . . . . . . . 4		3.1. Cascading and ripple affect of prepending across the
	3.2. Prepending during a routing leak . . . . . . . . . . . . 5		internet . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.3. Prepending to All . . . . . . . . . . . . . . . . . . . . 5		3.2. Excessive Prepending . . . . . . . . . . . . . . . . . . 5
	3.4. Memory . . . . . . . . . . . . . . . . . . . . . . . . . 6		3.3. Prepending during a routing leak . . . . . . . . . . . . 6
	3.5. Errant announcement . . . . . . . . . . . . . . . . . . . 6		3.4. Prepending to All . . . . . . . . . . . . . . . . . . . . 7
	4. Alternatives to AS Path Prepend . . . . . . . . . . . . . . . 7		3.5. Memory . . . . . . . . . . . . . . . . . . . . . . . . . 7
	5. Best Practices . . . . . . . . . . . . . . . . . . . . . . . 7		3.6. Errant announcement . . . . . . . . . . . . . . . . . . . 7
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		4. Alternatives to AS Path Prepend . . . . . . . . . . . . . . . 8
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 8		5. Best Practices . . . . . . . . . . . . . . . . . . . . . . . 9
	8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	9.1. Normative References . . . . . . . . . . . . . . . . . . 9		8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11
	9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		9.1. Normative References . . . . . . . . . . . . . . . . . . 11
			9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	The Border Gateway Protocol (BGP) [RFC4271] specifies the AS_PATH		The Border Gateway Protocol (BGP) [RFC4271] specifies the AS_PATH
	attribute which enumerates ASs a route update has traversed. If the		attribute which enumerates ASs a route update has traversed. If the
	UPDATE message is propagated over an external link, then the local AS		UPDATE message is propagated over an external link, then the local AS
	number is prepended to the AS_PATH attribute, and the NEXT_HOP		number is prepended to the AS_PATH attribute, and the NEXT_HOP
	attribute is updated with an IP address of the router that should be		attribute is updated with an IP address of the router that should be
	used as a next hop to the network. If the UPDATE message is		used as a next hop to the network. If the UPDATE message is
	propagated over an internal link, then the AS_PATH attribute and the		propagated over an internal link, then the AS_PATH attribute and the
	skipping to change at page 3, line 29 ¶		skipping to change at page 3, line 29 ¶
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2. Use Cases		2. Use Cases
	There are various reasons that AS Path Prepending is in use today		There are various reasons that AS Path Prepending is in use today
	including:		including:
	o Preferring one ISP over another ISP on the same ASBR or across		o Preferring one ISP over another ISP on the same ASBR or across
	different ASBRs		different ASBRs.
	o Preferring one ASBR over another ASBR in the same site		o Preferring one ASBR over another ASBR in the same site or between
			sister sites.
	o Utilize one path exclusively and another path solely as a backup		o Utilize one path exclusively and another path solely as a backup.
	o Signal to indicate that one path may have a different amount of		o Signal to indicate that one path may have a different amount of
	capacity than another where the lower capacity link still takes		capacity than another where the lower capacity link still takes
	traffic		traffic.
			o Conditionally prefer one ASBR over another at the same site or
			between sites for lowest latency path based on geographic
			location.
	o An ISP doesn't accept traffic engineering using BGP communities.		o An ISP doesn't accept traffic engineering using BGP communities.
	Prepending is the only option.		Prepending is the only option.
	The following illustration, from Geoff Hustons Path Prepending in BGP		The following illustration, from Geoff Hustons Path Prepending in BGP
	[1], shows how AS Prepending is typically used:		[1], shows how AS Prepending is typically used:
	+---+ +---+		+---+ +---+
	+---| D |----| F |		+---| D |----| F |
	| +---+ +---+		| +---+ +---+
	+---+ +---+ |		+---+ +---+ |
	| A |---| B | |		| A |---| B | |
	+---+ +---+ |		+---+ +---+ 2x<- |
	| +---+ +---+		| +---+ +---+
	+---| C |----| E |		+---| C |----| E |
	+---+ +---+		+---+ +---+
			In the diagram above, A, B, C, D, E, and F all have a different AS.
	B will normally prefer the path via C to send traffic to E, as this		B will normally prefer the path via C to send traffic to E, as this
	represents the shorter AS path for B. If E were to prepend a further		represents the shorter AS path for B. If E were to prepend a further
	two instances of its own AS number when advertising its routes to C,		two instances of its own AS number when advertising its routes to C,
	then B will now see a different situation, where the AS Path via D		then B will now see a different situation, where the AS Path via D
	represents the shorter path. Through the use of selective prepending		represents the shorter path. Through the use of selective prepending
	E is able to alter the routing decision of B, even though B is not an		E is able to alter the routing decision of B, even though B is not an
	adjacent neighbour of E. The result is that traffic from A and B		adjacent neighbour of E. The result is that traffic from A and B
	will be passed via D and F to reach E, rather than via C. In this		will be passed via D and F to reach E, rather than via C. In this
	way prepending implements action at a distance where the routing		way prepending implements action at a distance where the routing
	decisions made by non-adjacent ASs can be influenced by selective AS		decisions made by non-adjacent ASs can be influenced by selective AS
	Path prepending.		Path prepending.
	3. Problems		3. Problems
	Since it is so commonly used, what is the problem with the excessive		Since it is so commonly used, what is the problem with the excessive
	use of AS Path Prepending? Here are a few examples:		use of AS Path Prepending? Here are a few examples:
	3.1. Excessive Prepending		3.1. Cascading and ripple affect of prepending across the internet
			Care must be taken in prepending, as prepending can result in a
			ripple affect with multiple AS's performing the same set of prepend
			in the same direction can result in route leaks where the valid
			preferred path becomes now de-preferred.
			<-5x <-5x <-5x
			+---+ +---+ +---+ +---+
			+---| D |----| F |----| H |----| J |
			| +---+ +---+ +---+ +---+
			+---+ +---+ | |
			| A |---| B | | |
			+---+ +---+ 13x<-| |
			| +---+ +---+ +---+ +---+
			+---| C |----| E |----| G |----| I |
			+---+ +---+ +---+ +---+
			In the diagram above A, B, C, D, E, F G, H, I, J are all part of a
			different AS. B will normally prefer the path via D to send traffic
			to J, as this represents the preferred path to B, due to E prepending
			13 instances of its own AS number when advertising routes to C. ISP
			J decides to prepend 5 instances of its own AS when advertising H,
			and ISP H decides to do the same and prepends 5 instances of its own
			AS when advertising to F. ISP F decides to as well prepend 5
			instances of its own AS when advertising to D. B now sees 19 AS hops
			for prefixes coming from D to get to J which should be the preferred
			path compare to 18 AS hops coming from C which is now preferred. We
			now have a route leak to I as B now sends all of its traffic through
			I to reach J. This is the typical scenario where route leaks occur
			where providers decide to de-prefer a path, however as the same de-
			prefer of a path gets cascaded in the same direction, as a result,
			the path that should never be preferred as its as-path is very high
			in this case 18 AS hops ends up being the preferred path resulting in
			a route leak. BGP large communties along with conditional
			prepending, along with care being taken when prepending is performed
			between providers can help mitigate the adverse impacts of
			prepending.
			3.2. Excessive Prepending
	The risk of excessive use of AS Path Prepending can be illustrated		The risk of excessive use of AS Path Prepending can be illustrated
	with real-world examples that have been anonymized using documention		with real-world examples that have been anonymized using
	prefixes [RFC5737] and ASs [RFC5398] . Consider the prefix		documentation prefixes [RFC5737] and ASs [RFC5398] . Consider the
	198.51.100.0/24 which is normally announced with an inordinate amount		prefix 198.51.100.0/24 which is normally announced with an inordinate
	of prepending. A recent analysis revealed that 198.51.100.0/24 is		amount of prepending. A recent analysis revealed that
	announced to the world along the following AS path:		198.51.100.0/24 is announced to the world along the following AS
			path:
	64496 64511 64511 64511 64511 64511 64511 64511 64511 64511 64511		64496 64511 64511 64511 64511 64511 64511 64511 64511 64511 64511
	64511 64511 64511 64511 64511 64511 64511 64511 64511 64511 64511		64511 64511 64511 64511 64511 64511 64511 64511 64511 64511 64511
	64511 64511		64511 64511
	In this example, the origin AS64511 appears 23 consecutive times		In this example, the origin AS64511 appears 23 consecutive times
	before being passed on to a single upstream (AS64496), which passes		before being passed on to a single upstream (AS64496), which passes
	it on to the global internet, prepended-to-all. An attacker, wanting		it on to the global internet, prepended-to-all. An attacker, wanting
	to intercept or manipulate traffic to this prefix, could enlist a		to intercept or manipulate traffic to this prefix, could enlist a
	datacenter to allow announcements of the same prefix with a		datacenter to allow announcements of the same prefix with a
	fabricated AS path such as 999999 64496 64511. Here the fictional		fabricated AS path such as 999999 64496 64511. Here the fictional
	AS999999 represents the shady datacenter. This malicious route would		AS999999 represents the shady datacenter. This malicious route would
	be preferred due to the shortened AS path length and might go		be preferred due to the shortened AS path length and might go
	unnoticed by the true origin, even if route-monitoring had been		unnoticed by the true origin, even if route-monitoring had been
	implemented. Standard BGP route monitoring checks a route's origin		implemented. Standard BGP route monitoring checks a route's origin
	and upstream and both would be intact in this scenario. The length		and upstream and both would be intact in this scenario. The length
	of the prepending gives the attacker room to craft an AS path that		of the prepending gives the attacker room to craft an AS path that
	would appear plausible to the casual observer, comply with origin		would appear plausible to the casual observer, comply with origin
	validation mechanisms, and not be detected by off-the-shelf route		validation mechanisms, and not be detected by off-the-shelf route
	monitoring.		monitoring.
	3.2. Prepending during a routing leak		3.3. Prepending during a routing leak
	In April 2010, a service provider experienced a routing leak. While		In April 2010, a service provider experienced a routing leak. While
	analyzing the leak something peculiar was noticed. When we ranked		analyzing the leak something peculiar was noticed. When we ranked
	the approximately 50,000 prefixes involved in the leak based on how		the approximately 50,000 prefixes involved in the leak based on how
	many ASs accepted the leaked routes, most of the impact was		many ASs accepted the leaked routes, most of the impact was
	constrained to Country A routes. However, two of the top five most-		constrained to Country A routes. However, two of the top five most-
	propagated leaked routes (listed in the table below) were Country B		propagated leaked routes (listed in the table below) were Country B
	routes.		routes.
	During the routing leak, nearly all of the ASs of the internet		During the routing leak, nearly all of the ASs of the internet
	skipping to change at page 5, line 45 ¶		skipping to change at page 7, line 5 ¶
	You would think such mistakes would be relatively rare, especially		You would think such mistakes would be relatively rare, especially
	now, 10 years later. As it turns out, there is quite a lot of		now, 10 years later. As it turns out, there is quite a lot of
	prepending-to-all going on right now and during leaks, it doesn't go		prepending-to-all going on right now and during leaks, it doesn't go
	well for those who make this mistake. While one can debate the		well for those who make this mistake. While one can debate the
	merits of prepending to a subset of multiple transit providers, it is		merits of prepending to a subset of multiple transit providers, it is
	difficult to see the utility in prepending to every provider. In		difficult to see the utility in prepending to every provider. In
	this configuration, the prepending is no longer shaping route		this configuration, the prepending is no longer shaping route
	propagation. It is simply incentivizing ASs to choose another origin		propagation. It is simply incentivizing ASs to choose another origin
	if one were to suddenly appear whether by mistake or otherwise.		if one were to suddenly appear whether by mistake or otherwise.
	3.3. Prepending to All		3.4. Prepending to All
	Based on analysis done in 2019, Excessive AS Path Prepending [2], out		Based on analysis done in 2019, Excessive AS Path Prepending [2], out
	of approximately 750,000 routes in the IPv4 global routing table,		of approximately 750,000 routes in the IPv4 global routing table,
	nearly 60,000 BGP routes are prepended to 95% or more of hundreds of		nearly 60,000 BGP routes are prepended to 95% or more of hundreds of
	BGP sources. About 8% of the global routing table, or 1 out of every		BGP sources. About 8% of the global routing table, or 1 out of every
	12 BGP routes, is configured with prepends to virtually the entire		12 BGP routes, is configured with prepends to virtually the entire
	internet. The 60,000 routes include entities of every stripe:		internet. The 60,000 routes include entities of every stripe:
	governments, financial institutions, even important parts of internet		governments, financial institutions, even important parts of internet
	infrastructure.		infrastructure.
	skipping to change at page 6, line 31 ¶		skipping to change at page 7, line 39 ¶
	needed and 2) the AS attempting to de-prioritize traffic from transit		needed and 2) the AS attempting to de-prioritize traffic from transit
	providers over settlement-free peers and 3) there are simply a lot of		providers over settlement-free peers and 3) there are simply a lot of
	errors in BGP routing. Consider the prepended AS path below:		errors in BGP routing. Consider the prepended AS path below:
	64496 64501 64501 64510 64510 64501 64510 64501 64501 64510 64510		64496 64501 64501 64510 64510 64501 64510 64501 64501 64510 64510
	64501 64501 64510		64501 64501 64510
	The prepending here involves a mix of two distinct ASNs (64501 and		The prepending here involves a mix of two distinct ASNs (64501 and
	64510) with the last two digits transposed.		64510) with the last two digits transposed.
	3.4. Memory		3.5. Memory
	Long AS Paths cause an increase in memory usage by BGP speakers. The
	memory usage is not so much a concern in the control plane BGP
	implementations, but more so when AS Paths are included in Netflow
	messages. Netflow is processed in the forwarding plane, where memory
	is more expensive than in the control plane.
	A concern about an AS Path longer than 255 is the extra complexity		Long AS Paths cause an increase in memory usage by BGP speakers. A
			concern about an AS Path longer than 255 is the extra complexity
	required to process it, because it needs to be encoded in more than		required to process it, because it needs to be encoded in more than
	one AS_SEQUENCE in the AS_PATH BGP path attribute.		one AS_SEQUENCE in the AS_PATH BGP path attribute.
	3.5. Errant announcement		3.6. Errant announcement
	There was an Internet-wide outage caused by a single errant routing		There was an Internet-wide outage caused by a single errant routing
	announcement. In this incident, AS64496 announced its one prefix		announcement. In this incident, AS64496 announced its one prefix
	with an extremely long AS path. Someone entered their ASN instead of		with an extremely long AS path. Someone entered their ASN instead of
	the prepend count 64496 modulo 256 = 252 prepends and when a path		the prepend count 64496 modulo 256 = 252 prepends and when a path
	lengths exceeded 255, routers crashed		lengths exceeded 255, routers crashed
	4. Alternatives to AS Path Prepend		4. Alternatives to AS Path Prepend
	There are various options to provide path preference without needing		Various options, to provide path preference without needing to use AS
	to use AS Path Prepend:		Path Prepend, include:
	o Use predefined communities that are mapped to a particular		o Use predefined communities that are mapped to a particular
	behavior when propagated.		behavior when propagated.
	o Announce more specific routes on the preferred path.		o Announce more specific routes on the preferred path.
	o The BGP Origin Code is an attribute that is used for path		o The BGP Origin Code is an attribute that is used for path
	selection and can be used as a high order tie-breaker. The three		selection and can be used as a high order tie-breaker. The three
	origin codes are IGP, EGP and INCOMPLETE. When AS Paths are of		origin codes are IGP, EGP and INCOMPLETE. When AS Paths are of
	equivalent length, users could advertise paths, with IGP or EGP		equivalent length, users could advertise paths, with IGP or EGP
	origin, over the preferred path while the other ASBRs (which would		origin, over the preferred path while the other ASBRs (which would
	otherwise need to prepend N times) advertises with an INCOMPLETE		otherwise need to prepend N times) advertises with an INCOMPLETE
	origin code.		origin code.
			o The Multi Exit Discriminator (MED) is an optional non-transitive
			attribute that can be used to influence path preference instead of
			using as-path. MED is non transitive so it cannot influence an AS
			more then 1 AS hop away.
			o Local-preference optional non-transitive attribute, above as-path
			in bgp path selection, can be used to influence route preference
			within the local operators AS administrative domain. Local-
			preference can shield the operator domain from traffic shifts off
			the preferred path to a de-preferred path caused by excess
			prepending done by service providers across the internet. If all
			service providers across the internet set local-preference inbound
			conditionally with Large Community set on preferred paths,
			essentially the impacts of route leaks as well as other routing
			issues resulting from excess prepending can be mitigated.
			<-5x <-5x <-5x
			LP 110 +---+ +---+ +---+ +---+
			+---| D |----| F |----| H |----| J |
			| +---+ +---+ +---+ +---+
			+---+ +---+ | |
			| A |---| B | | |
			+---+ +---+ 13x<-| |
			| +---+ +---+ +---+ +---+
			+---| C |----| E |----| G |----| I |
			+---+ +---+ +---+ +---+
			In the diagram above A, B, C, D, E, F G, H, I, J are all part of a
			different AS. B will normally prefer the path via D to send traffic
			to J, as this represents the preferred path to B, due to E prepending
			13 instances of its own AS number when advertising routes to C. ISP
			J decides to prepend 5 instances of its own AS when advertising to H,
			and ISP H decides to do the same and prepends 5 instances of its own
			AS when advertising to F. ISP F decides to also prepend 5 instances
			of its own AS when advertising to D. B now sees 19 AS hops for
			prefixes coming from D to get to J which should be the preferred path
			compare to 18 AS hops coming from C which is now preferred. We now
			have a route leak to I as B now sends all of its traffic through I to
			reach J. Route leak on B can be prevented locally within the
			operator domain by setting local-preference inbound, which is above
			as-path length in the best path selection, to higher then default 100
			to 110 inbound from D, thus shielding the operator B from being
			influenced by the excessive prepend cascading ripple affect by F, H,
			J. Note that A still sees the cascading ripple affect of excess
			prepending, however A, or any service provider AS downstream of B,
			ingressing B, will be shunted to D via local-preference and the route
			leak is now mitigated for all downstream AS to the left of B that
			prefer the path through B.
	5. Best Practices		5. Best Practices
	Many of the best practices, or lack thereof, can be illustrated from		Many of the best practices, or lack thereof, can be illustrated from
	the preceeding examples. Here's a summary of the best current		the preceeding examples. Here's a summary of the best current
	practices when using AS Path Prepending:		practices when using AS Path Prepending:
	o Network operators should ensure prepending is absolutely necessary		o Network operators should ensure prepending is absolutely necessary
	as many networks have excessive prepending. It is best to		as many networks have excessive prepending. It is best to
	innumerate what the routing policies are intended to achieve		innumerate what the routing policies are intended to achieve
	before concluding that prepending is a solution		before concluding that prepending is a solution
	o The neighbor you are prepending may have an unconditional		o The neighbor you are prepending may have an unconditional
	preference for customer routes and prepending doesn't work. It's		preference for customer routes and prepending doesn't work. It's
	helpful to check with neighbors to see if they will honor the		helpful to check with neighbors to see if they will honor the
	prepend to avoid wasting effort and potentially causing further		prepend to avoid wasting effort and potentially causing further
	vulnerabilities.		vulnerabilities.
			o Use of local-preference inbound on preferred paths between service
			providers to help mitigate the adverse affects of prepending
	o There is no need to prepend more than 5 ASs. The following		o There is no need to prepend more than 5 ASs. The following
	diagram shows that, according to Excessive AS Path Prepending [3],		diagram, from the previously referenced AS Path Prepending
	90% of AS path lengths are 5 ASNs or fewer in length.		analysis from 2019, shows that 90% of AS path lengths are 5 ASNs
			or fewer in length.
	+------------------------------------+		+------------------------------------+
	90| |		90| |
	| X |		| X |
	80| X X |		80| X X |
	| X X |		| X X |
	70| X X |		70| X X |
	| X X |		| X X |
	60| X X |		60| X X |
	| X X |		| X X |
	skipping to change at page 9, line 45 ¶		skipping to change at page 11, line 45 ¶
	Large Communities", RFC 8195, DOI 10.17487/RFC8195, June		Large Communities", RFC 8195, DOI 10.17487/RFC8195, June
	2017, <https://www.rfc-editor.org/info/rfc8195>.		2017, <https://www.rfc-editor.org/info/rfc8195>.
	9.2. URIs		9.2. URIs
	[1] https://labs.apnic.net/?p=1264		[1] https://labs.apnic.net/?p=1264
	[2] https://blogs.oracle.com/internetintelligence/excessive-as-path-		[2] https://blogs.oracle.com/internetintelligence/excessive-as-path-
	prepending-is-a-self-inflicted-vulnerability		prepending-is-a-self-inflicted-vulnerability
	[3] https://blogs.oracle.com/internetintelligence/excessive-as-path-
	prepending-is-a-self-inflicted-vulnerability
	Authors' Addresses		Authors' Addresses
	Mike McBride		Mike McBride
	Futurewei		Futurewei
	Email: michael.mcbride@futurewei.com		Email: michael.mcbride@futurewei.com
	Doug Madory		Doug Madory
	Kentik		Kentik
	Email: dmadory@kentik.com		Email: dmadory@kentik.com
	Jeff Tantsura		Jeff Tantsura
	Apstra		Microsoft
	Email: jefftant.ietf@gmail.com		Email: jefftant.ietf@gmail.com
	Robert Raszuk		Robert Raszuk
	Bloomberg LP		NTT Network Innovations
			940 Stewart Dr
			Sunnyvale, CA 94085
			USA
	Email: robert@raszuk.net		Email: robert@raszuk.net
	Hongwei Li		Hongwei Li
	HPE		HPE
	Email: flycoolman@gmail.com		Email: flycoolman@gmail.com
	Jakob Heitz		Jakob Heitz
	Cisco		Cisco
	170 West Tasman Drive		170 West Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Email: jheitz@cisco.com		Email: jheitz@cisco.com
			Gyan Mishra
			Verizon Inc.
			Email: gyan.s.mishra@verizon.com
End of changes. 31 change blocks.
	57 lines changed or deleted		154 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/