Deprecation of AS_SET and AS_CONFED_SET in BGPGoogle, Inc.1600 Amphitheatre ParkwayMountain ViewCA94043United States of America+1 571 748 4373warren@kumari.netUSA NIST100 Bureau DriveGaithersburgMD20899United States of America+1 301 975 3973ksriram@nist.govUSA NIST100 Bureau DriveGaithersburgMD20899United States of America+1 301 975 3259lilia.hannachi@nist.govJuniper Networks, Inc.1133 Innovation WaySunnyvaleCA94089United States of Americajhaas@juniper.net
RTG
idrBCP 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
advances that recommendation to a standards requirement in BGP; it
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
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
various BGP security mechanisms. This document updates RFC 4271 by
deprecating the origination of BGP routes with AS_SET (Type 1 AS_PATH segment) and
updates RFC 5065 by deprecating the origination of BGP
routes with AS_CONFED_SET (Type 4 AS_PATH segment).
Finally, it obsoletes RFC 6472.Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
. Introduction
. Requirements Language
. Updates to the Requirements of RFCs 4271 and 5065
. Treatment of Routes with AS_SET in RPKI-Based BGP Security
. BGP AS_PATH "Brief" Aggregation
. Issues with "Brief" AS_PATH Aggregation and RPKI-ROV
. Recommendations to Mitigate Unpredictable AS_PATH Origins for RPKI-ROV Purposes
. Operational Considerations
. Implementing Consistent Brief Aggregation
. Not Advertising Aggregate Routes to Contributing ASes
. Mitigating Forwarding Loops
. Security Considerations
. IANA Considerations
. References
. Normative References
. Informative References
. Example of Route Filtering for Aggregate Routes and Their Contributors
. Examples of Consistent and Inconsistent BGP Origin AS Generated by Brief Aggregation
. Scenario 1: First one route, then another, each with a fully disjoint AS_PATH
. Scenario 2: First one route, then another, and the AS_PATHs overlap at the origin AS
. Scenario 3: First one route, then another, and the AS_PATHs overlap at the neighbor AS
. Achieving Consistent Origin AS During Aggregation
. Discussion on Forwarding Loops and AS_SETs
Acknowledgements
Authors' Addresses
Introduction recommends not
using AS_SET and AS_CONFED_SET AS_PATH path segment types in the Border
Gateway Protocol (BGP). This document advances the BCP recommendation to
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
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 design,
implementation, and deployment of various BGP security mechanisms. In
particular, the prohibition of AS_SETs and AS_CONFED_SETs removes any
ambiguity about the origin AS in RPKI-based Route Origin
Validation (RPKI-ROV)
. The AS_SET path segment in the AS_PATH attribute (Sections and of ) is created by a router that is
performing route aggregation and contains an unordered set of Autonomous
Systems (ASes) that contributing prefixes in the aggregate have
traversed.The AS_CONFED_SET path segment in
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
local confederation that contributing prefixes in the aggregate have
traversed. It is very similar to an AS_SET but is used within a
confederation.By performing aggregation, a router is combining multiple BGP routes
for more specific destinations into a new route for a less specific
destination (see ). Aggregation
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
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
advantage of X.509 extensions for IP addresses and AS identifiers
(see , , ,
, and ).
This could result in reachability problems for the destinations
covered by the aggregated prefix.From analysis of historical Internet routing data, it is apparent that
aggregation that involves AS_SETs is very seldom used in practice on the
public Internet (see ). When it is used, it
is often used incorrectly; only a single AS in the AS_SET is
the most common case . Also, very often the same AS appears in the
AS_SEQUENCE and the AS_SET in the BGP update. The occurrence of reserved
AS numbers is also somewhat frequent.Requirements Language
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
when, and only when, they appear in all capitals, as shown here.
Updates to the Requirements of RFCs 4271 and 5065Unless explicitly configured by a network operator to do otherwise
(e.g., during a transition phase), BGP speakers:
MUST NOT advertise BGP UPDATE messages containing AS_SETs or AS_CONFED_SETs and
MUST use the "treat-as-withdraw" error handling
behavior per upon reception of BGP UPDATE messages containing AS_SETs or AS_CONFED_SETs in the AS_PATH or AS4_PATH .
Per the above specifications, this document updates and
by deprecating AS_SET (see )
and AS_CONFED_SET (see ), respectively.Treatment of Routes with AS_SET in RPKI-Based BGP SecurityResource Public Key Infrastructure (RPKI) uses X.509
extensions for IP addresses and AS identifiers .
RPKI-ROV
is a BGP security technology that never allows a route with AS_SET to be considered Valid.
BGPsec and Autonomous System Provider Authorization (ASPA)
are also BGP security technologies
based on RPKI. BGPsec does not support AS_SETs. In ASPA-based AS_PATH verification,
a route with AS_SET is always considered Invalid and hence ineligible for route selection.BGP AS_PATH "Brief" AggregationSections and of
describe BGP aggregation procedures. describes a generally less utilized
"Complex AS_PATH Aggregation" procedure.
describes the ATOMIC_AGGREGATE Path Attribute and notes that:
When a BGP speaker aggregates several routes for the purpose of
advertisement to a particular peer, the AS_PATH of the aggregated
route normally includes an AS_SET formed from the set of ASes from
which the aggregate was formed. In many cases, the network
administrator can determine if the aggregate can safely be advertised
without the AS_SET, and without forming route loops.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_SET, the aggregated route, when advertised to the peer, SHOULD
include the ATOMIC_AGGREGATE attribute.
When BGP AS_PATH aggregation is done according to the procedures in ,
and any resulting AS_SETs are discarded, it is typically
referred to as "brief" aggregation in implementations. That terminology is adopted here: In this document, brief aggregation refers to what is described in this section, in contrast to consistent brief aggregation as described in .
Brief aggregation results in an AS_PATH that has the following property (from
):
[D]etermine the longest leading sequence of tuples (as defined above)
common to all the AS_PATH attributes of the routes to be aggregated.
Make this sequence the leading sequence of the aggregated AS_PATH
attribute.
The ATOMIC_AGGREGATE Path Attribute is subsequently attached to the
BGP route, if AS_SETs are dropped.Issues with "Brief" AS_PATH Aggregation and RPKI-ROVWhile brief AS_PATH aggregation has the desirable property of not
containing AS_SETs, the resulting aggregated AS_PATH may contain an
unpredictable origin AS.
This is because the aggregating AS may be different from the purported origin AS (for the aggregate), which may vary as explained below.
Such unpredictable origin ASes may result
in RPKI-ROV validation issues:
Depending on the contributing routes to the aggregate route, the
resulting origin AS may vary.
The presence of expected contributing routes may be unpredictable
due to route availability from BGP neighbors.
In the presence of such varying origin ASes, it would be necessary
for the resource holder to register ROAs for each potential origin AS that
may result from the expected aggregated AS_PATHs.
Recommendations to Mitigate Unpredictable AS_PATH Origins for RPKI-ROV PurposesTo ensure a consistent BGP origin AS is announced for
aggregate BGP routes for implementations of "brief" BGP aggregation, the
implementation MUST be configured to truncate the AS_PATH after the
right-most instance of the desired origin AS for the aggregate.
The desired origin AS could be the aggregating AS itself.
A ROA would be necessary for the aggregate prefix with the desired origin AS.This form of brief aggregation is referred to as "consistent
brief" BGP aggregation.If the resulting AS_PATH would be truncated from the otherwise
expected result of BGP AS_PATH aggregation (an AS_SET would not be
generated and possibly some ASes are removed from the "longest leading sequence" of
ASes), the ATOMIC_AGGREGATE Path Attribute SHOULD be attached. This is
consistent with the intent of .Operational ConsiderationsThis section provides advice to operators regarding deployment and configuration.Implementing Consistent Brief AggregationWhen aggregating prefixes, network operators MUST use
consistent brief aggregation as described in
.
In consistent brief aggregation, the AGGREGATOR and ATOMIC_AGGREGATE
Path Attributes are included, but the AS_PATH does not have AS_SET or
AS_CONFED_SET path segment types.
See for examples of
brief aggregation while keeping the origin AS unambiguous
and generating appropriate ROAs.Not Advertising Aggregate Routes to Contributing ASesAn aggregate prefix
SHOULD NOT be announced to the contributing ASes. Instead, more specific
prefixes (from the aggregate) SHOULD be announced to each contributing AS,
excluding any that were learned from the contributing AS in
consideration. See for an example of
this filtering policy.Mitigating Forwarding LoopsWhen both less specific and more specific destinations are present,
it's possible to create forwarding loops between networks, as discussed in .As a reminder, Rule #2 in
requires that BGP implementations performing aggregation discard
packets that match the aggregate route but do not match any of the
more specific routes.
Further discussion of forwarding loops and their relationship to
AS_SETs can be found in .Security ConsiderationsThis document deprecates the use of aggregation techniques that create
AS_SETs or AS_CONFED_SETs. Obsoleting these path segment types from BGP
and the removal of the related code from implementations would potentially
decrease the attack surface for BGP. Deployments of new BGP security
technologies
(e.g., , , and
) benefit greatly if AS_SETs and AS_CONFED_SETs are not used in BGP.IANA ConsiderationsThis document has no IANA actions.ReferencesNormative ReferencesRecommendation for Not Using AS_SET and AS_CONFED_SET in BGPKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.A Border Gateway Protocol 4 (BGP-4)This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.This document obsoletes RFC 1771. [STANDARDS-TRACK]Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation PlanThis memo discusses the strategy for address assignment of the existing 32-bit IPv4 address space with a view toward conserving the address space and limiting the growth rate of global routing state. This document obsoletes the original Classless Inter-domain Routing (CIDR) spec in RFC 1519, with changes made both to clarify the concepts it introduced and, after more than twelve years, to update the Internet community on the results of deploying the technology described. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Autonomous System Confederations for BGPThe Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for Transmission Control Protocol/Internet Protocol (TCP/IP) networks. BGP requires that all BGP speakers within a single autonomous system (AS) must be fully meshed. This represents a serious scaling problem that has been well documented in a number of proposals.This document describes an extension to BGP that may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the "full mesh" requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system.This document obsoletes RFC 3065. [STANDARDS-TRACK]BGP Support for Four-Octet Autonomous System (AS) Number SpaceThe Autonomous System number is encoded as a two-octet entity in the base BGP specification. This document describes extensions to BGP to carry the Autonomous System numbers as four-octet entities. This document obsoletes RFC 4893 and updates RFC 4271. [STANDARDS-TRACK]Revised Error Handling for BGP UPDATE MessagesAccording to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable because a session reset would impact not only routes with the offending attribute but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes.This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760, 5543, 5701, and 6368.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Informative ReferencesDetailed analysis of AS_SETs in BGP updatescommit ef3f4a9BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) ObjectsYandexQrator LabsInternet Initiative Japan & Arrcus, Inc.ArrcusUSA National Institute of Standards and TechnologyThis document describes procedures that make use of Autonomous System Provider Authorization (ASPA) objects in the Resource Public Key Infrastructure (RPKI) to verify the Border Gateway Protocol (BGP) AS_PATH attribute of advertised routes. This AS_PATH verification enhances routing security by adding means to detect and mitigate route leaks and AS_PATH manipulations.Work in ProgressSpecial-Purpose Autonomous System (AS) NumbersIANAX.509 Extensions for IP Addresses and AS IdentifiersThis document defines two X.509 v3 certificate extensions. The first binds a list of IP address blocks, or prefixes, to the subject of a certificate. The second binds a list of autonomous system identifiers to the subject of a certificate. These extensions may be used to convey the authorization of the subject to use the IP addresses and autonomous system identifiers contained in the extensions. [STANDARDS-TRACK]An Infrastructure to Support Secure Internet RoutingThis document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. This document is not an Internet Standards Track specification; it is published for informational purposes.BGP Prefix Origin ValidationTo help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination Autonomous System (AS) of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. [STANDARDS-TRACK]Use Cases and Interpretations of Resource Public Key Infrastructure (RPKI) Objects for Issuers and Relying PartiesThis document describes a number of use cases together with directions and interpretations for organizations and relying parties when creating or encountering Resource Public Key Infrastructure (RPKI) object scenarios in the public RPKI. All of these items are discussed here in relation to the Internet routing system.BGPsec Protocol SpecificationThis document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of Autonomous Systems (ASes) through which a BGP UPDATE message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries digital signatures produced by each AS that propagates the UPDATE message. The digital signatures provide confidence that every AS on the path of ASes listed in the UPDATE message has explicitly authorized the advertisement of the route.The Use of maxLength in the Resource Public Key Infrastructure (RPKI)This document recommends ways to reduce the forged-origin hijack attack surface by prudently limiting the set of IP prefixes that are included in a Route Origin Authorization (ROA). One recommendation is to avoid using the maxLength attribute in ROAs except in some specific cases. The recommendations complement and extend those in RFC 7115. This document also discusses the creation of ROAs for facilitating the use of Distributed Denial of Service (DDoS) mitigation services. Considerations related to ROAs and RPKI-based Route Origin Validation (RPKI-ROV) in the context of destination-based Remotely Triggered Discard Route (RTDR) (elsewhere referred to as "Remotely Triggered Black Hole") filtering are also highlighted.A Profile for Route Origin Authorizations (ROAs)This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. This document obsoletes RFC 6482.Example of Route Filtering for Aggregate Routes and Their Contributors
The illustration presented below shows how an AS_SET is not used when
aggregating and how data plane route loops are avoided.
Consider that p1/24 (from AS 64501), p2/24 (from AS 64502), p3/24 (from AS 64503),
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 AGGREGATE are used.
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 64504.
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.
( ) ( ) ( ) ( )
( AS64501 ) ( AS64502 ) ( AS64503 ) ( AS64504 )
( ) ( ) ( ) ( )
p1/24 p2/24 p3/24 p4/24
| | | |
| +--> ( ) <--+ |
| ( AS64505 ) |
+----------------> ( ) <----------------+
p/22
|
V
AS 64501 AS 64502
========================== ==========================
p1/24 AS_PATH "" p1/24 AS_PATH "64505 64501"
p2/24 AS_PATH "64505 64502" p2/24 AS_PATH ""
p3/24 AS_PATH "64505 64503" p3/24 AS_PATH "64505 64503"
p4/24 AS_PATH "64505 64504" p4/24 AS_PATH "64505 64504"
AS 64503 AS 64504
========================== ==========================
p1/24 AS_PATH "64505 64501" p1/24 AS_PATH "64505 64501"
p2/24 AS_PATH "64505 64502" p2/24 AS_PATH "64505 64502"
p3/24 AS_PATH "" p3/24 AS_PATH "64505 64503"
p4/24 AS_PATH "64505 64504" p4/24 AS_PATH ""
AS 64505
==========================
p/22 AS_PATH "" AGGREGATOR 64505 ATOMIC_AGGREGATE
p1/24 AS_PATH "64501"
p2/24 AS_PATH "64502"
p3/24 AS_PATH "64503"
p4/24 AS_PATH "64504"Examples of Consistent and Inconsistent BGP Origin AS Generated by Brief Aggregation
The examples below illustrate how brief aggregation
may result in an inconsistent origin AS.
AS 64500 aggregates more specific routes into 192.0.2.0/24.Consider the following scenarios where brief aggregation is done
by AS 64500 and what the resultant origin ASes would be.
Routes:
R1 - 192.0.2.0/26 AS_PATH "64501"
R2 - 192.0.2.64/26 AS_PATH "64502"
R3 - 192.0.2.128/26 AS_PATH "64504 64502"
R4 - 192.0.2.192/26 AS_PATH "64504 64501"
( ) ( )
( AS64501 ) ( AS64502 )
( ) ( )
192.0.2.0/26 192.0.2.192/26 192.0.2.128/26 192.0.2.64/26
| | | |
| | | |
| \/ \/ |
| ( ) |
| ( AS64504 ) |
| ( ) |
| | | |
| R4 | | R3 |
| | | |
| \/ \/ |
| R1 ( ) R2 |
+------------------->( AS64500 )<-------------+
( )
|
| (announcing
| aggregate 192.0.2.0/24)
\/Scenario 1: First one route, then another, each with a fully disjoint AS_PATHReceive R1. Aggregate 192.0.2.0/24 AS_PATH "64501"Alternate "bug?": Aggregate 192.0.2.0/24 AS_PATH "[ 64501 ]"(Note: AS numbers within square brackets represent an AS_SET.)Receive R2. Aggregate 192.0.2.0/24 AS_PATH "[ 64501 64502 ]"If brief aggregation is in use, the AS_PATH would be truncated to
the empty AS_PATH, "".The resulting AS_PATH is thus not stable and depends on the presence
of specific routes.Scenario 2: First one route, then another, and the AS_PATHs overlap at the origin ASReceive R1. Aggregate 192.0.2.0/24 AS_PATH "64501"Receive R4. Aggregate 192.0.2.0/24 AS_PATH "[ 64504 64501 ]"If brief aggregation is in use, the AS_PATH is truncated to "".The resulting AS_PATH is thus not stable and depends on the presence
of specific routes.Scenario 3: First one route, then another, and the AS_PATHs overlap at the neighbor ASReceive R3. Aggregate 192.0.2.0/24 AS_PATH "64504 64501"Receive R4. Aggregate 192.0.2.0/24 AS_PATH "64504 [ 64501 64502 ]"If brief aggregation is in use, the AS_PATH is truncated to "64504".The resulting AS_PATH is thus not stable and depends on the presence
of specific routes.Achieving Consistent Origin AS During AggregationIn the three scenarios above, the aggregating AS 64500 is using
brief aggregation. This results in inconsistent
origin ASes as the contributing routes are learned. This motivates the
"consistent brief" BGP aggregation mentioned in
and discussed further
with examples below.The trivial solution to addressing the issue is to simply discard
all of the ASes for the contributing routes. In simple BGP aggregation
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
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
AS, 64500, means that a consistent ROA
could be registered in the RPKI for this prefix. This satisfies the
need for a consistent (unambiguous) origin AS.If the contributing ASes are themselves multihomed to the Internet
outside of their connections to AS 64500, then additional ROAs would
need to be created for each of the more specific prefixes.In more complex proxy aggregation scenarios, there may be a desire
to permit some stable (i.e., common) portion of the contributing AS_PATHs to be kept in the
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
implementation may permit the aggregate's brief AS_PATH to be "64504", and
a ROA would be created for the aggregate prefix with 64504 as the origin AS.
Discussion on Forwarding Loops and AS_SETsAlthough BGP-4 was designed to carry Classless Inter-Domain Routing (CIDR) routes,
does not discuss the installation of "discard"
or "null" routes when implementing its aggregation procedures. Implementations
could originate an aggregate prefix without a covering route
for a more specific prefix (subsumed by the aggregate prefix) present in the local
routing table.When aggregating more specific routes according to
the aggregation procedures of , the aggregating BGP
speaker will place contributing routes into the generated AS_PATH, perhaps
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
provides a form of protection against forwarding loops created by BGP
aggregation.When brief aggregation methods are used, a BGP speaker may receive a
route containing a less specific destination covering a local more specific
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
the possibility of forwarding loops. To help prevent forwarding loops,
it is critical to adhere to the following:
Rule #2 in :
A router that generates an aggregate route for multiple,
more-specific routes must discard packets that match the
aggregate route, but not any of the more-specific routes. In other
words, the "next hop" for the aggregate route should be the null
destination.
Not advertising aggregate routes to contributing ASes
as specified in
of this document (also see ).
AcknowledgementsThe authors would like to thank ,
, , , , , , ,
, ,
, ,
, , , , ,
, ,
, ,
, ,
, ,
, ,
, , , , and for comments and
suggestions. The comments and suggestions received from the IESG
reviewers are also much appreciated.
Authors' AddressesGoogle, Inc.1600 Amphitheatre ParkwayMountain ViewCA94043United States of America+1 571 748 4373warren@kumari.netUSA NIST100 Bureau DriveGaithersburgMD20899United States of America+1 301 975 3973ksriram@nist.govUSA NIST100 Bureau DriveGaithersburgMD20899United States of America+1 301 975 3259lilia.hannachi@nist.govJuniper Networks, Inc.1133 Innovation WaySunnyvaleCA94089United States of Americajhaas@juniper.net