rfc9774xml2.original.xml   rfc9774.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.2119.xml">
<!ENTITY rfc4271 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.4271.xml">
<!ENTITY rfc4632 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.4632.xml">
<!ENTITY rfc6793 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.6793.xml">
<!ENTITY rfc5065 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.5065.xml">
<!ENTITY rfc3779 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.3779.xml">
<!ENTITY rfc6472 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.6472.xml">
<!ENTITY rfc9582 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.9582.xml">
<!ENTITY rfc6480 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.6480.xml">
<!ENTITY rfc6811 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.6811.xml">
<!ENTITY rfc6907 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.6907.xml">
<!ENTITY rfc7606 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.7606.xml">
<!ENTITY rfc8205 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.8205.xml">
<!ENTITY rfc8174 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.8174.xml">
<!ENTITY rfc9319 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.9319.xml">
<!ENTITY I-D.ietf-sidrops-aspa-verification SYSTEM "http://xml.resource.org/publ
ic/rfc/bibxml3/reference.I-D.ietf-sidrops-aspa-verification.xml">
]>
<rfc submissionType="IETF" category="std" docName="draft-ietf-idr-deprecate-as-s
et-confed-set-18" updates="4271 5065" obsoletes="6472" ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<!-- Don't put each section on its own page --> <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
std" docName="draft-ietf-idr-deprecate-as-set-confed-set-18" number="9774" conse
nsus="true" updates="4271, 5065" obsoletes="6472" ipr="trust200902" xml:lang="en
" tocInclude="true" symRefs="true" sortRefs="true" version="3">
<front> <front>
<title abbrev="AS_SET, AS_CONFED_SET use deprecation">Deprecation of AS_SET <title abbrev="Deprecation of AS_SET and AS_CONFED_SET">Deprecation of AS_SE
and AS_CONFED_SET in BGP</title> T and AS_CONFED_SET in BGP</title>
<seriesInfo name="RFC" value="9774"/>
<author fullname="Warren Kumari" initials="W" surname="Kumari"> <author fullname="Warren Kumari" initials="W" surname="Kumari">
<organization>Google, Inc.</organization> <organization>Google, Inc.</organization>
<address> <address>
<postal> <postal>
<street>1600 Amphitheatre Parkway</street> <street>1600 Amphitheatre Parkway</street>
<city>Mountain View</city> <city>Mountain View</city>
<region>CA</region> <region>CA</region>
<code>94043</code> <code>94043</code>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<phone>+1 571 748 4373</phone> <phone>+1 571 748 4373</phone>
<email>warren@kumari.net</email> <email>warren@kumari.net</email>
</address> </address>
</author> </author>
<author fullname="Kotikalapudi Sriram" initials="K" surname="Sriram"> <author fullname="Kotikalapudi Sriram" initials="K" surname="Sriram">
<organization>USA NIST</organization> <organization>USA NIST</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>US</country> <country>United States of America</country>
</postal> </postal>
<phone>+1 301 975 3973</phone> <phone>+1 301 975 3973</phone>
<email>ksriram@nist.gov</email> <email>ksriram@nist.gov</email>
</address> </address>
</author> </author>
<author fullname="Lilia Hannachi" initials="L" surname="Hannachi"> <author fullname="Lilia Hannachi" initials="L" surname="Hannachi">
<organization>USA NIST</organization> <organization>USA NIST</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>US</country> <country>United States of America</country>
</postal> </postal>
<phone>+1 301 975 3259</phone> <phone>+1 301 975 3259</phone>
<email>lilia.hannachi@nist.gov</email> <email>lilia.hannachi@nist.gov</email>
</address> </address>
</author> </author>
<author fullname="Jeffrey Haas" initials="J." surname="Haas"> <author fullname="Jeffrey Haas" initials="J." surname="Haas">
<organization>Juniper Networks, Inc.</organization> <organization>Juniper Networks, Inc.</organization>
<address> <address>
<postal> <postal>
<street>1133 Innovation Way</street> <street>1133 Innovation Way</street>
<city>Sunnyvale</city> <city>Sunnyvale</city>
<region>CA</region> <region>CA</region>
<code>94089</code> <code>94089</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>jhaas@juniper.net</email> <email>jhaas@juniper.net</email>
</address> </address>
</author> </author>
<date year="2025" month="May"/>
<date year="" /> <area>RTG</area>
<workgroup>idr</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in the
title) for use on http://www.rfc-editor.org/rfcsearch.html.
BGP, BGP-4, Network Operator, RPKI, Aggregation, RPKI-based Route Origin Valida
tion, RPKI-ROV -->
<abstract> <abstract>
<t>BCP 172 (i.e., RFC 6472) recommends not using AS_SET and AS_CONFED_SET <t>BCP 172 (i.e., RFC 6472) recommends not using AS_SET and AS_CONFED_SET
AS_PATH segment types in the Border Gateway Protocol (BGP). This document AS_PATH segment types in the Border Gateway Protocol (BGP). This document
advances that recommendation to a standards requirement in BGP; it advances that recommendation to a standards requirement in BGP; it
prohibits the use of the AS_SET and AS_CONFED_SET path segment types prohibits the use of the AS_SET and AS_CONFED_SET path segment types
in the AS_PATH. This is done to simplify the design and implementation in the AS_PATH. This is done to simplify the design and implementation
of BGP and to make the semantics of the originator of a BGP route clearer. of BGP and to make the semantics of the originator of a BGP route clearer.
This will also simplify the design, implementation, and deployment of This will also simplify the design, implementation, and deployment of
various BGP security mechanisms. This document updates RFC 4271 by various BGP security mechanisms. This document updates RFC 4271 by
deprecating the origination of BGP routes with AS_SET (Type 1 AS_PATH segm ent) and deprecating the origination of BGP routes with AS_SET (Type 1 AS_PATH segm ent) and
skipping to change at line 124 skipping to change at line 88
in the AS_PATH. This is done to simplify the design and implementation in the AS_PATH. This is done to simplify the design and implementation
of BGP and to make the semantics of the originator of a BGP route clearer. of BGP and to make the semantics of the originator of a BGP route clearer.
This will also simplify the design, implementation, and deployment of This will also simplify the design, implementation, and deployment of
various BGP security mechanisms. This document updates RFC 4271 by various BGP security mechanisms. This document updates RFC 4271 by
deprecating the origination of BGP routes with AS_SET (Type 1 AS_PATH segm ent) and deprecating the origination of BGP routes with AS_SET (Type 1 AS_PATH segm ent) and
updates RFC 5065 by deprecating the origination of BGP updates RFC 5065 by deprecating the origination of BGP
routes with AS_CONFED_SET (Type 4 AS_PATH segment). routes with AS_CONFED_SET (Type 4 AS_PATH segment).
Finally, it obsoletes RFC 6472.</t> Finally, it obsoletes RFC 6472.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<name>Introduction</name>
<t>BCP 172 <xref target="RFC6472"></xref> makes a recommendation for not <t><xref target="BCP172"/> recommends not
using AS_SET (see <xref target="RFC4271"></xref>) and AS_CONFED_SET (see using AS_SET <xref target="RFC4271" format="default"/> and AS_CONFED_SET <
<xref target="RFC5065"></xref>) AS_PATH path segment types in the Border xref target="RFC5065" format="default"/> AS_PATH path segment types in the Borde
r
Gateway Protocol (BGP). This document advances the BCP recommendation to Gateway Protocol (BGP). This document advances the BCP recommendation to
a standards requirement in BGP; it prohibits the use of the AS_SET and a standards requirement in BGP; it prohibits the use of the AS_SET and
AS_CONFED_SET types of path segments in the AS_PATH. The purpose is to AS_CONFED_SET types of path segments in the AS_PATH. The purpose is to
simplify the design and implementation of BGP and to make the semantics simplify the design and implementation of BGP and to make the semantics
of the originator of a BGP route clearer. This will also simplify the desi gn, of the originator of a BGP route clearer. This will also simplify the desi gn,
implementation, and deployment of various BGP security mechanisms. In implementation, and deployment of various BGP security mechanisms. In
particular, the prohibition of AS_SETs and AS_CONFED_SETs removes the particular, the prohibition of AS_SETs and AS_CONFED_SETs removes any
possibility of ambiguity about origin AS in RPKI-based route origin ambiguity about the origin AS in RPKI-based Route Origin
validation (RPKI-ROV) Validation (RPKI-ROV)
<xref target="RFC6811"></xref> <xref target="RFC6907"/> <xref target="RFC6811" format="default"/> <xref target="RFC6907" format="d
<xref target="RFC9319"/>.</t> efault"/>
<xref target="RFC9319" format="default"/>.</t>
<t> The AS_SET path segment in the AS_PATH attribute (Sections 4.3 and <t> The AS_SET path segment in the AS_PATH attribute (Sections <xref
5.1.2 of <xref target="RFC4271"></xref>) is created by a router that is target="RFC4271" sectionFormat="bare" section="4.3"/> and <xref
target="RFC4271" sectionFormat="bare" section="5.1.2"/> of <xref
target="RFC4271" format="default"/>) is created by a router that is
performing route aggregation and contains an unordered set of Autonomous performing route aggregation and contains an unordered set of Autonomous
Systems (ASes) that contributing prefixes in the aggregate have Systems (ASes) that contributing prefixes in the aggregate have
traversed.</t> traversed.</t>
<t>The AS_CONFED_SET path segment <xref target="RFC5065" format="default"/
<t>The AS_CONFED_SET path segment (see <xref target="RFC5065"/>) in > in
the AS_PATH attribute is created by a router that is performing route the AS_PATH attribute is created by a router that is performing route
aggregation and contains an unordered set of Member AS Numbers in the aggregation and contains an unordered set of Member AS Numbers in the
local confederation that contributing prefixes in the aggregate have local confederation that contributing prefixes in the aggregate have
traversed. It is very similar to an AS_SET but is used within a traversed. It is very similar to an AS_SET but is used within a
confederation.</t> confederation.</t>
<t>By performing aggregation, a router is combining multiple BGP routes <t>By performing aggregation, a router is combining multiple BGP routes
for more specific destinations into a new route for a less specific for more specific destinations into a new route for a less specific
destination (<xref target="RFC4271"/>, Section 9.1.2.2.). Aggregation destination (see <xref target="RFC4271" sectionFormat="comma" section="9.1 .2.2"/>). Aggregation
may blur the semantics of the origin AS for the prefix being announced by may blur the semantics of the origin AS for the prefix being announced by
producing an AS_SET or AS_CONFED_SET. Such sets can cause operational producing an AS_SET or AS_CONFED_SET. Such sets can cause operational
issues, such as not being able to authenticate a route origin for the issues, such as not being able to authenticate a route origin for the
aggregate prefix in new BGP security technologies such as those that take aggregate prefix in new BGP security technologies such as those that take
advantage of X.509 extensions for IP addresses and AS identifiers advantage of X.509 extensions for IP addresses and AS identifiers
(<xref target="RFC6480"/>, <xref target="RFC6811"/>, <xref target="RFC6907 (see <xref target="RFC6480" format="default"/>, <xref target="RFC6811" for
"/>, mat="default"/>, <xref target="RFC6907" format="default"/>,
<xref target="RFC8205"/>, <xref target="RFC9319"/>). <xref target="RFC8205" format="default"/>, and <xref target="RFC9319" form
at="default"/>).
This could result in reachability problems for the destinations This could result in reachability problems for the destinations
covered by the aggregated prefix.</t> covered by the aggregated prefix.</t>
<t>From analysis of historical Internet routing data, it is apparent that <t>From analysis of historical Internet routing data, it is apparent that
aggregation that involves AS_SETs is very seldom used in practice on the aggregation that involves AS_SETs is very seldom used in practice on the
public Internet (see <xref target="Analysis"/>). When it is used, it public Internet (see <xref target="Analysis" format="default"/>). When it is used, it
is often used incorrectly; only a single AS in the AS_SET is is often used incorrectly; only a single AS in the AS_SET is
the most common case <xref target="Analysis"/>. Also, very often the same AS appears in the the most common case <xref target="Analysis" format="default"/>. Also, ver y often the same AS appears in the
AS_SEQUENCE and the AS_SET in the BGP update. The occurrence of reserved AS_SEQUENCE and the AS_SET in the BGP update. The occurrence of reserved
AS numbers (<xref target="IANA-SP-ASN"/>) is also somewhat frequent.</t> AS numbers <xref target="IANA-SP-ASN" format="default"/> is also somewhat
frequent.</t>
</section> </section>
<section numbered="true" toc="default">
<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&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<section 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>
</section> </section>
<section anchor="recs" numbered="true" toc="default">
<section title="Updates to the Requirements of RFC 4271 and RFC 5065" anchor <name>Updates to the Requirements of RFCs 4271 and 5065</name>
="recs">
<t>Unless explicitly configured by a network operator to do otherwise <t>Unless explicitly configured by a network operator to do otherwise
(e.g., during a transition phase), BGP speakers: (e.g., during a transition phase), BGP speakers:
<ul>
<li>MUST NOT advertise BGP UPDATE messages containing AS_SETs or AS_CO
NFED_SETs, and</li>
<li>Upon reception of BGP UPDATE messages containing AS_SETs or AS_CON
FED_SETs
in the AS_PATH or AS4_PATH <xref target="RFC6793"/>, MUST use the
"treat-as-withdraw" error handling
behavior as per <xref target="RFC7606"/>.</li>
</ul>
</t> </t>
<ul>
<li><bcp14>MUST NOT</bcp14> advertise BGP UPDATE messages containing AS_
SETs or AS_CONFED_SETs and</li>
<t>Per above specifications, this document updates RFC 4271 and RFC 5065 <li><bcp14>MUST</bcp14> use the "treat-as-withdraw" error handling
by deprecating AS_SET (see <xref target="RFC4271" section="4.3" sectionFor behavior per <xref target="RFC7606" format="default"/> upon recept
mat="comma"/>) ion of BGP UPDATE messages containing AS_SETs or AS_CONFED_SETs in the AS_PATH o
and AS_CONFED_SET (see <xref target="RFC5065" section="3" sectionFormat="c r AS4_PATH <xref target="RFC6793" format="default"/>.</li>
omma"/>), respectively.</t> </ul>
<t>Per the above specifications, this document updates <xref target="RFC42
71"/> and <xref target="RFC5065"/>
by deprecating AS_SET (see <xref target="RFC4271" section="4.3" sectionFor
mat="comma" format="default"/>)
and AS_CONFED_SET (see <xref target="RFC5065" section="3" sectionFormat="c
omma" format="default"/>), respectively.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Treatment of Routes with AS_SET in RPKI-based BGP Security"> <name>Treatment of Routes with AS_SET in RPKI-Based BGP Security</name>
<t>Resource Public Key Infrastructure (RPKI) <xref target="RFC6480"/> uses <t>Resource Public Key Infrastructure (RPKI) <xref target="RFC6480" format
X.509 ="default"/> uses X.509
extensions for IP addresses and AS identifiers <xref target="RFC3779"/>. extensions for IP addresses and AS identifiers <xref target="RFC3779" form
RPKI-based Route Origin Validation (ROV) <xref target="RFC6811"/> <xref ta at="default"/>.
rget="RFC6907"/> RPKI-ROV <xref target="RFC6811" format="default"/> <xref target="RFC6907"
format="default"/>
is a BGP security technology that never allows a route with AS_SET to be c onsidered Valid. is a BGP security technology that never allows a route with AS_SET to be c onsidered Valid.
BGPsec <xref target="RFC8205"/> and Autonomous System Provider Authorizati BGPsec <xref target="RFC8205" format="default"/> and Autonomous System Pro
on (ASPA) vider Authorization (ASPA)
<xref target="I-D.ietf-sidrops-aspa-verification"/> are also BGP security <xref target="I-D.ietf-sidrops-aspa-verification" format="default"/> are a
technologies lso BGP security technologies
based on RPKI. BGPsec does not support AS_SETs. In ASPA-based AS_PATH veri fication, based on RPKI. BGPsec does not support AS_SETs. In ASPA-based AS_PATH veri fication,
a route with AS_SET is always considered Invalid and hence ineligible for route selection.</t> a route with AS_SET is always considered Invalid and hence ineligible for route selection.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="BGP AS_PATH &quot;Brief&quot; Aggregation"> <name>BGP AS_PATH "Brief" Aggregation</name>
<t> <t>Sections <xref target="RFC4271" sectionFormat="bare"
Sections 9.1.4 and 9.2.2.2 of <xref target="RFC4271"/> describe BGP aggreg section="9.1.4"/> and <xref target="RFC4271" sectionFormat="bare"
ation procedures. section="9.2.2.2"/> of <xref target="RFC4271" format="default"/>
Appendix F.6 in <xref target="RFC4271"/> describe BGP aggregation procedures. <xref section="F.6"
describes a generally less utilized "Complex AS_PATH Aggregation" target="RFC4271" format="default"/> describes a generally less utilized
procedure.</t> "Complex AS_PATH Aggregation" procedure.</t>
<t><xref target="RFC4271" section="5.1.6" sectionFormat="comma" format="de
<t><xref target="RFC4271" section="5.1.6" sectionFormat="comma"/>, fault"/>
describing the ATOMIC_AGGREGATE Path Attribute, notes that:</t> describes the ATOMIC_AGGREGATE Path Attribute and notes that:</t>
<blockquote>
<blockquote> <t>When a BGP speaker aggregates several routes for the purpose of
<t>When a BGP speaker aggregates several routes for the purpose of
advertisement to a particular peer, the AS_PATH of the aggregated advertisement to a particular peer, the AS_PATH of the aggregated
route normally includes an AS_SET formed from the set of ASes from route normally includes an AS_SET formed from the set of ASes from
which the aggregate was formed. In many cases, the network which the aggregate was formed. In many cases, the network
administrator can determine if the aggregate can safely be advertised administrator can determine if the aggregate can safely be advertised
without the AS_SET, and without forming route loops.</t> without the AS_SET, and without forming route loops.</t>
<t>If an aggregate excludes at least some of the AS numbers present in
<t>If an aggregate excludes at least some of the AS numbers present in
the AS_PATH of the routes that are aggregated as a result of dropping the AS_PATH of the routes that are aggregated as a result of dropping
the AS_SET, the aggregated route, when advertised to the peer, SHOULD the AS_SET, the aggregated route, when advertised to the peer, <bcp14> SHOULD</bcp14>
include the ATOMIC_AGGREGATE attribute.</t> include the ATOMIC_AGGREGATE attribute.</t>
</blockquote> </blockquote>
<t>When BGP AS_PATH aggregation is done according to the procedures in <xr
<t>When BGP AS_PATH aggregation is done according to the <xref target="R ef target="RFC4271" section="9.2.2.2" sectionFormat="comma" format="default"/>,
FC4271" section="9.2.2.2" sectionFormat="comma"/> and any resulting AS_SETs are discarded, it is typically
procedures, and any resulting AS_SETs are discarded, this is typically referred to as "brief" aggregation in implementations. That terminology
referred to as "brief" aggregation in implementations. is adopted here: In this document, brief aggregation refers to what is described
Brief aggregation results in an AS_PATH that has the property in this section, in contrast to consistent brief aggregation as described in <x
(from <xref target="RFC4271" section="9.2.2.2" sectionFormat="comma"/>): ref target="consistent-brief"/>.
</t> Brief aggregation results in an AS_PATH that has the following property
(from
<blockquote> <xref target="RFC4271" section="9.2.2.2" sectionFormat="comma" format="d
<t>determine the longest leading sequence of tuples (as defined above) efault"/>):</t>
<blockquote>
<t>[D]etermine the longest leading sequence of tuples (as defined above)
common to all the AS_PATH attributes of the routes to be aggregated. common to all the AS_PATH attributes of the routes to be aggregated.
Make this sequence the leading sequence of the aggregated AS_PATH Make this sequence the leading sequence of the aggregated AS_PATH
attribute.</t> attribute.</t>
</blockquote> </blockquote>
<t>The ATOMIC_AGGREGATE Path Attribute is subsequently attached to the
<t>The ATOMIC_AGGREGATE Path Attribute is subsequently attached to the
BGP route, if AS_SETs are dropped.</t> BGP route, if AS_SETs are dropped.</t>
<section numbered="true" toc="default">
<section title="Issues with &quot;Brief&quot; AS_PATH Aggregation and RPKI <name>Issues with "Brief" AS_PATH Aggregation and RPKI-ROV</name>
-ROV">
<t>While brief AS_PATH aggregation has the desirable property of not <t>While brief AS_PATH aggregation has the desirable property of not
containing AS_SETs, the resulting aggregated AS_PATH may contain an containing AS_SETs, the resulting aggregated AS_PATH may contain an
unpredictable origin AS. unpredictable origin AS.
This is because the aggregating AS may be different from the purported o rigin AS (for the aggregate), which may vary as explained below. This is because the aggregating AS may be different from the purported o rigin AS (for the aggregate), which may vary as explained below.
Such an unpredictable origin ASes may result Such unpredictable origin ASes may result
in RPKI-ROV validation issues:</t> in RPKI-ROV validation issues:</t>
<ul> <ul>
<li>Depending on the contributing routes to the aggregate route, the <li>Depending on the contributing routes to the aggregate route, the
resulting origin AS may vary.</li> resulting origin AS may vary.</li>
<li>The presence of expected contributing routes may be unpredictable <li>The presence of expected contributing routes may be unpredictable
due to route availability from BGP neighbors.</li> due to route availability from BGP neighbors.</li>
<li>In the presence of such varying origin ASes, it would be necessary <li>In the presence of such varying origin ASes, it would be necessary
for the resource holder to register Route for the resource holder to register ROAs <xref target="RFC9582" format
Origin Authorizations (ROAs) <xref target="RFC9582"></xref> for each p ="default"/> for each potential origin AS that
otential origin AS that
may result from the expected aggregated AS_PATHs.</li> may result from the expected aggregated AS_PATHs.</li>
</ul> </ul>
</section> </section>
<section anchor="consistent-brief" numbered="true" toc="default">
<section title="Recommendations to Mitigate Unpredictable AS_PATH Origins <name>Recommendations to Mitigate Unpredictable AS_PATH Origins for RPKI
for RPKI-ROV Purposes" anchor="consistent-brief"> -ROV Purposes</name>
<t>To ensure a consistent BGP origin AS is announced for <t>To ensure a consistent BGP origin AS is announced for
aggregate BGP routes for implementations of "brief" BGP aggregation, the aggregate BGP routes for implementations of "brief" BGP aggregation, the
implementation MUST be configured to truncate the AS_PATH after the implementation <bcp14>MUST</bcp14> be configured to truncate the AS_PATH after the
right-most instance of the desired origin AS for the aggregate. right-most instance of the desired origin AS for the aggregate.
The desired origin AS could be the aggregating AS itself. The desired origin AS could be the aggregating AS itself.
A ROA would be necessary for the aggregate prefix with the desired origi n AS.</t> A ROA would be necessary for the aggregate prefix with the desired origi n AS.</t>
<t>This form of brief aggregation is referred to as "consistent <t>This form of brief aggregation is referred to as "consistent
brief" BGP aggregation.</t> brief" BGP aggregation.</t>
<t>If the resulting AS_PATH would be truncated from the otherwise <t>If the resulting AS_PATH would be truncated from the otherwise
expected result of BGP AS_PATH aggregation (an AS_SET would not be expected result of BGP AS_PATH aggregation (an AS_SET would not be
generated and possibly some ASes are removed from the "longest leading s equence" of generated and possibly some ASes are removed from the "longest leading s equence" of
ASes), the ATOMIC_AGGREGATE Path Attribute SHOULD be attached. This is ASes), the ATOMIC_AGGREGATE Path Attribute <bcp14>SHOULD</bcp14> be atta
consistent with the intent of <xref target="RFC4271" section="5.1.6" sec ched. This is
tionFormat="comma"/>.</t> consistent with the intent of <xref target="RFC4271" section="5.1.6" sec
tionFormat="comma" format="default"/>.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Operational Considerations"> <name>Operational Considerations</name>
<t>This section provides advice to operators regarding deployment and config <t>This section provides advice to operators regarding deployment and conf
uration.</t> iguration.</t>
<section title="Implementing Consistent Brief Aggregation"> <section numbered="true" toc="default">
<t>When aggregating prefixes, network operators MUST use <name>Implementing Consistent Brief Aggregation</name>
<t>When aggregating prefixes, network operators <bcp14>MUST</bcp14> use
consistent brief aggregation as described in consistent brief aggregation as described in
<xref target="consistent-brief"/>. <xref target="consistent-brief" format="default"/>.
In consistent brief aggregation, the AGGREGATOR and ATOMIC_AGGREGATE In consistent brief aggregation, the AGGREGATOR and ATOMIC_AGGREGATE
Path Attributes are included, but the AS_PATH does not have AS_SET or Path Attributes are included, but the AS_PATH does not have AS_SET or
AS_CONFED_SET path segment types. AS_CONFED_SET path segment types.
See <xref target="brief-agg-example"/> for examples of See <xref target="brief-agg-example" format="default"/> for examples of
brief aggregation while keeping the origin AS unambiguous brief aggregation while keeping the origin AS unambiguous
and generating appropriate ROAs.</t> and generating appropriate ROAs.</t>
</section> </section>
<section anchor="filtering-to-contributors" numbered="true" toc="default">
<section title="Not Advertising Aggregate Routes to Contributing ASes" <name>Not Advertising Aggregate Routes to Contributing ASes</name>
anchor="filtering-to-contributors">
<t>An aggregate prefix <t>An aggregate prefix
SHOULD NOT be announced to the contributing ASes. Instead, more specific <bcp14>SHOULD NOT</bcp14> be announced to the contributing ASes. Instead
prefixes (from the aggregate) SHOULD be announced to each contributing A , more specific
S, prefixes (from the aggregate) <bcp14>SHOULD</bcp14> be announced to each
contributing AS,
excluding any that were learned from the contributing AS in excluding any that were learned from the contributing AS in
consideration. See <xref target="filter-example"/> for an example of consideration. See <xref target="filter-example" format="default"/> for an example of
this filtering policy.</t> this filtering policy.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Mitigating Forwarding Loops"> <name>Mitigating Forwarding Loops</name>
<t>As discussed in <xref target="RFC4632" section="5.1"/>, <t>When both less specific and more specific destinations are present,
the presence of both less specific and more specific destinations has it's possible to create forwarding loops between networks, as discussed
the possibility to create forwarding loops between networks.</t> in <xref target="RFC4632" section="5.1" format="default"/>.</t>
<t>As a reminder, Rule #2 in <xref target="RFC4632" section="5.1" format
<t>As a reminder, Rule #2 of <xref target="RFC4632" section="5.1"/> ="default"/>
requires that BGP implementations performing aggregation discard requires that BGP implementations performing aggregation discard
packets that match the aggregate route but do not match any of the packets that match the aggregate route but do not match any of the
more-specific routes. more specific routes.
</t> </t>
<t>Further discussion of forwarding loops and their relationship to <t>Further discussion of forwarding loops and their relationship to
AS_SETs can be found in <xref target="forwarding-loop-discussion"/>.</t> AS_SETs can be found in <xref target="forwarding-loop-discussion" format ="default"/>.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Security Considerations"> <name>Security Considerations</name>
<t>This document deprecates the use of aggregation techniques that create <t>This document deprecates the use of aggregation techniques that create
AS_SETs or AS_CONFED_SETs. Obsoleting these path segment types from BGP AS_SETs or AS_CONFED_SETs. Obsoleting these path segment types from BGP
and removal of the related code from implementations would potentially and the removal of the related code from implementations would potentially
decrease the attack surface for BGP. Deployments of new BGP security decrease the attack surface for BGP. Deployments of new BGP security
technologies technologies
(e.g., <xref target="RFC6480"/>, <xref target="RFC6811"/>, (e.g., <xref target="RFC6480" format="default"/>, <xref target="RFC6811" f
<xref target="RFC8205"/>) benefit greatly if AS_SETs and AS_CONFED_SETs ar ormat="default"/>, and
e not used in BGP.</t> <xref target="RFC8205" format="default"/>) benefit greatly if AS_SETs and
</section> AS_CONFED_SETs are not used in BGP.</t>
<section title="IANA Considerations">
<t>This document requires no IANA actions.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Acknowledgements"> <name>IANA Considerations</name>
<t>The authors would like to thank Alvaro Retana, John Scudder, Ketan Tala <t>This document has no IANA actions.</t>
ulikar,
Keyur Patel, Susan Hares, Claudio Jeker, Nick Hilliard, Robert Raszuk,
John Heasley, Job Snijders, Jared Mauch, Jakob Heitz, Tony Przygienda,
Douglas Montgomery, Randy Bush, Curtis Villamizar, Danny McPherson, Chris
Morrow,
Tom Petch, Ilya Varlashkin, Enke Chen, Tony Li, Florian Weimer, John
Leslie, Paul Jakma, Rob Austein, Russ Housley, Sandra Murphy, Steve
Bellovin, Steve Kent, Steve Padgett, and Alfred Hoenes for
comments and suggestions. The comments and suggestions received from the I
ESG reviewers are also much appreciated.
</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References">
&rfc2119;
&rfc4271;
&rfc4632;
&rfc5065;
&rfc6472;
&rfc6793;
&rfc7606;
&rfc8174;
</references>
<references title="Informative References">
&rfc3779;
&rfc6811;
&rfc6480;
&rfc9582;
&rfc6907;
&rfc8205;
&rfc9319;
&I-D.ietf-sidrops-aspa-verification;
<reference anchor="IANA-SP-ASN" <displayreference target="I-D.ietf-sidrops-aspa-verification" to="ASPA-VERI
target="https://www.iana.org/assignments/iana-as-numbers-special-registry FICATION"/>
/iana-as-numbers-special-registry.xhtml"> <references>
<front> <name>References</name>
<title>Special-Purpose Autonomous System (AS) Numbers</title> <references>
<author initials="" surname=""> <name>Normative References</name>
<organization /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
</author> 119.xml"/>
<date month="" year="" /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
</front> 271.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
632.xml"/>
<reference anchor="Analysis" <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
target="https://github.com/ksriram25/IETF/blob/main/Detailed-AS 065.xml"/>
_SET-analysis.txt">
<front>
<title>Detailed analysis of AS_SETs in BGP updates</title>
<author initials="L." surname="Hannachi">
<organization />
</author>
<author initials="K." surname="Sriram"> <referencegroup anchor="BCP172" target="https://www.rfc-editor.org/info/bcp
<organization /> 172">
</author> <reference anchor="RFC6472" target="https://www.rfc-editor.org/info/rf
c6472">
<front>
<title>Recommendation for Not Using AS_SET and AS_CONFED_SET in BG
P</title>
<author fullname="W. Kumari" initials="W." surname="Kumari"/>
<author fullname="K. Sriram" initials="K." surname="Sriram"/>
<date month="December" year="2011"/>
</front>
<seriesInfo name="BCP" value="172"/>
<seriesInfo name="RFC" value="6472"/>
<seriesInfo name="DOI" value="10.17487/RFC6472"/>
</reference>
</referencegroup>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
793.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
606.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
779.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
811.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
480.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
582.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
907.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
205.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
319.xml"/>
<date month="October" year="2019" /> <!-- [I-D.ietf-sidrops-aspa-verification] draft-ietf-sidrops-aspa-verification-2
</front> 2
IESG State: I-D Exists as of 04/21/25
--> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D
.ietf-sidrops-aspa-verification.xml"/>
<seriesInfo name="NIST Robust Inter-domain Routing Project Website" valu <reference anchor="IANA-SP-ASN" target="https://www.iana.org/assignments
e="" /> /iana-as-numbers-special-registry">
</reference> <front>
<title>Special-Purpose Autonomous System (AS) Numbers</title>
<author initials="" surname="">
<organization>IANA</organization>
</author>
<date month="" year=""/>
</front>
</reference>
<reference anchor="Analysis" target="https://github.com/ksriram25/IETF/b
lob/main/Detailed-AS_SET-analysis.txt">
<front>
<title>Detailed analysis of AS_SETs in BGP updates</title>
<author>
<organization/>
</author>
<date month="March" year="2022"/>
</front>
<refcontent>commit ef3f4a9</refcontent>
</reference>
</references>
</references> </references>
<section title="Example of Route Filtering for Aggregate Routes and their Co <section anchor="filter-example" numbered="true" toc="default">
ntributors" <name>Example of Route Filtering for Aggregate Routes and Their Contributo
anchor="filter-example"> rs</name>
<t>
<t> The illustration presented below shows how an AS_SET is not used when
Presented here is an illustration of how an AS_SET is not used when aggregating and how data plane route loops are avoided.
aggregating and still data-plane route loops are avoided.
Consider that p1/24 (from AS 64501), p2/24 (from AS 64502), p3/24 (from A S 64503), Consider that p1/24 (from AS 64501), p2/24 (from AS 64502), p3/24 (from A S 64503),
and p4/24 (from AS 64504) are aggregated by AS 64505 to p/22. and p4/24 (from AS 64504) are aggregated by AS 64505 to p/22.
AS_SET is not used with the aggregate p/22 but AGGREGATOR and ATOMIC AGGR EGATE are used. AS_SET is not used with the aggregate p/22 but AGGREGATOR and ATOMIC AGGR EGATE are used.
Data-plane route loops are avoided by not announcing the aggregate p/22 Data plane route loops are avoided by not announcing the aggregate p/22
to the contributing ASes, i.e., AS 64501, AS 64502, AS 64503, and AS 6450 4. to the contributing ASes, i.e., AS 64501, AS 64502, AS 64503, and AS 6450 4.
Instead, as further illustration, p1/24, p2/24, and p4/24 are announced t o AS 64503. Instead, as further illustrated, p1/24, p2/24, and p4/24 are announced to AS 64503.
The routing tables (post aggregation) of each of the ASes are depicted in the diagram below. The routing tables (post aggregation) of each of the ASes are depicted in the diagram below.
</t> </t>
<artset>
<artwork type="ascii-art" align="center">
<![CDATA[
<artwork type="ascii-art" align="center" name="" alt=""><![CDATA[
( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
( AS64501 ) ( AS64502 ) ( AS64503 ) ( AS64504 ) ( AS64501 ) ( AS64502 ) ( AS64503 ) ( AS64504 )
( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
p1/24 p2/24 p3/24 p4/24 p1/24 p2/24 p3/24 p4/24
| | | | | | | |
| +--> ( ) <--+ | | +--> ( ) <--+ |
| ( AS64505 ) | | ( AS64505 ) |
+----------------> ( ) <----------------+ +----------------> ( ) <----------------+
p/22 p/22
| |
skipping to change at line 467 skipping to change at line 407
p2/24 AS_PATH "64505 64502" p2/24 AS_PATH "64505 64502" p2/24 AS_PATH "64505 64502" p2/24 AS_PATH "64505 64502"
p3/24 AS_PATH "" p3/24 AS_PATH "64505 64503" p3/24 AS_PATH "" p3/24 AS_PATH "64505 64503"
p4/24 AS_PATH "64505 64504" p4/24 AS_PATH "" p4/24 AS_PATH "64505 64504" p4/24 AS_PATH ""
AS 64505 AS 64505
========================== ==========================
p/22 AS_PATH "" AGGREGATOR 64505 ATOMIC_AGGREGATE p/22 AS_PATH "" AGGREGATOR 64505 ATOMIC_AGGREGATE
p1/24 AS_PATH "64501" p1/24 AS_PATH "64501"
p2/24 AS_PATH "64502" p2/24 AS_PATH "64502"
p3/24 AS_PATH "64503" p3/24 AS_PATH "64503"
p4/24 AS_PATH "64504" p4/24 AS_PATH "64504"]]></artwork>
]]>
</artwork>
</artset>
</section> </section>
<section title="Examples of Consistent and Inconsistent BGP Origin-AS Genera <section anchor="brief-agg-example" numbered="true" toc="default">
ted by <name>Examples of Consistent and Inconsistent BGP Origin AS Generated by B
Traditional Brief Aggregation" anchor="brief-agg-example"> rief Aggregation</name>
<t> <t>
In the examples below, it is illustrated how traditional brief aggregation The examples below illustrate how brief aggregation
may result in an inconsistent origin AS. may result in an inconsistent origin AS.
</t> </t>
<t>AS 64500 aggregates more specific routes into 192.0.2.0/24.</t> <t>AS 64500 aggregates more specific routes into 192.0.2.0/24.</t>
<t>Consider the following scenarios where brief aggregation is done <t>Consider the following scenarios where brief aggregation is done
by AS 64500 and what the resultant origin ASes would be.</t> by AS 64500 and what the resultant origin ASes would be.</t>
<artset> <artwork type="ascii-art" align="left" name="" alt=""><![CDATA[
<artwork type="ascii-art" align="left">
<![CDATA[
Routes: Routes:
R1 - 192.0.2.0/26 AS_PATH "64501" R1 - 192.0.2.0/26 AS_PATH "64501"
R2 - 192.0.2.64/26 AS_PATH "64502" R2 - 192.0.2.64/26 AS_PATH "64502"
R3 - 192.0.2.128/26 AS_PATH "64504 64502" R3 - 192.0.2.128/26 AS_PATH "64504 64502"
R4 - 192.0.2.192/26 AS_PATH "64504 64501" R4 - 192.0.2.192/26 AS_PATH "64504 64501"
( ) ( ) ( ) ( )
( AS64501 ) ( AS64502 ) ( AS64501 ) ( AS64502 )
( ) ( ) ( ) ( )
192.0.2.0/26 192.0.2.192/26 192.0.2.128/26 192.0.2.64/26 192.0.2.0/26 192.0.2.192/26 192.0.2.128/26 192.0.2.64/26
skipping to change at line 513 skipping to change at line 447
| | | | | | | |
| R4 | | R3 | | R4 | | R3 |
| | | | | | | |
| \/ \/ | | \/ \/ |
| R1 ( ) R2 | | R1 ( ) R2 |
+------------------->( AS64500 )<-------------+ +------------------->( AS64500 )<-------------+
( ) ( )
| |
| (announcing | (announcing
| aggregate 192.0.2.0/24) | aggregate 192.0.2.0/24)
\/ \/]]></artwork>
]]>
</artwork>
</artset>
<section title="Scenario 1: First one route, then another, each with a <section numbered="true" toc="default">
fully disjoint AS_PATH"> <name>Scenario 1: First one route, then another, each with a fully disjoi
nt AS_PATH</name>
<t>Receive R1. Aggregate 192.0.2.0/24 AS_PATH "64501"</t> <t>Receive R1. Aggregate 192.0.2.0/24 AS_PATH "64501"</t>
<t>Alternate "bug?": Aggregate 192.0.2.0/24 AS_PATH "[ 64501 ]"</t> <t>Alternate "bug?": Aggregate 192.0.2.0/24 AS_PATH "[ 64501 ]"</t>
<t>(Note: AS numbers within square brackets represent an AS_SET.)</t> <t>(Note: AS numbers within square brackets represent an AS_SET.)</t>
<t>Receive R2. Aggregate 192.0.2.0/24 AS_PATH "[ 64501 64502 ]"</t> <t>Receive R2. Aggregate 192.0.2.0/24 AS_PATH "[ 64501 64502 ]"</t>
<t>If brief aggregation is in use, the AS_PATH would be truncated to <t>If brief aggregation is in use, the AS_PATH would be truncated to
the empty AS_PATH, "".</t> the empty AS_PATH, "".</t>
<t>The resulting AS_PATH is thus not stable and depends on the presence <t>The resulting AS_PATH is thus not stable and depends on the presence
of specific routes.</t> of specific routes.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Scenario 2: First one route, then another, the AS_PATHs <name>Scenario 2: First one route, then another, and the AS_PATHs overla
overlap at the origin AS."> p at the origin AS</name>
<t>Receive R1. Aggregate 192.0.2.0/24 AS_PATH "64501"</t> <t>Receive R1. Aggregate 192.0.2.0/24 AS_PATH "64501"</t>
<t>Receive R4. Aggregate 192.0.2.0/24 AS_PATH "[ 64504 64501 ]"</t> <t>Receive R4. Aggregate 192.0.2.0/24 AS_PATH "[ 64504 64501 ]"</t>
<t>If brief aggregation is in use, the AS_PATH is truncated to "".</t> <t>If brief aggregation is in use, the AS_PATH is truncated to "".</t>
<t>The resulting AS_PATH is thus not stable and depends on the presence <t>The resulting AS_PATH is thus not stable and depends on the presence
of specific routes.</t> of specific routes.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Scenario 3: First one route, then another, the AS_PATHs <name>Scenario 3: First one route, then another, and the AS_PATHs overla
overlap at the neighbor AS"> p at the neighbor AS</name>
<t>Receive R3. Aggregate 192.0.2.0/24 AS_PATH "64504 64501".</t> <t>Receive R3. Aggregate 192.0.2.0/24 AS_PATH "64504 64501"</t>
<t>Receive R4. Aggregate 192.0.2.0/24 AS_PATH "64504 [ 64501 64502 ]"</ t> <t>Receive R4. Aggregate 192.0.2.0/24 AS_PATH "64504 [ 64501 64502 ]"</ t>
<t>If brief aggregation is in use, the AS_PATH is truncated to "64504".< /t> <t>If brief aggregation is in use, the AS_PATH is truncated to "64504".< /t>
<t>The resulting AS_PATH is thus not stable and depends on the presence <t>The resulting AS_PATH is thus not stable and depends on the presence
of specific routes.</t> of specific routes.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Achieving Consistent Origin-AS During Aggregation"> <name>Achieving Consistent Origin AS During Aggregation</name>
<t>In the three scenarios above, the aggregating AS 64500 is using <t>In the three scenarios above, the aggregating AS 64500 is using
traditional brief aggregation. This results in inconsistent brief aggregation. This results in inconsistent
origin ASes as the contributing routes are learned. This motivates the origin ASes as the contributing routes are learned. This motivates the
"consistent brief" BGP aggregation mentioned in "consistent brief" BGP aggregation mentioned in
<xref target="consistent-brief"/> and discussed further <xref target="consistent-brief" format="default"/> and discussed further
with examples below.</t> with examples below.</t>
<t>The trivial solution to addressing the issue is to simply discard <t>The trivial solution to addressing the issue is to simply discard
all of the ASes for the contributing routes. In simple BGP aggregation all of the ASes for the contributing routes. In simple BGP aggregation
topologies, this is likely the correct thing to do. The AS originating topologies, this is likely the correct thing to do. The AS originating
the aggregate, 192.0.2.0/24 in this example, is likely the resource the aggregate, 192.0.2.0/24 in this example, is likely the resource
holder for the route in question. In such a case, simply originating holder for the route in question. In such a case, simply originating
the route to its BGP upstream neighbors in the Internet with its own the route to its BGP upstream neighbors in the Internet with its own
AS, 64500, means that a consistent Route Origin Authorization (ROA) AS, 64500, means that a consistent ROA
could be registered in the RPKI for this prefix. This satisfies the could be registered in the RPKI for this prefix. This satisfies the
need for a consistent (unambiguous) origin AS.</t> need for a consistent (unambiguous) origin AS.</t>
<t>If the contributing ASes are themselves multihomed to the Internet <t>If the contributing ASes are themselves multihomed to the Internet
outside of their connections to AS 64500, then additional ROAs would outside of their connections to AS 64500, then additional ROAs would
need to be created for each of the more specific prefixes.</t> need to be created for each of the more specific prefixes.</t>
<t>In more complex proxy aggregation scenarios, there may be a desire <t>In more complex proxy aggregation scenarios, there may be a desire
to permit some stable (i.e., common) portion of the contributing AS_PATH s to be kept in the to permit some stable (i.e., common) portion of the contributing AS_PATH s to be kept in the
aggregate route. Consider the case for Scenario 3, where the neighbor aggregate route. Consider the case for Scenario 3, where the neighbor
AS is the same for both R3 and R4 - AS 64504. In such a case, an AS is the same for both R3 and R4 -- AS 64504. In such a case, an
implementation may permit the aggregate's brief AS_PATH to be "64504", a nd implementation may permit the aggregate's brief AS_PATH to be "64504", a nd
a ROA would be created for the aggregate prefix with 64504 as the origin AS. a ROA would be created for the aggregate prefix with 64504 as the origin AS.
</t> </t>
</section> </section>
</section> </section>
<section anchor="forwarding-loop-discussion" numbered="true" toc="default">
<section title="Discussion on Forwarding Loops and AS_SETs" <name>Discussion on Forwarding Loops and AS_SETs</name>
anchor="forwarding-loop-discussion"> <t>Although BGP-4 was designed to carry Classless Inter-Domain Routing (CI
<t>Although BGP-4 was designed to carry CIDR routes, DR) routes,
<xref target="RFC4271"/> does not discuss the installation of "discard" <xref target="RFC4271" format="default"/> does not discuss the installatio
n of "discard"
or "null" routes when implementing its aggregation procedures. Implementa tions or "null" routes when implementing its aggregation procedures. Implementa tions
could originate an aggregate prefix without a covering route could originate an aggregate prefix without a covering route
for a more-specific prefix (subsumed by the aggregate prefix) present in t he local for a more specific prefix (subsumed by the aggregate prefix) present in t he local
routing table.</t> routing table.</t>
<t>When aggregating more specific routes according to <t>When aggregating more specific routes according to
<xref target="RFC4271"/> aggregation procedures, the aggregating BGP the aggregation procedures of <xref target="RFC4271" format="default"/>, t he aggregating BGP
speaker will place contributing routes into the generated AS_PATH, perhaps speaker will place contributing routes into the generated AS_PATH, perhaps
using AS_SETs. As a result, a contributing AS will not install the using AS_SETs. As a result, a contributing AS will not install the
aggregated route into its RIB since the route is an AS_PATH loop. This aggregated route into its RIB since the route is an AS_PATH loop. This
provides a form of protection against forwarding loops created by BGP provides a form of protection against forwarding loops created by BGP
aggregation.</t> aggregation.</t>
<t>When brief aggregation methods are used, a BGP speaker may receive a <t>When brief aggregation methods are used, a BGP speaker may receive a
route containing such less specific destination covering a local more route containing a less specific destination covering a local more specifi
specific destination and install it in its routing table since it is not c
destination and install it in its routing table since it is not
prevented from doing so by BGP AS_PATH loop detection. This gives rise to prevented from doing so by BGP AS_PATH loop detection. This gives rise to
the possibility of forwarding loops. To help prevent forwarding loops, the possibility of forwarding loops. To help prevent forwarding loops,
it is critical to adhere to the following:</t> it is critical to adhere to the following:</t>
<ol> <ol>
<li>Rule #2 of <xref target="RFC4632" section="5.1"/>: <li>Rule #2 in <xref target="RFC4632" section="5.1" format="default"/>
"A router that generates an aggregate route for multiple, : </li>
</ol>
<blockquote>
A router that generates an aggregate route for multiple,
more-specific routes must discard packets that match the more-specific routes must discard packets that match the
aggregate route, but not any of the more-specific routes. In other aggregate route, but not any of the more-specific routes. In other
words, the "next hop" for the aggregate route should be the null words, the "next hop" for the aggregate route should be the null
destination."</li> destination.</blockquote>
<li> Not advertising aggregate routes to contributing ASes <ol start="2">
as specified in <xref target="filtering-to-contributors"/> <li>Not advertising aggregate routes to contributing ASes
of this document (also see <xref target="filter-example"/>).</li> as specified in <xref target="filtering-to-contributors" format="defau
</ol> lt"/>
of this document (also see <xref target="filter-example" format="defau
lt"/>).</li>
</ol>
</section>
<section numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Alvaro Retana"/>,
<contact fullname="John Scudder"/>, <contact fullname="Ketan
Talaulikar"/>, <contact fullname="Keyur Patel"/>, <contact
fullname="Susan Hares"/>, <contact fullname="Claudio Jeker"/>, <contact
fullname="Nick Hilliard"/>, <contact fullname="Robert Raszuk"/>,
<contact fullname="John Heasley"/>, <contact fullname="Job Snijders"/>,
<contact fullname="Jared Mauch"/>, <contact fullname="Jakob Heitz"/>,
<contact fullname="Tony Przygienda"/>, <contact fullname="Douglas
Montgomery"/>, <contact fullname="Randy Bush"/>, <contact
fullname="Curtis Villamizar"/>, <contact fullname="Danny McPherson"/>,
<contact fullname="Chris Morrow"/>, <contact fullname="Tom Petch"/>,
<contact fullname="Ilya Varlashkin"/>, <contact fullname="Enke Chen"/>,
<contact fullname="Tony Li"/>, <contact fullname="Florian Weimer"/>,
<contact fullname="John Leslie"/>, <contact fullname="Paul Jakma"/>,
<contact fullname="Rob Austein"/>, <contact fullname="Russ Housley"/>,
<contact fullname="Sandra Murphy"/>, <contact fullname="Steven M.
Bellovin"/>, <contact fullname="Steve Kent"/>, <contact fullname="Steve
Padgett"/>, and <contact fullname="Alfred Hoenes"/> for comments and
suggestions. The comments and suggestions received from the IESG
reviewers are also much appreciated.
</t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 114 change blocks. 
358 lines changed or deleted 329 lines changed or added

This html diff was produced by rfcdiff 1.48.