Diff: rfc9234xml2.original.xml

	rfc9234xml2.original.xml	rfc9234.xml

	<?xml version="1.0" encoding="US-ASCII"?>	<?xml version="1.0" encoding="UTF-8"?>

	<!DOCTYPE rfc [	<!DOCTYPE rfc [

	<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC	<!ENTITY nbsp " ">
	.2119.xml">	<!ENTITY zwsp "">
	<!ENTITY RFC4271 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC	<!ENTITY nbhy "‑">
	.4271.xml">	<!ENTITY wj "⁠">
	<!ENTITY RFC4272 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.4272.xml">
	<!ENTITY RFC4486 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.4486.xml">
	<!ENTITY RFC5065 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.5065.xml">
	<!ENTITY RFC5492 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.5492.xml">
	<!ENTITY RFC7606 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.7606.xml">
	<!ENTITY RFC7705 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.7705.xml">
	<!ENTITY RFC7908 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.7908.xml">
	<!ENTITY RFC7938 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.7938.xml">
	<!ENTITY RFC8126 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8126.xml">
	<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8174.xml">
	<!ENTITY RFC8205 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8205.xml">
	<!ENTITY nbsp " ">
	]>	]>


	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" xml:lang="en" submissionType="IE
	<?rfc strict="yes" ?>	TF" category="std" consensus="true" docName="draft-ietf-idr-bgp-open-policy-23"
	<?rfc toc="yes"?>	number="9234" ipr="trust200902" tocInclude="true" tocDepth="4" symRefs="true" so
	<?rfc tocdepth="4"?>	rtRefs="true" updates="" obsoletes="" version="3">
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="yes" ?>
	<?rfc compact="yes" ?>
	<?rfc subcompact="no" ?>


	<rfc category="std" docName="draft-ietf-idr-bgp-open-policy-24" ipr="trust200902 ">
	<front>	<front>

	<title abbrev="Route Leak Prevention">Route Leak Prevention and Detection us	<title abbrev="Route Leak Prevention">Route Leak Prevention and Detection Us
	ing Roles in UPDATE and OPEN Messages</title>	ing Roles in UPDATE and OPEN Messages</title>
		<seriesInfo name="RFC" value="9234"/>
	<author fullname="Alexander Azimov" initials="A." surname="Azimov">	<author fullname="Alexander Azimov" initials="A." surname="Azimov">
	<organization>Qrator Labs & Yandex</organization>	<organization>Qrator Labs & Yandex</organization>
	<address>	<address>
	<postal>	<postal>
	<street>Ulitsa Lva Tolstogo 16</street>	<street>Ulitsa Lva Tolstogo 16</street>
	<city>Moscow</city>	<city>Moscow</city>
	<code>119021</code>	<code>119021</code>
	<country>Russian Federation</country>	<country>Russian Federation</country>
	</postal>	</postal>
	<email>a.e.azimov@gmail.com</email>	<email>a.e.azimov@gmail.com</email>

	skipping to change at line 57 ¶	skipping to change at line 39 ¶
	<address>	<address>
	<postal>	<postal>
	<street>1-y Magistralnyy tupik 5A</street>	<street>1-y Magistralnyy tupik 5A</street>
	<city>Moscow</city>	<city>Moscow</city>
	<code>123290</code>	<code>123290</code>
	<country>Russian Federation</country>	<country>Russian Federation</country>
	</postal>	</postal>
	<email>eb@qrator.net</email>	<email>eb@qrator.net</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Randy Bush" initials="R." surname="Bush">	<author fullname="Randy Bush" initials="R." surname="Bush">

	<organization>Internet Initiative Japan & Arrcus, Inc.</organization>	<organization abbrev="IIJ & Arrcus">Internet Initiative Japan & Ar rcus, Inc.</organization>
	<address>	<address>
	<postal>	<postal>
	<street>5147 Crystal Springs</street>	<street>5147 Crystal Springs</street>
	<city>Bainbridge Island</city>	<city>Bainbridge Island</city>
	<region>Washington</region>	<region>Washington</region>
	<code>98110</code>	<code>98110</code>
	<country>United States of America</country>	<country>United States of America</country>
	</postal>	</postal>
	<email>randy@psg.com</email>	<email>randy@psg.com</email>
	</address>	</address>

	skipping to change at line 71 ¶	skipping to change at line 52 ¶
	<postal>	<postal>
	<street>5147 Crystal Springs</street>	<street>5147 Crystal Springs</street>
	<city>Bainbridge Island</city>	<city>Bainbridge Island</city>
	<region>Washington</region>	<region>Washington</region>
	<code>98110</code>	<code>98110</code>
	<country>United States of America</country>	<country>United States of America</country>
	</postal>	</postal>
	<email>randy@psg.com</email>	<email>randy@psg.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Keyur Patel" initials="K." surname="Patel">	<author fullname="Keyur Patel" initials="K." surname="Patel">
	<organization>Arrcus</organization>	<organization>Arrcus</organization>
	<address>	<address>
	<postal>	<postal>

	<street>2077 Gateway Place, Suite #400</street>	<street>2077 Gateway Place</street>
		<street>Suite #400</street>
	<city>San Jose</city>	<city>San Jose</city>
	<region>CA</region>	<region>CA</region>
	<code>95119</code>	<code>95119</code>
	<country>United States of America</country>	<country>United States of America</country>

	</postal>	</postal>
	<email>keyur@arrcus.com</email>	<email>keyur@arrcus.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Kotikalapudi Sriram" initials="K." surname="Sriram">	<author fullname="Kotikalapudi Sriram" initials="K." surname="Sriram">
	<organization abbrev="USA NIST">USA National Institute of Standards and Te chnology</organization>	<organization abbrev="USA NIST">USA National Institute of Standards and Te chnology</organization>
	<address>	<address>
	<postal>	<postal>
	<street>100 Bureau Drive</street>	<street>100 Bureau Drive</street>
	<city>Gaithersburg</city>	<city>Gaithersburg</city>
	<region>MD</region>	<region>MD</region>
	<code>20899</code>	<code>20899</code>
	<country>United States of America</country>	<country>United States of America</country>
	</postal>	</postal>
	<email>ksriram@nist.gov</email>	<email>ksriram@nist.gov</email>
	</address>	</address>
	</author>	</author>

		<date year="2022" month="April" />
	<date/>	<area>rtg</area>
		<workgroup>idr</workgroup>
	<keyword>BGP</keyword>	<keyword>BGP</keyword>
	<keyword>Route leak</keyword>	<keyword>Route leak</keyword>
	<keyword>BGP Role</keyword>	<keyword>BGP Role</keyword>


	<abstract>	<abstract>
	<t>	<t>
	Route leaks are the propagation of BGP prefixes that violate assumptions of BGP topology relationships, e.g., announcing a route learned from one transi t provider to another transit provider or a lateral (i.e., non-transit) peer or announcing a route learned from one lateral peer to another lateral peer or a tr ansit provider.	Route leaks are the propagation of BGP prefixes that violate assumptions of BGP topology relationships, e.g., announcing a route learned from one transi t provider to another transit provider or a lateral (i.e., non-transit) peer or announcing a route learned from one lateral peer to another lateral peer or a tr ansit provider.
	These are usually the result of misconfigured or absent BGP route filter ing or lack of coordination between autonomous systems (ASes).	These are usually the result of misconfigured or absent BGP route filter ing or lack of coordination between autonomous systems (ASes).

	Existing approaches to leak prevention rely on marking routes by operato r configuration, with no check that the configuration corresponds to that of the eBGP neighbor, or enforcement that the two eBGP speakers agree on the peering r elationship.	Existing approaches to leak prevention rely on marking routes by operato r configuration, with no check that the configuration corresponds to that of the External BGP (eBGP) neighbor, or enforcement of the two eBGP speakers agreeing on the peering relationship.
	This document enhances the BGP OPEN message to establish an agreement of the peering relationship on each eBGP session between autonomous systems in ord er to enforce appropriate configuration on both sides.	This document enhances the BGP OPEN message to establish an agreement of the peering relationship on each eBGP session between autonomous systems in ord er to enforce appropriate configuration on both sides.
	Propagated routes are then marked according to the agreed relationship, allowing both prevention and detection of route leaks.	Propagated routes are then marked according to the agreed relationship, allowing both prevention and detection of route leaks.
	</t>	</t>
	</abstract>	</abstract>


	<note title="Requirements Language">
	<t>
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when,
	and only when, they appear in all capitals, as shown here.
	</t>
	</note>
	</front>	</front>


	<middle>	<middle>

		<section anchor="intro">
	<section title="Introduction" anchor="intro">	<name>Introduction</name>
	<t>	<t>
	Route leaks are the propagation of BGP prefixes that violate assumptions of BGP topology relationships, e.g., announcing a route learned from one transi t provider to another transit provider or a lateral (i.e., non-transit) peer or announcing a route learned from one lateral peer to another lateral peer or a tr ansit provider <xref target="RFC7908"/>.	Route leaks are the propagation of BGP prefixes that violate assumptions of BGP topology relationships, e.g., announcing a route learned from one transi t provider to another transit provider or a lateral (i.e., non-transit) peer or announcing a route learned from one lateral peer to another lateral peer or a tr ansit provider <xref target="RFC7908"/>.
	These are usually the result of misconfigured or absent BGP route filter ing or lack of coordination between autonomous systems (ASes).	These are usually the result of misconfigured or absent BGP route filter ing or lack of coordination between autonomous systems (ASes).
	</t>	</t>
	<t>	<t>

	Existing approaches to leak prevention rely on marking routes by operato r configuration, with no check that the configuration corresponds to that of the eBGP neighbor, or enforcement that the two eBGP speakers agree on the relations hip.	Existing approaches to leak prevention rely on marking routes by operato r configuration, with no check that the configuration corresponds to that of the eBGP neighbor, or enforcement of the two eBGP speakers agreeing on the relation ship.
	This document enhances the BGP OPEN message to establish an agreement of the relationship on each eBGP session between autonomous systems in order to en force appropriate configuration on both sides.	This document enhances the BGP OPEN message to establish an agreement of the relationship on each eBGP session between autonomous systems in order to en force appropriate configuration on both sides.
	Propagated routes are then marked according to the agreed relationship, allowing both prevention and detection of route leaks.	Propagated routes are then marked according to the agreed relationship, allowing both prevention and detection of route leaks.
	</t>	</t>


	<t>	<t>
	This document specifies a means of replacing the operator-driven configu ration-based method of route leak prevention, described above, with an in-band m ethod for route leak prevention and detection.	This document specifies a means of replacing the operator-driven configu ration-based method of route leak prevention, described above, with an in-band m ethod for route leak prevention and detection.
	</t>	</t>


	<t>	<t>
	This method uses a new configuration parameter, BGP Role, which is negot iated using a BGP Role Capability in the OPEN message <xref target="RFC5492"/>.	This method uses a new configuration parameter, BGP Role, which is negot iated using a BGP Role Capability in the OPEN message <xref target="RFC5492"/>.

	An eBGP speaker may require the use of this capability and confirmation of BGP Role with a neighbor for the BGP OPEN to succeed.	An eBGP speaker may require the use of this capability and confirmation of the BGP Role with a neighbor for the BGP OPEN to succeed.
	</t>	</t>


	<t>	<t>

	An optional, transitive BGP Path Attribute, called Only to Customer (OTC ), is specified in <xref target="prevention_attribute"/>.	An optional, transitive BGP Path Attribute, called "Only to Customer (OT C)", is specified in <xref target="prevention_attribute"/>.
	It prevents ASes from creating leaks and detects leaks created by the AS es in the middle of an AS path.	It prevents ASes from creating leaks and detects leaks created by the AS es in the middle of an AS path.
	The main focus/applicability is the Internet (IPv4 and IPv6 unicast rout e advertisements).	The main focus/applicability is the Internet (IPv4 and IPv6 unicast rout e advertisements).
	</t>	</t>
	</section>	</section>


	<section anchor="terminology" title="Terminology">	<section>
		<name>Requirements Language</name>

		<t>
		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
		RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
		be interpreted as
		described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
		when, and only when, they appear in all capitals, as shown here.
		</t>
		</section>

		<section anchor="terminology">
		<name>Terminology</name>
	<t>	<t>
	The terms "local AS" and "remote AS" are used to refer to the two ends o f an eBGP session.	The terms "local AS" and "remote AS" are used to refer to the two ends o f an eBGP session.
	The "local AS" is the AS where the protocol action being described is to be performed, and "remote AS" is the AS at the other end of the eBGP session in consideration.	The "local AS" is the AS where the protocol action being described is to be performed, and "remote AS" is the AS at the other end of the eBGP session in consideration.
	</t>	</t>


	<t>	<t>
	The use of the term "route is ineligible" in this document has the same meaning as in <xref target="RFC4271"/>, i.e., "route is ineligible to be install ed in Loc-RIB and will be excluded from the next phase of route selection."	The use of the term "route is ineligible" in this document has the same meaning as in <xref target="RFC4271"/>, i.e., "route is ineligible to be install ed in Loc-RIB and will be excluded from the next phase of route selection."
	</t>	</t>

	<section anchor="defs" title="Peering Relationships">	<section anchor="defs">
	<t>	<name>Peering Relationships</name>
		<t>
	The terms for peering relationships defined and used in this document (s ee below) do not necessarily represent business relationships based on payment a greements.	The terms for peering relationships defined and used in this document (s ee below) do not necessarily represent business relationships based on payment a greements.

	These terms are used to represent restrictions on BGP route propagation,	These terms are used to represent restrictions on BGP route propagation,
	sometimes known as the Gao-Rexford model <xref target="Gao"/>.	sometimes known as the Gao-Rexford model <xref target="GAO-REXFORD"/>.
	The terms Provider, Customer, and Peer used here are synonymous to the t	The terms "Provider", "Customer", and "Peer" used here are synonymous to
	erms "transit provider", "customer", and "lateral (i.e., non-transit) peer", res	the terms "transit provider", "customer", and "lateral (i.e., non-transit) peer
	pectively, used in <xref target="RFC7908"/>.	", respectively, used in <xref target="RFC7908"/>.
	</t>	</t>
	<t>	<t>
	The following is a list of BGP Roles for eBGP peering and the correspond ing rules for route propagation:	The following is a list of BGP Roles for eBGP peering and the correspond ing rules for route propagation:

	<list style="hanging">	</t>
	<t hangText="Provider:">	<dl newline="false" spacing="normal">
	MAY propagate any available route to a Customer.	<dt>Provider:</dt>
	</t>	<dd>
	<t hangText="Customer:">	<bcp14>MAY</bcp14> propagate any available route to a Customer.
	MAY propagate any route learned from a Customer, or locally originat	</dd>
	ed, to a Provider.	<dt>Customer:</dt>
	All other routes MUST NOT be propagated.	<dd>
	</t>	<bcp14>MAY</bcp14> propagate any route learned from a Customer, or t
	<t hangText="Route Server (RS):">	hat is locally originated, to a Provider.
	MAY propagate any available route to a Route Server Client (RS-Clien	All other routes <bcp14>MUST NOT</bcp14> be propagated.
	t).	</dd>
	</t>	<dt>Route Server (RS):</dt>
	<t hangText="Route Server Client (RS-Client):">	<dd>
	MAY propagate any route learned from a Customer, or locally originat	<bcp14>MAY</bcp14> propagate any available route to a Route Server C
	ed, to an RS.	lient (RS-Client).
	All other routes MUST NOT be propagated.	</dd>
	</t>	<dt>Route Server Client (RS-Client):</dt>
	<t hangText="Peer:">	<dd>
	MAY propagate any route learned from a Customer, or locally originat	<bcp14>MAY</bcp14> propagate any route learned from a Customer, or t
	ed, to a Peer.	hat is locally originated, to an RS.
	All other routes MUST NOT be propagated.	All other routes <bcp14>MUST NOT</bcp14> be propagated.
	</t>	</dd>
	</list>	<dt>Peer:</dt>
	</t>	<dd>
	<t>	<bcp14>MAY</bcp14> propagate any route learned from a Customer, or t
		hat is locally originated, to a Peer.
		All other routes <bcp14>MUST NOT</bcp14> be propagated.
		</dd>
		</dl>
		<t>
	If the local AS has one of the above Roles (in the order shown), then th e corresponding peering relationship with the remote AS is Provider-to-Customer, Customer-to-Provider, RS-to-RS-Client, RS-Client-to-RS, or Peer-to-Peer (i.e., lateral peers), respectively.	If the local AS has one of the above Roles (in the order shown), then th e corresponding peering relationship with the remote AS is Provider-to-Customer, Customer-to-Provider, RS-to-RS-Client, RS-Client-to-RS, or Peer-to-Peer (i.e., lateral peers), respectively.
	These are called normal peering relationships.	These are called normal peering relationships.

	</t>	</t>
	<t>	<t>
	If the local AS has more than one peering role with the remote AS such p	If the local AS has more than one peering Role with the remote AS, such
	eering relation is called Complex.	a peering relation is called "Complex".
	An example is when the peering relationship is Provider-to-Customer for	An example is when the peering relationship is Provider-to-Customer for
	some prefixes while it is Peer-to-Peer for other prefixes <xref target="Gao"/>.	some prefixes while it is Peer-to-Peer for other prefixes <xref target="GAO-REXF
	</t>	ORD"/>.
	<t>	</t>
		<t>
	A BGP speaker may apply policy to reduce what is announced, and a recipi ent may apply policy to reduce the set of routes they accept.	A BGP speaker may apply policy to reduce what is announced, and a recipi ent may apply policy to reduce the set of routes they accept.

	</t>	</t>
	<t>	<t>
	Violation of the route propagation rules listed above may result in rout e leaks <xref target="RFC7908"/>.	Violation of the route propagation rules listed above may result in rout e leaks <xref target="RFC7908"/>.
	Automatic enforcement of these rules should significantly reduce route l eaks that may otherwise occur due to manual configuration mistakes.	Automatic enforcement of these rules should significantly reduce route l eaks that may otherwise occur due to manual configuration mistakes.

	</t>	</t>
	<t>	<t>
	As specified in <xref target="prevention_attribute"/>, the Only to Custo	As specified in <xref target="prevention_attribute"/>, the OTC Attribute
	mer (OTC) Attribute is used to identify all the routes in the AS that have been	is used to identify all the routes in the AS that have been received from a Pee
	received from a Peer, Provider, or RS.	r, a Provider, or an RS.
	</t>	</t>
	</section>	</section>
	</section>	</section>

		<section anchor="bgp_role">
		<name>BGP Role</name>


	<section anchor="bgp_role" title="BGP Role">
	<t>	<t>
	The BGP Role characterizes the relationship between the eBGP speakers fo rming a session.	The BGP Role characterizes the relationship between the eBGP speakers fo rming a session.

	One of the Roles described below SHOULD be configured at the local AS fo r each eBGP session (see definitions in <xref target="terminology"/>) based on t he local AS's knowledge of its Role.	One of the Roles described below <bcp14>SHOULD</bcp14> be configured at the local AS for each eBGP session (see definitions in <xref target="terminology "/>) based on the local AS's knowledge of its Role.
	The only exception is when the eBGP connection is Complex (see <xref tar get="considerations"/>).	The only exception is when the eBGP connection is Complex (see <xref tar get="considerations"/>).
	BGP Roles are mutually confirmed using the BGP Role Capability (describe d in <xref target="capability"/>) on each eBGP session.	BGP Roles are mutually confirmed using the BGP Role Capability (describe d in <xref target="capability"/>) on each eBGP session.
	</t>	</t>
	<t>	<t>
	Allowed Roles for eBGP sessions are:	Allowed Roles for eBGP sessions are:

	<list style="symbols">
	<t>Provider - the local AS is a transit Provider of the remote AS;</t>
	<t>Customer - the local AS is a transit Customer of the remote AS;</t>
	<t>RS - the local AS is a Route Server (usually at an Internet exchang
	e point) and the remote AS is its RS-Client;</t>
	<t>RS-Client - the local AS is a client of an RS and the RS is the rem
	ote AS;</t>
	<t>Peer - the local and remote ASes are Peers (i.e., have a lateral pe
	ering relationship).</t>
	</list>
	</t>	</t>

	<section anchor="capability" title="BGP Role Capability">
		<dl>
		<dt>Provider:
		</dt>
		<dd>the local AS is a transit provider of the remote AS;
		</dd>

		<dt>Customer:
		</dt>
		<dd>the local AS is a transit customer of the remote AS;
		</dd>

		<dt>RS:
		</dt>
		<dd> the local AS is a Route Server (usually at an Internet exchange point), and
		the remote AS is its RS-Client;
		</dd>

		<dt>RS-Client:
		</dt>
		<dd>the local AS is a client of an RS and the RS is the remote AS; and
		</dd>

		<dt>Peer:
		</dt>
		<dd>the local and remote ASes are Peers (i.e., have a lateral peering relationsh
		ip).
		</dd>

		</dl>

		<section anchor="capability">
		<name>BGP Role Capability</name>
	<t>	<t>
	The BGP Role Capability is defined as follows:	The BGP Role Capability is defined as follows:

	<list style="symbols">
	<t>Code - 9</t>
	<t>Length - 1 (octet)</t>
	<t>Value - integer corresponding to speaker's BGP Role (see <xref ta
	rget="values"/>).</t>
	</list>
	</t>	</t>

	<texttable anchor="values" title="Predefined BGP Role Values" suppress-t	<dl>
	itle="false">	<dt>Code:
	<ttcol align="center">Value</ttcol>	</dt>
	<ttcol align="left">Role name (for the local AS)</ttcol>	<dd>9
	<c>0</c>	</dd>
	<c>Provider</c>
	<c>1</c>	<dt>Length:
	<c>RS</c>	</dt>
	<c>2</c>	<dd>1 (octet)
	<c>RS-Client</c>	</dd>
	<c>3</c>
	<c>Customer</c>	<dt>Value:
	<c>4</c>	</dt>
	<c>Peer (i.e., Lateral Peer)</c>	<dd>integer corresponding to the speaker's BGP Role (see <xref
	<c>5-255</c>	target="values"/>)
	<c>Unassigned</c>	</dd>
	</texttable>	</dl>

		<table anchor="values">
		<name>Predefined BGP Role Values</name>
		<thead>
		<tr>
		<th align="center">Value</th>
		<th align="left">Role name (for the local AS)</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td align="center">0</td>
		<td align="left">Provider</td>
		</tr>
		<tr>
		<td align="center">1</td>
		<td align="left">RS</td>
		</tr>
		<tr>
		<td align="center">2</td>
		<td align="left">RS-Client</td>
		</tr>
		<tr>
		<td align="center">3</td>
		<td align="left">Customer</td>
		</tr>
		<tr>
		<td align="center">4</td>
		<td align="left">Peer (i.e., Lateral Peer)</td>
		</tr>
		<tr>
		<td align="center">5-255</td>
		<td align="left">Unassigned</td>
		</tr>
		</tbody>
		</table>
	<t>	<t>

	If BGP Role is locally configured, the eBGP speaker MUST advertise BGP	If the BGP Role is locally configured, the eBGP speaker <bcp14>MUST</b
	Role Capability in the BGP OPEN message.	cp14> advertise the BGP Role Capability in the BGP OPEN message.
	An eBGP speaker MUST NOT advertise multiple versions of the BGP Role C	An eBGP speaker <bcp14>MUST NOT</bcp14> advertise multiple versions of
	apability.	the BGP Role Capability.
	The error handling when multiple BGP Role Capabilities are received is described in <xref target="correctness"/>.	The error handling when multiple BGP Role Capabilities are received is described in <xref target="correctness"/>.
	</t>	</t>


	</section>	</section>

	<section anchor="correctness" title="Role Correctness">	<section anchor="correctness">
		<name>Role Correctness</name>
	<t>	<t>

	<xref target="capability"/> described how BGP Role encodes the relatio nship on each eBGP session between autonomous systems (ASes).	<xref target="capability"/> describes how the BGP Role encodes the rel ationship on each eBGP session between ASes.
	</t>	</t>

	<t>	<t>

	The mere receipt of BGP Role Capability does not automatically guarant	The mere receipt of the BGP Role Capability does not automatically gua
	ee the Role agreement between two eBGP neighbors.	rantee the Role agreement between two eBGP neighbors.
	If the BGP Role Capability is advertised, and one is also received fro	If the BGP Role Capability is advertised, and one is also received fro
	m the peer, the Roles MUST correspond to the relationships in Table 2.	m the peer, the Roles <bcp14>MUST</bcp14> correspond to the relationships in <xr
	If the Roles do not correspond, the BGP speaker MUST reject the connec	ef target="allowed"/>.
	tion using the Role Mismatch Notification (code 2, subcode TBD).
	</t>
	<texttable anchor="allowed" title="Allowed Pairs of Role Capabilities" s
	uppress-title="false">
	<ttcol align="left">Local AS Role</ttcol>
	<ttcol align="left">Remote AS Role</ttcol>
	<c>Provider</c>
	<c>Customer</c>

	<c>Customer</c>
	<c>Provider</c>

	<c>RS</c>
	<c>RS-Client</c>

	<c>RS-Client</c>
	<c>RS</c>


	<c>Peer</c>	If the Roles do not correspond, the BGP speaker <bcp14>MUST</bcp14> re
	<c>Peer</c>	ject the connection using the Role Mismatch Notification (code 2, subcode 11).
	</texttable>	</t>
		<table anchor="allowed">
		<name>Allowed Pairs of Role Capabilities</name>
		<thead>
		<tr>
		<th align="left">Local AS Role</th>
		<th align="left">Remote AS Role</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td align="left">Provider</td>
		<td align="left">Customer</td>
		</tr>
		<tr>
		<td align="left">Customer</td>
		<td align="left">Provider</td>
		</tr>
		<tr>
		<td align="left">RS</td>
		<td align="left">RS-Client</td>
		</tr>
		<tr>
		<td align="left">RS-Client</td>
		<td align="left">RS</td>
		</tr>
		<tr>
		<td align="left">Peer</td>
		<td align="left">Peer</td>
		</tr>
		</tbody>
		</table>
	<t>	<t>

	For backward compatibility, if the BGP Role Capability is sent but one is not received, the BGP Speaker SHOULD ignore the absence of the BGP Role Capa bility and proceed with session establishment.	For backward compatibility, if the BGP Role Capability is sent but one is not received, the BGP Speaker <bcp14>SHOULD</bcp14> ignore the absence of th e BGP Role Capability and proceed with session establishment.
	The locally configured BGP Role is used for the procedures described i n <xref target="prevention_attribute"/>.	The locally configured BGP Role is used for the procedures described i n <xref target="prevention_attribute"/>.
	</t>	</t>
	<t>	<t>
	An operator may choose to apply a "strict mode" in which the receipt o f a BGP Role Capability from the remote AS is required.	An operator may choose to apply a "strict mode" in which the receipt o f a BGP Role Capability from the remote AS is required.

	When operating in the "strict mode", if the BGP Role Capability is sen t, but one is not received, then the connection is rejected using the Role Misma tch Notification (code 2, subcode TBD). See comments in <xref target="Security"/ >.	When operating in the "strict mode", if the BGP Role Capability is sen t but one is not received, the connection is rejected using the Role Mismatch No tification (code 2, subcode 11). See comments in <xref target="Security"/>.
	</t>	</t>
	<t>	<t>
	If an eBGP speaker receives multiple but identical BGP Role Capabiliti es with the same value in each, then the speaker considers them to be a single B GP Role Capability and proceeds <xref target="RFC5492"/>.	If an eBGP speaker receives multiple but identical BGP Role Capabiliti es with the same value in each, then the speaker considers them to be a single B GP Role Capability and proceeds <xref target="RFC5492"/>.

	If multiple BGP Role Capabilities are received and not all of them hav e the same value, then the BGP speaker MUST reject the connection using the Role Mismatch Notification (code 2, subcode TBD).	If multiple BGP Role Capabilities are received and not all of them hav e the same value, then the BGP speaker <bcp14>MUST</bcp14> reject the connection using the Role Mismatch Notification (code 2, subcode 11).
	</t>	</t>
	<t>	<t>
	The BGP Role value for the local AS (in conjunction with the OTC Attri bute in the received UPDATE message) is used in the route leak prevention and de tection procedures described in <xref target="prevention_attribute"/>.	The BGP Role value for the local AS (in conjunction with the OTC Attri bute in the received UPDATE message) is used in the route leak prevention and de tection procedures described in <xref target="prevention_attribute"/>.
	</t>	</t>
	</section>	</section>
	</section>	</section>

		<section anchor="prevention_attribute">
	<section anchor="prevention_attribute" title="BGP Only to Customer (OTC) Att	<name>BGP Only to Customer (OTC) Attribute</name>
	ribute">
	<t>	<t>

	The Only to Customer (OTC) Attribute is an optional transitive path attr	The OTC Attribute is an optional transitive Path Attribute of the UPDATE
	ibute of the UPDATE message with Attribute Type Code 35 and a length of 4 octets	message with Attribute Type Code 35 and a length of 4 octets.
	.	The purpose of this attribute is to enforce that once a route is sent to
	The purpose of this attribute is to enforce that once a route is sent to	a Customer, a Peer, or an RS-Client (see definitions in <xref target="defs"/>),
	a Customer, Peer, or RS-Client (see definitions in <xref target="defs"/>), it w	it will subsequently go only to the Customers.
	ill subsequently go only to Customers.
	The attribute value is an AS number (ASN) determined by the procedures d escribed below.	The attribute value is an AS number (ASN) determined by the procedures d escribed below.
	</t>	</t>
	<t>	<t>
	The following ingress procedure applies to the processing of the OTC Att ribute on route receipt:	The following ingress procedure applies to the processing of the OTC Att ribute on route receipt:

	<list style="numbers">
	<t>
	If a route with the OTC Attribute is received from a Customer or RS-
	Client, then it is a route leak and MUST be considered ineligible (see <xref tar
	get="terminology"/>).
	</t>
	<t>
	If a route with the OTC Attribute is received from a Peer (i.e., rem
	ote AS with a Peer Role) and the Attribute has a value that is not equal to the
	remote (i.e., Peer's) AS number, then it is a route leak and MUST be considered
	ineligible.
	</t>
	<t>
	If a route is received from a Provider, Peer, or RS, and the OTC Att
	ribute is not present, then it MUST be added with a value equal to the AS number
	of the remote AS.
	</t>
	</list>
	</t>	</t>

		<ol spacing="normal" type="1"><li>
		If a route with the OTC Attribute is received from a Customer or an
		RS-Client, then it is a route leak and <bcp14>MUST</bcp14> be considered ineligi
		ble (see <xref target="terminology"/>).
		</li>
		<li>
		If a route with the OTC Attribute is received from a Peer (i.e., rem
		ote AS with a Peer Role) and the Attribute has a value that is not equal to the
		remote (i.e., Peer's) AS number, then it is a route leak and <bcp14>MUST</bcp14>
		be considered ineligible.
		</li>
		<li>
		If a route is received from a Provider, a Peer, or an RS and the OTC
		Attribute is not present, then it <bcp14>MUST</bcp14> be added with a value equ
		al to the AS number of the remote AS.
		</li>
		</ol>
	<t>	<t>
	The following egress procedure applies to the processing of the OTC Attr ibute on route advertisement:	The following egress procedure applies to the processing of the OTC Attr ibute on route advertisement:

	<list style="numbers">
	<t>
	If a route is to be advertised to a Customer, Peer, or RS-Client (wh
	en the sender is an RS), and the OTC Attribute is not present, then when adverti
	sing the route, an OTC Attribute MUST be added with a value equal to the AS numb
	er of the local AS.
	</t>
	<t>
	If a route already contains the OTC Attribute, it MUST NOT be propag
	ated to Providers, Peers, or RS(s).
	</t>
	</list>
	</t>	</t>

		<ol spacing="normal" type="1"><li>
		If a route is to be advertised to a Customer, a Peer, or an RS-Clien
		t (when the sender is an RS), and the OTC Attribute is not present, then when ad
		vertising the route, an OTC Attribute <bcp14>MUST</bcp14> be added with a value
		equal to the AS number of the local AS.
		</li>


		<li>
		If a route already contains the OTC Attribute, it <bcp14>MUST NOT</b
		cp14> be propagated to Providers, Peers, or RSes.
		</li>
		</ol>
	<t>	<t>
	The above-described procedures provide both leak prevention for the loca l AS and leak detection and mitigation multiple hops away.	The above-described procedures provide both leak prevention for the loca l AS and leak detection and mitigation multiple hops away.

	In the case of prevention at the local AS, the presence of an OTC Attrib
	ute indicates to the egress router that the route was learned from a Peer, Provi	In the case of prevention at the local AS, the presence of an OTC Attrib
	der, or RS, and it can be advertised only to the customers.	ute indicates to the egress router that the route was learned from a Peer, a Pro
	The same OTC Attribute which is set locally also provides a way to detec	vider, or an RS, and it can be advertised only to the Customers.
	t route leaks by an AS multiple hops away if a route is received from a Customer	The same OTC Attribute that is set locally also provides a way to detect
	, Peer, or RS-Client.	route leaks by an AS multiple hops away if a route is received from a Customer,
		a Peer, or an RS-Client.
	For example, if an AS sets the OTC Attribute on a route sent to a Peer a nd the route is subsequently received by a compliant AS from a Customer, then th e receiving AS detects (based on the presence of the OTC Attribute) that the rou te is a leak.	For example, if an AS sets the OTC Attribute on a route sent to a Peer a nd the route is subsequently received by a compliant AS from a Customer, then th e receiving AS detects (based on the presence of the OTC Attribute) that the rou te is a leak.
	</t>	</t>


	<t>	<t>
	The OTC Attribute might be set at the egress of the remote AS or at the ingress of the local AS, i.e., if the remote AS is non-compliant with this speci fication, then the local AS will have to set the OTC Attribute if it is absent.	The OTC Attribute might be set at the egress of the remote AS or at the ingress of the local AS, i.e., if the remote AS is non-compliant with this speci fication, then the local AS will have to set the OTC Attribute if it is absent.
	In both scenarios, the OTC value will be the same.	In both scenarios, the OTC value will be the same.
	This makes the scheme more robust and benefits early adopters.	This makes the scheme more robust and benefits early adopters.
	</t>	</t>


	<t>	<t>

	The OTC Attribute is considered malformed if the length value is not 4. An UPDAT E message with a malformed OTC Attribute SHALL be handled using the approach of "treat-as-withdraw" <xref target="RFC7606"/>.	The OTC Attribute is considered malformed if the length value is not 4. An UPDAT E message with a malformed OTC Attribute <bcp14>SHALL</bcp14> be handled using t he approach of "treat-as-withdraw" <xref target="RFC7606"/>.
	</t>	</t>


	<t>	<t>

	The BGP Role negotiation and OTC Attribute based procedures specified in	The BGP Role negotiation and OTC-Attribute-based procedures specified in
	this document are NOT RECOMMENDED to be used between autonomous systems in an A	this document are <bcp14>NOT RECOMMENDED</bcp14> to be used between autonomous
	S Confederation <xref target="RFC5065"/>.	systems in an AS Confederation <xref target="RFC5065"/>.
	If an OTC Attribute is added on egress from the AS Confederation, its va	If an OTC Attribute is added on egress from the AS Confederation, its va
	lue MUST equal the AS Confederation Identifier.	lue <bcp14>MUST</bcp14> equal the AS Confederation Identifier.
	Also, on egress from the AS Confederation, an UPDATE MUST NOT contain an	Also, on egress from the AS Confederation, an UPDATE <bcp14>MUST NOT</bc
	OTC Attribute with a value corresponding to any Member-AS Number other than the	p14> contain an OTC Attribute with a value corresponding to any Member-AS Number
	AS Confederation Identifier.	other than the AS Confederation Identifier.
	</t>	</t>
	<t>	<t>

	The procedures specified in this document in scenarios that use private	The procedures specified in this document in scenarios that use private
	AS numbers behind an Internet-facing ASN (e.g., a data center network <xref targ	AS numbers behind an Internet-facing ASN (e.g., a data-center network <xref targ
	et="RFC7938"/> or stub customer) may be used, but any details are outside the sc	et="RFC7938"/> or stub customer) may be used, but any details are outside the sc
	ope of this document.	ope of this document.
	On egress from the Internet-facing AS, the OTC Attribute MUST NOT contai	On egress from the Internet-facing AS, the OTC Attribute <bcp14>MUST NOT
	n a value other than the Internet-facing ASN.	</bcp14> contain a value other than the Internet-facing ASN.
	</t>	</t>
	<t>	<t>

	Once the OTC Attribute has been set, it MUST be preserved unchanged (thi s also applies to an AS Confederation).	Once the OTC Attribute has been set, it <bcp14>MUST</bcp14> be preserved unchanged (this also applies to an AS Confederation).
	</t>	</t>


	<t>	<t>

	The described ingress and egress procedures are applicable only for the	The described ingress and egress procedures are applicable only for the
	address families AFI 1 (IPv4) and AFI 2 (IPv6) with SAFI 1 (unicast) in both cas	address families AFI 1 (IPv4) and AFI 2 (IPv6) with SAFI 1 (unicast) in both cas
	es and MUST NOT be applied to other address families by default.	es and <bcp14>MUST NOT</bcp14> be applied to other address families by default.
	The operator MUST NOT have the ability to modify the procedures defined	The operator <bcp14>MUST NOT</bcp14> have the ability to modify the proc
	in this section.	edures defined in this section.
	</t>	</t>
	</section>	</section>


	<section anchor="considerations" title="Additional Considerations">	<section anchor="considerations">
		<name>Additional Considerations</name>
	<t>	<t>

	Roles MUST NOT be configured on an eBGP session with a Complex peering r	Roles <bcp14>MUST NOT</bcp14> be configured on an eBGP session with a Co
	elationship.	mplex peering relationship.
	If multiple eBGP sessions can segregate the Complex peering relationship	If multiple eBGP sessions can segregate the Complex peering relationship
	into eBGP sessions with normal peering relationships, BGP Roles SHOULD be used	into eBGP sessions with normal peering relationships, BGP Roles <bcp14>SHOULD</
	on each of the resulting eBGP sessions.	bcp14> be used on each of the resulting eBGP sessions.
	</t>	</t>


	<t>	<t>
	An operator may want to achieve an equivalent outcome by configuring pol icies on a per-prefix basis to follow the definitions of peering relations as de scribed in <xref target="defs"/>.	An operator may want to achieve an equivalent outcome by configuring pol icies on a per-prefix basis to follow the definitions of peering relations as de scribed in <xref target="defs"/>.
	However, in this case, there are no in-band measures to check the correc tness of the per-prefix peering configuration.	However, in this case, there are no in-band measures to check the correc tness of the per-prefix peering configuration.
	</t>	</t>


	<t>	<t>
	The incorrect setting of BGP Roles and/or OTC Attributes may affect pref ix propagation.	The incorrect setting of BGP Roles and/or OTC Attributes may affect pref ix propagation.
	Further, this document does not specify any special handling of an incor rect AS number in the OTC Attribute.	Further, this document does not specify any special handling of an incor rect AS number in the OTC Attribute.
	</t>	</t>


	<t>	<t>
	In AS migration scenarios <xref target="RFC7705"/>, a given router may r epresent itself as any one of several different ASes.	In AS migration scenarios <xref target="RFC7705"/>, a given router may r epresent itself as any one of several different ASes.
	This should not be a problem since the egress procedures in <xref target ="prevention_attribute"/> specify that the OTC Attribute is to be attached as pa rt of route transmission.	This should not be a problem since the egress procedures in <xref target ="prevention_attribute"/> specify that the OTC Attribute is to be attached as pa rt of route transmission.
	Therefore, a router is expected to set the OTC value equal to the ASN it is currently representing itself as.	Therefore, a router is expected to set the OTC value equal to the ASN it is currently representing itself as.
	</t>	</t>
	<t>	<t>

	Section 6 of <xref target="RFC7606"/> documents possible negative impacts of "tr eat-as-withdraw" behavior. Such negative impacts may include forwarding loops o r blackholes. It also discusses debugging considerations related to this behavi or.	<xref target="RFC7606" sectionFormat="of" section="6"/> documents possible negat ive impacts of "treat-as-withdraw" behavior. Such negative impacts may include forwarding loops or dropped traffic. It also discusses debugging considerations related to this behavior.
	</t>	</t>
	</section>	</section>

		<section anchor="IANA">
		<name>IANA Considerations</name>


	<section anchor="IANA" title="IANA Considerations">
	<t>	<t>

	IANA has registered a new BGP Capability (<xref target="capability"/>) i n the "Capability Codes" registry's "IETF Review" range <xref target="RFC5492"/> .	IANA has registered a new BGP Capability (<xref target="capability"/>) i n the "Capability Codes" registry within the "IETF Review" range <xref target="R FC5492"/>.
	The description for the new capability is "BGP Role".	The description for the new capability is "BGP Role".

	IANA has assigned the value 9 [to be removed upon publication: https://w ww.iana.org/assignments/capability-codes/capability-codes.xhtml].	IANA has assigned the value 9.
	This document is the reference for the new capability.	This document is the reference for the new capability.
	</t>	</t>

	<t>	<t>

	The BGP Role capability includes a Value field, for which IANA is reques	IANA has created and now maintains a new subregistry called "BGP Role Val
	ted to create and maintain a new sub-registry called "BGP Role Value" in the Cap	ue" within the "Capability Codes" registry. Registrations should include a value
	ability Codes registry.	, a role name, and a reference to the defining document. IANA has registered the
	Assignments consist of a Value and a corresponding Role name.	values in <xref target="role-table"/>. Future assignments may be made by the "I
	Initially, this registry is to be populated with the data contained in <	ETF Review" policy as defined in <xref target="RFC8126"/>.
	xref target="values"/> found in <xref target="capability"/>.	</t>
	Future assignments may be made by the "IETF Review" policy as defined in	<table anchor="role-table">
	<xref target="RFC8126"/>. The registry is as shown in <xref target="role-table"	<name>IANA Registry for BGP Role</name>
	/>.	<thead>
	</t>	<tr>
	<texttable anchor="role-table" title="IANA Registry for BGP Role" suppress	<th align="center">Value</th>
	-title="false">	<th align="left">Role name (for the local AS)</th>
	<ttcol align="center">Value</ttcol>	<th align="center">Reference</th>
	<ttcol align="left">Role name (for the local AS)</ttcol>	</tr>
	<ttcol align="center">Reference</ttcol>	</thead>
		<tbody>
	<c>0</c>	<tr>
	<c>Provider</c>	<td align="center">0</td>
	<c>This document</c>	<td align="left">Provider</td>
	<c>1</c>	<td align="center">This document</td>
	<c>RS</c>	</tr>
	<c>This document</c>	<tr>
	<c>2</c>	<td align="center">1</td>
	<c>RS-Client</c>	<td align="left">RS</td>
	<c>This document</c>	<td align="center">This document</td>
	<c>3</c>	</tr>
	<c>Customer</c>	<tr>
	<c>This document</c>	<td align="center">2</td>
	<c>4</c>	<td align="left">RS-Client</td>
	<c>Peer (i.e., Lateral Peer)</c>	<td align="center">This document</td>
	<c>This document</c>	</tr>
	<c>5-255</c>	<tr>
	<c>To be assigned by IETF Review </c>	<td align="center">3</td>
	<c/>	<td align="left">Customer</td>
	</texttable>	<td align="center">This document</td>
		</tr>
	<t>	<tr>
	IANA has registered a new OPEN Message Error subcode named the "Role Mis	<td align="center">4</td>
	match" (see <xref target="correctness"/>) in the OPEN Message Error subcodes reg	<td align="left">Peer (i.e., Lateral Peer)</td>
	istry.	<td align="center">This document</td>
	IANA has assigned the value 11 [to be removed upon publication: https://	</tr>
	www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-6].	<tr>
	This document is the reference for the new subcode.	<td align="center">5-255</td>
	</t>	<td align="left">To be assigned by IETF Review </td>
		<td align="center"/>
		</tr>
		</tbody>
		</table>
	<t>	<t>

	Due to improper use of the values 8, 9, and 10 in the OPEN Message Error subcode	IANA has registered a new OPEN Message Error subcode named "Role Mismatc
	s registry, this document requested IANA to mark these values as "Deprecated". I	h" (see <xref target="correctness"/>) in the "OPEN Message Error subcodes" regis
	ANA has marked values 8-10 as "Deprecated" in the OPEN Message Error subcodes re	try.
	gistry. This document is listed as the reference.	IANA has assigned the value 11. This document is the reference for the n
		ew subcode.
	</t>	</t>


		<t>Due to improper use of the values 8, 9, and 10, IANA has marked values
		8-10 as "Deprecated" in
		the "OPEN Message Error subcodes" registry. This document is listed as
		the reference.</t>
	<t>	<t>

	IANA has also registered a new path attribute named "Only to Customer (O	IANA has also registered a new Path Attribute named "Only to Customer (O
	TC)" (see <xref target="prevention_attribute"/>) in the "BGP Path Attributes" re	TC)" (see <xref target="prevention_attribute"/>) in the "BGP Path Attributes" re
	gistry.	gistry.
	IANA has assigned code value 35 [To be removed upon publication: http://	IANA has assigned code value 35.
	www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-2].
	This document is the reference for the new attribute.	This document is the reference for the new attribute.
	</t>	</t>
	</section>	</section>

		<section anchor="Security">
	<section anchor="Security" title="Security Considerations">	<name>Security Considerations</name>
	<t>	<t>
	The security considerations of BGP (as specified in <xref target="RFC427 1"/> and <xref target="RFC4272"/>) apply.	The security considerations of BGP (as specified in <xref target="RFC427 1"/> and <xref target="RFC4272"/>) apply.
	</t>	</t>


	<t>	<t>

	This document proposes a mechanism using BGP Role for the prevention and detection of route leaks that are the result of BGP policy misconfiguration.	This document proposes a mechanism that uses the BGP Role for the preven tion and detection of route leaks that are the result of BGP policy misconfigura tion.
	A misconfiguration of the BGP Role may affect prefix propagation.	A misconfiguration of the BGP Role may affect prefix propagation.

	For example, if a downstream (i.e., towards a Customer) peering link wer	For example, if a downstream (i.e., towards a Customer) peering link wer
	e misconfigured with a Provider or Peer Role, this will limit the number of pref	e misconfigured with a Provider or Peer Role, it would limit the number of prefi
	ixes that can be advertised in this direction.	xes that can be advertised in this direction.
	On the other hand, if an upstream provider were misconfigured (by a loca	On the other hand, if an upstream provider were misconfigured (by a loca
	l AS) with the Customer Role, this may result in propagating routes that are rec	l AS) with the Customer Role, it may result in propagating routes that are recei
	eived from other Providers or Peers.	ved from other Providers or Peers.
	But the BGP Role negotiation and the resulting confirmation of Roles mak e such misconfigurations unlikely.	But the BGP Role negotiation and the resulting confirmation of Roles mak e such misconfigurations unlikely.
	</t>	</t>


	<t>	<t>
	Setting the strict mode of operation for BGP Role negotiation as the def ault may result in a situation where the eBGP session will not come up after a s oftware update.	Setting the strict mode of operation for BGP Role negotiation as the def ault may result in a situation where the eBGP session will not come up after a s oftware update.
	Implementations with such default behavior are strongly discouraged.	Implementations with such default behavior are strongly discouraged.
	</t>	</t>


	<t>	<t>
	Removing the OTC Attribute or changing its value can limit the opportuni ty for route leak detection.	Removing the OTC Attribute or changing its value can limit the opportuni ty for route leak detection.
	Such activity can be done on purpose as part of an on-path attack.	Such activity can be done on purpose as part of an on-path attack.
	For example, an AS can remove the OTC Attribute on a received route and then leak the route to its transit provider.	For example, an AS can remove the OTC Attribute on a received route and then leak the route to its transit provider.

	This kind of threat is not new in BGP and it may affect any Attribute (N ote: BGPsec <xref target="RFC8205"/> offers protection only for the AS_PATH Attr ibute).	This kind of threat is not new in BGP, and it may affect any Attribute ( note that BGPsec <xref target="RFC8205"/> offers protection only for the AS_PATH Attribute).
	</t>	</t>


	<t>	<t>
	Adding an OTC Attribute when the route is advertised from Customer to Pr ovider will limit the propagation of the route.	Adding an OTC Attribute when the route is advertised from Customer to Pr ovider will limit the propagation of the route.

	Such a route may be considered as ineligible by the immediate Provider o r its Peers or upper layer Providers.	Such a route may be considered as ineligible by the immediate Provider o r its Peers or upper-layer Providers.
	This kind of OTC Attribute addition is unlikely to happen on the Provide r side because it will limit the traffic volume towards its Customer.	This kind of OTC Attribute addition is unlikely to happen on the Provide r side because it will limit the traffic volume towards its Customer.

	On the Customer side, adding an OTC Attribute for traffic engineering pu rposes is also discouraged because it will limit route propagation in an unpredi ctable way.	On the Customer side, adding an OTC Attribute for traffic-engineering pu rposes is also discouraged because it will limit route propagation in an unpredi ctable way.
	</t>	</t>
	</section>	</section>
	</middle>	</middle>


	<back>	<back>

	<references title="Normative References">	<references>
	&RFC2119;	<name>References</name>
	&RFC4271;	<references>
	&RFC5065;	<name>Normative References</name>
	&RFC5492;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	&RFC7606;	FC.2119.xml"/>
	&RFC7908;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	&RFC8126;	FC.4271.xml"/>
	&RFC8174;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	</references>	FC.5065.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<references title="Informative References">	FC.5492.xml"/>
	&RFC8205;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	&RFC4272;	FC.7606.xml"/>
	&RFC7938;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	&RFC7705;	FC.7908.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<reference anchor="Gao" target="https://ieeexplore.ieee.org/document/97452	FC.8126.xml"/>
	3">	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<front>	FC.8174.xml"/>
	<title>Stable Internet routing without global coordination</title>	</references>
		<references>
		<name>Informative References</name>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8205.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.4272.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7938.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7705.xml"/>


	<author initials="L." surname="Gao">	<reference anchor="GAO-REXFORD" target="https://ieeexplore.ieee.org/docu
		ment/974523">
		<front>
		<title>Stable Internet routing without global coordination</title>
		<author initials="L." surname="Gao">
	</author>	</author>

	<author initials="J." surname="Rexford">	<author initials="J." surname="Rexford">
	</author>	</author>

		<date month="December" year="2001"/>
		</front>
		<refcontent>IEEE/ACM Transactions on Networking, Volume 9, Issue 6, pp.
		689-692
		</refcontent>
		<seriesInfo name="DOI" value="10.1109/90.974523"/>
		</reference>


	<date month='December' year='2001' />	</references>
	</front>
	<seriesInfo name='' value='IEEE/ACM Transactions on Networking, Volume 9
	, Issue 6, pp 689-692, DOI 10.1109/90.974523' />
	</reference>

	</references>	</references>

		<section numbered="false">
	<section title="Acknowledgments" numbered="no">	<name>Acknowledgments</name>
	<t>	<t>

	The authors wish to thank Alvaro Retana, Bruno Decraene, Jeff Haas, John Scudder, Sue Hares, Ben Maddison, Andrei Robachevsky, Daniel Ginsburg, Ruediger Volk, Pavel Lunin, Gyan Mishra, and Ignas Bagdonas for review, comments, and su ggestions during the course of this work. Thanks are also due to many IESG revi ewers whose comments greatly helped improve the clarity, accuracy, and presentat ion in the document.	The authors wish to thank <contact fullname="Alvaro Retana"/>, <contact fullname="Bruno Decraene"/>, <contact fullname="Jeff Haas"/>, <contact fullname= "John Scudder"/>, <contact fullname="Sue Hares"/>, <contact fullname="Ben Maddis on"/>, <contact fullname="Andrei Robachevsky"/>, <contact fullname="Daniel Ginsb urg"/>, <contact fullname="Ruediger Volk"/>, <contact fullname="Pavel Lunin"/>, <contact fullname="Gyan Mishra"/>, and <contact fullname="Ignas Bagdonas"/> for their reviews, comments, and suggestions during the course of this work. Thanks are also due to many IESG reviewers whose comments greatly helped improve the c larity, accuracy, and presentation in the document.
	</t>	</t>
	</section>	</section>

	<section title="Contributors" numbered="no">	<section numbered="false">
	<figure><artwork><![CDATA[	<name>Contributors</name>

	Brian Dickson
	Independent
	Email: brian.peter.dickson@gmail.com


	Doug Montgomery	<author fullname="Brian Dickson" initials="B" surname="Dickson">
	USA National Institute of Standards and Technology	<organization>Independent</organization>
	Email: dougm@nist.gov	<address>
		<email>brian.peter.dickson@gmail.com</email>
		</address>
		</author>


	]]></artwork></figure>	<author fullname="Doug Montgomery" initials="D" surname="Montgomery">
		<organization>USA National Institute of Standards and Technology</organiza
		tion>
		<address>
		<email>dougm@nist.gov</email>
		</address>
		</author>

	</section>	</section>
	</back>	</back>
	</rfc>	</rfc>

End of changes. 99 change blocks.
	388 lines changed or deleted	452 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/