For over three decades, BGP’s AS_SET path segment has been a legal, if problematic, feature of Internet routing. In May 2025, the IETF formally ended that era. RFC 9774 doesn’t merely discourage AS_SET: it prohibits it entirely.This post unpacks what AS_SET is, why it was created, what went wrong, and what network operators need to do now that the IETF has made its deprecation a binding standard requirement.
Background: What is the AS_PATH attribute?
Every BGP UPDATE message carries an AS_PATHattribute – a record of the Autonomous Systems a route advertisement has traversed on its way from origin to destination. It serves two critical functions: loop prevention (a router seeing its own AS in the path discards the route) and policy (operators use AS_PATH to make routing decisions based on where traffic comes from or how it’s being forwarded.
The AS_PATH is composed of path segments, each of which is one of four types:
| Type | Description | Status |
|---|---|---|
| AS_SEQUENCE | An ordered list of ASes the route has passed through. The most common and well-understood type. | Valid |
| AS_SET | An unordered set of ASes created during route aggregation. Now deprecated. | Deprecated |
| AS_CONFED_SEQUENCE | Ordered list of Member AS Numbers within a BGP confederation. | Valid |
| AS_CONFED_SET | An unordered set of confederation member ASes, used during intra-confederation aggregation, is now deprecated. | Deprecated |
Where did AS_SET come from?
To understand AS_SET, you need to understand route aggregation. As the Internet evolved in the early 1990s, the routing table was growing rapidly, raising concerns about scalability and making aggregation an important operational technique. Aggregation was an essential tool: rather than advertising a dozen /24s, an upstream provider could collapse them into a single /20, reducing routing table size and churn across the global DFZ (Default-Free Zone).
But aggregation created a problem for AS_PATH: if you combine routes from AS 64501, AS 64502, and AS 64503 into a single aggregate, which ASes go into the AS_PATH? The original BGP-4 specification (RFC 4271) addressed this by defining AS_SET as an unordered collection of all contributing ASes. The aggregate route would carry an AS_PATH like:
EXAMPLE AS_PATH WITH AS_SET
65000 {64501, 64502, 64503}The curly braces denote an unordered set. The idea was sound in theory: preserve a complete record of which ASes contributed to the aggregate, enabling loop detection and policy filtering to still function correctly across the aggregated prefix.
In practice, this ended up causing far more problems than it solved.
The problems with AS_SET
- It breaks route origin validation
Modern BGP security depends heavily on knowing, with certainty, which AS originated a given prefix. The Resource Public Key Infrastructure (RPKI) system allows operators to create Route Origin Authorizations (ROAs) that cryptographically bind a prefix to its authorized originating AS. When a route is validated using RPKI-based Route Origin Validation (RPKI-ROV), the system checks whether the origin AS in the AS_PATH is covered by a valid ROA.
When AS_SET is present, the “origin” of the route becomes a set of ASes rather than a single, unambiguous one. This is fundamentally incompatible with RPKI-ROV: a route with an AS_SET cannot be considered Valid under RPKI-ROV. It will always be treated as either NotFound or Invalid, depending on the RPKI state of the contributing ASes.
- Loop prevention becomes unreliable
BGP’s built-in loop detection works by checking whether a router’s own AS number appears in the incoming route’s AS_PATH. If yes, the route is discarded. This is clean and deterministic for AS_SEQUENCE, but with AS_SET, the aggregating router may strip some contributing ASes when generating the “brief” aggregate path, breaking the implicit guarantee that contributing ASes will always appear in the path and reject the aggregate.
RFC 9774’s Appendix C details how this can create forwarding loops: a contributing AS may accept the aggregate route (because its AS number was dropped from the brief path), install it in its RIB, and then forward traffic toward the aggregate, creating a loop that never resolves.
- It is rarely used correctly in practice.
Analysis of historical Internet routing data, as cited directly in the RFC, reveals that AS_SET aggregation is extremely rare on the public Internet. More critically, when it does appear, it is usually implemented incorrectly. The most common observed case is an AS_SET containing only a single AS – semantically identical to an AS_SEQUENCE entry, but with all the security downsides of a set. Reserved AS numbers also appear with surprising frequency in observed AS_SETs, pointing to misconfiguration rather than intentional use.
From BCP to prohibition: The journey from RFC 6472 to RFC 9774
The problems with AS_SET were not unknown. In December 2011, the IETF published RFC 6472 as Best Current Practice 172 (BCP 172), which recommended not using AS_SET and AS_CONFED_SET. The keyword is “recommended.” RFC 6472 was advisory; operators could choose to ignore it without violating any standard.
Fourteen years of deployment experience, the rise of RPKI, and the operational evidence that AS_SET was causing more harm than good led the IETF’s IDR (Inter-Domain Routing) working group to take the next step. RFC 9774, published in May 2025, advances that recommendation to a normative, standards-track requirement:
RFC 9774 - SECTION 3 (NORMATIVE REQUIREMENTS) Unless 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 upon reception of BGP UPDATE messages containing AS_SETs or AS_CONFED_SETs in the AS_PATH or AS4_PATH.
The “treat-as-withdraw” behavior (defined in RFC 7606) means that upon receiving a BGP UPDATE with an AS_SET, a router must silently treat it as if it were a withdrawal, discarding the route rather than processing it. This is a much stronger stance than ignoring or filtering: it makes non-compliance operationally costly.
The right way to aggregate: consistent brief aggregation
RFC 9774 doesn’t just prohibit AS_SET; it specifies a compliant replacement, consistent brief aggregation. The core idea is to generate aggregate routes without AS_SET by truncating the AS_PATH at a stable, designated origin AS, and signaling the information loss using existing BGP attributes.
The ATOMIC_AGGREGATE and AGGREGATOR attributes
When a router generates an aggregate and drops AS_SET (or any portion of contributing ASes), it SHOULD attach the ATOMIC_AGGREGATE path attribute to the advertised route. This attribute serves as a transparent signal to all downstream routers: “this route was created by aggregation, and some AS path information has been deliberately omitted.” Routers receiving such a route are expected not to disaggregate it.
The AGGREGATOR attribute complements this by recording the AS number and IP address of the router that performed the aggregation, providing accountability and diagnostic context without requiring the full contributing AS set.
Truncating to a consistent origin
The most important operational requirement in RFC 9774 is that when performing consistent brief aggregation, the implementation MUST be configured to truncate the AS_PATH after the rightmost instance of the desired origin AS. This ensures the origin AS in the aggregate is stable and predictable – a prerequisite for registering a valid ROA.
AGGREGATION EXAMPLE: AS 64505 AGGREGATING FOUR /24S INTO A /22
Contributing prefixes and their origins:
p1/24 ← AS 64501
p2/24 ← AS 64502
p3/24 ← AS 64503
p4/24 ← AS 64504
Aggregated by AS 64505 into p/22:
p/22 AS_PATH "" AGGREGATOR 64505 ATOMIC_AGGREGATE
Individual more-specifics are still announced with full AS_PATHs
to all ASes EXCEPT the contributing AS receiving the update:
AS 64503 receives:
p1/24 AS_PATH "64505 64501"
p2/24 AS_PATH "64505 64502"
p4/24 AS_PATH "64505 64504"
(p3/24 is NOT announced back to AS 64503)
Note: The aggregate p/22 is NOT announced to contributing ASes
to prevent forwarding loops.
Not advertising the aggregate to contributing ASes
RFC 9774 reinforces a crucial loop-prevention rule: the aggregate SHOULD NOT be announced to any of the contributing ASes. Instead, the more-specific prefixes (excluding the one learned from that particular contributing AS) should be announced back to each contributor. This prevents the scenario where a contributing AS installs the aggregate and creates a black hole or loop when the more-specific routes are withdrawn.
Impact on BGP security technologies
The deprecation of AS_SET is not merely a housekeeping exercise. It is a deliberate, necessary step to enable the full deployment of the next generation of BGP security infrastructure.
| Security Technology | Relationship to AS_SET | Benefit from RFC 9774 |
|---|---|---|
| RPKI-ROV Route Origin Validation | Routes with AS_SET can never be Valid under RPKI-ROV. The origin AS is ambiguous. | Aggregate routes now have a single, stable origin AS that can be covered by ROA. |
| BGPsec | BGPsec does not support AS_SET. Routes with AS_SET are incompatible with BGPsec processing. | Removes an entire class of routes that block BGPsec deployment. |
| ASPAAS Provider Authorization | In ASPA-based path verification, routes with AS_SET are always considered Invalid and excluded from route selection. | Aggregate routes become eligible for ASPA verification once AS_SET is absent. |
What this means for the operators
RFC 9774 includes a transition provision: operators may explicitly configure their routers to continue generating or accepting AS_SET during a migration phase. But the expectation is clear – this is a temporary escape hatch, not a permanent exemption. Here’s what network operators should be doing:
Audit your aggregation configurations
Review any BGP aggregate-address statements or route summarization policies in your routers. Identify every instance where AS_SET generation is enabled (common in Cisco IOS as aggregate-address X.X.X.X/Y as-set). These must be migrated to consistent brief aggregation.
Switch to consistent brief aggregation
Configure your aggregation to truncate the AS_PATH at a designated, stable origin AS, ideally your own AS. Attach ATOMIC_AGGREGATE and AGGREGATOR attributes. Verify that the origin AS in the resulting aggregate is deterministic across all contributing route combinations.
Register ROAs for your aggregate prefixes
Once you have a stable origin AS for each aggregate, register a corresponding ROA in the RPKI. Without a matching ROA, RPKI-ROV will mark your aggregate as NotFound; still better than Invalid, but not ideal. ROA creation is available through your Regional Internet Registry (RIR) portal.
Filter incoming AS_SET routes
Per RFC 9774’s “treat-as-withdraw” requirement, configure your BGP speakers to drop any incoming UPDATE containing AS_SET silently. Most major router vendors have already implemented or are in the process of implementing this behavior.
Update peering filter policies
Review your inbound BGP filtering policies to reject routes with AS_SET path segments explicitly. This protects your network even if a peer’s router has not yet been updated. For a broader framework of routing security best practices, MANRS (Mutually Agreed Norms for Routing Security) provides an actionable baseline applicable to any network operator.
State of play: ten months after RFC 9774
RFC 9774 was published on 21 May 2025. As of March 2026, the broader BGP security ecosystem has continued to move, and understanding that context makes the AS_SET deprecation feel less like a housekeeping RFC and more like one tile clicking into place in a much larger mosaic.
RPKI-ROV: Past the tipping point
The single most important development reinforcing the logic of RFC 9774 has been the accelerating deployment of RPKI Route Origin Validation. By mid-2024, a landmark was crossed: for the first time in RPKI history, the majority of IPv4 routes in the global routing table were covered by Route Origin Authorizations, with IPv6 having crossed the 50% threshold even earlier.
More recently, more than half of both the IPv4 routes and the IPv6 routes in the BGP Internet routing system are now secured with RPKI, and, perhaps more significantly, three-quarters of all IP traffic is now bound for RPKI-secured destinations. The gap between “routes covered” and “traffic covered” reflects the fact that the largest content providers and eyeball networks, which carry the bulk of global traffic, were early adopters.
On the enforcement side, the reduction in the propagation of RPKI-invalid routes can be primarily attributed to the tier-1 backbone providers that reject invalids, with invalid routes achieving propagation no greater than 50% of BGP sources in Routeviews, and often far less. Any operator still generating AS_SET on an aggregate prefix is, by definition, generating a route that will fail validation for the majority of Internet traffic.
ASPA: The next layer is arriving
RFC 9774’s deprecation of AS_SET was explicitly designed to unblock the next generation of BGP path security. The most immediate beneficiary is ASPA (Autonomous System Provider Authorization) – a mechanism that extends RPKI-based verification beyond route origins to the full AS_PATH, enabling routers to detect route leaks that origin validation alone cannot catch. Routes containing AS_SET are always considered Invalid under ASPA-based path verification, which means the removal of AS_SET from the routing table is a direct prerequisite for ASPA to function correctly on aggregated prefixes. With ARIN and RIPE NCC having reached full ASPA production capability, and major networks already deploying ASPA validation globally, the ecosystem that RFC 9774 enables is now arriving in earnest.
A real-world reminder: July 2025 hijack incident
Theory is one thing; operational reality is another. In July 2025, a routing hijack incident – the kind covered in depth in Noction’s guide to BGP hijacking and prevention – illustrated exactly the kind of attack that the RFC 9774 → RPKI → ASPA chain is designed to prevent. Three short-duration attacks occurred between 9 and 12 July 2025, using social engineering: the attacker hijacked an ASN and used it to convince a multinational transit provider to propagate the hijacked prefixes, involving IP addresses in the Americas and an ASN from Asia. Coordination among the three Regional Internet Registries resolved the issue.
The incident was ultimately contained, but it demonstrated that the tools to prevent it (RPKI ROAs for origin, ASPA records for path verification) must be deployed by all parties involved, not just the victim. An aggregate route with an unambiguous origin AS and a valid ROA would have been far harder to hijack without detection.
Where vendors and operators stand
RFC 9774 includes a transition provision that permits operators to continue generating or accepting AS_SET during the migration phase. In practice, the community is moving in the right direction, though unevenly. Most major router platforms from Juniper, Cisco, and others have long supported suppressing AS_SET generation (typically via “brief” aggregation modes), and RFC 9774 simply makes that the required default rather than an operator choice.
The real migration work is at the operational layer: auditing aggregate-address configurations, confirming that ATOMIC_AGGREGATE and AGGREGATOR are being attached correctly, and registering ROAs for all aggregate prefixes. ROV adoption remains uneven globally, but the critical tier-1 and major transit providers are already enforcing it, meaning that any operator still generating AS_SET on aggregate prefixes is increasingly likely to have those routes suppressed or treated as unknown by downstream networks.
For over three decades, BGP’s AS_SET path segment has been a legal, if problematic, feature of Internet routing. In May 2025, the IETF formally ended that era. RFC 9774 doesn’t merely discourage AS_SET: it prohibits it entirely.
This post unpacks what AS_SET is, why it was created, what went wrong, and what network operators need to do now that the IETF has made its deprecation a binding standard requirement.
Background: What is the AS_PATH attribute?
Every BGP UPDATE message carries an AS_PATHattribute – a record of the Autonomous Systems a route advertisement has traversed on its way from origin to destination. It serves two critical functions: loop prevention (a router seeing its own AS in the path discards the route) and policy (operators use AS_PATH to make routing decisions based on where traffic comes from or how it’s being forwarded.
The AS_PATH is composed of path segments, each of which is one of four types:
| Type | Description | Status |
|---|---|---|
| AS_SEQUENCE | An ordered list of ASes the route has passed through. The most common and well-understood type. | Valid |
| AS_SET | An unordered set of ASes created during route aggregation. Now deprecated. | Deprecated |
| AS_CONFED_SEQUENCE | Ordered list of Member AS Numbers within a BGP confederation. | Valid |
| AS_CONFED_SET | An unordered set of confederation member ASes, used during intra-confederation aggregation, is now deprecated. | Deprecated |
Where did AS_SET come from?
To understand AS_SET, you need to understand route aggregation. As the Internet evolved in the early 1990s, the routing table was growing rapidly, raising concerns about scalability and making aggregation an important operational technique. Aggregation was an essential tool: rather than advertising a dozen /24s, an upstream provider could collapse them into a single /20, reducing routing table size and churn across the global DFZ (Default-Free Zone).
But aggregation created a problem for AS_PATH: if you combine routes from AS 64501, AS 64502, and AS 64503 into a single aggregate, which ASes go into the AS_PATH? The original BGP-4 specification (RFC 4271) addressed this by defining AS_SET as an unordered collection of all contributing ASes. The aggregate route would carry an AS_PATH like:
EXAMPLE AS_PATH WITH AS_SET
65000 {64501, 64502, 64503}The curly braces denote an unordered set. The idea was sound in theory: preserve a complete record of which ASes contributed to the aggregate, enabling loop detection and policy filtering to still function correctly across the aggregated prefix.
In practice, this ended up causing far more problems than it solved.
The problems with AS_SET
- It breaks route origin validation
Modern BGP security depends heavily on knowing, with certainty, which AS originated a given prefix. The Resource Public Key Infrastructure (RPKI) system allows operators to create Route Origin Authorizations (ROAs) that cryptographically bind a prefix to its authorized originating AS. When a route is validated using RPKI-based Route Origin Validation (RPKI-ROV), the system checks whether the origin AS in the AS_PATH is covered by a valid ROA.
When AS_SET is present, the “origin” of the route becomes a set of ASes rather than a single, unambiguous one. This is fundamentally incompatible with RPKI-ROV: a route with an AS_SET cannot be considered Valid under RPKI-ROV. It will always be treated as either NotFound or Invalid, depending on the RPKI state of the contributing ASes.
- Loop prevention becomes unreliable
BGP’s built-in loop detection works by checking whether a router’s own AS number appears in the incoming route’s AS_PATH. If yes, the route is discarded. This is clean and deterministic for AS_SEQUENCE, but with AS_SET, the aggregating router may strip some contributing ASes when generating the “brief” aggregate path, breaking the implicit guarantee that contributing ASes will always appear in the path and reject the aggregate.
RFC 9774’s Appendix C details how this can create forwarding loops: a contributing AS may accept the aggregate route (because its AS number was dropped from the brief path), install it in its RIB, and then forward traffic toward the aggregate, creating a loop that never resolves.
- It is rarely used correctly in practice.
Analysis of historical Internet routing data, as cited directly in the RFC, reveals that AS_SET aggregation is extremely rare on the public Internet. More critically, when it does appear, it is usually implemented incorrectly. The most common observed case is an AS_SET containing only a single AS – semantically identical to an AS_SEQUENCE entry, but with all the security downsides of a set. Reserved AS numbers also appear with surprising frequency in observed AS_SETs, pointing to misconfiguration rather than intentional use.
From BCP to prohibition: The journey from RFC 6472 to RFC 9774
The problems with AS_SET were not unknown. In December 2011, the IETF published RFC 6472 as Best Current Practice 172 (BCP 172), which recommended not using AS_SET and AS_CONFED_SET. The keyword is “recommended.” RFC 6472 was advisory; operators could choose to ignore it without violating any standard.
Fourteen years of deployment experience, the rise of RPKI, and the operational evidence that AS_SET was causing more harm than good led the IETF’s IDR (Inter-Domain Routing) working group to take the next step. RFC 9774, published in May 2025, advances that recommendation to a normative, standards-track requirement:
RFC 9774 - SECTION 3 (NORMATIVE REQUIREMENTS) Unless 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 upon reception of BGP UPDATE messages containing AS_SETs or AS_CONFED_SETs in the AS_PATH or AS4_PATH.
The “treat-as-withdraw” behavior (defined in RFC 7606) means that upon receiving a BGP UPDATE with an AS_SET, a router must silently treat it as if it were a withdrawal, discarding the route rather than processing it. This is a much stronger stance than ignoring or filtering: it makes non-compliance operationally costly.
The right way to aggregate: consistent brief aggregation
RFC 9774 doesn’t just prohibit AS_SET; it specifies a compliant replacement, consistent brief aggregation. The core idea is to generate aggregate routes without AS_SET by truncating the AS_PATH at a stable, designated origin AS, and signaling the information loss using existing BGP attributes.
The ATOMIC_AGGREGATE and AGGREGATOR attributes
When a router generates an aggregate and drops AS_SET (or any portion of contributing ASes), it SHOULD attach the ATOMIC_AGGREGATE path attribute to the advertised route. This attribute serves as a transparent signal to all downstream routers: “this route was created by aggregation, and some AS path information has been deliberately omitted.” Routers receiving such a route are expected not to disaggregate it.
The AGGREGATOR attribute complements this by recording the AS number and IP address of the router that performed the aggregation, providing accountability and diagnostic context without requiring the full contributing AS set.
Truncating to a consistent origin
The most important operational requirement in RFC 9774 is that when performing consistent brief aggregation, the implementation MUST be configured to truncate the AS_PATH after the rightmost instance of the desired origin AS. This ensures the origin AS in the aggregate is stable and predictable – a prerequisite for registering a valid ROA.
AGGREGATION EXAMPLE: AS 64505 AGGREGATING FOUR /24S INTO A /22
Contributing prefixes and their origins:
p1/24 ← AS 64501
p2/24 ← AS 64502
p3/24 ← AS 64503
p4/24 ← AS 64504
Aggregated by AS 64505 into p/22:
p/22 AS_PATH "" AGGREGATOR 64505 ATOMIC_AGGREGATE
Individual more-specifics are still announced with full AS_PATHs
to all ASes EXCEPT the contributing AS receiving the update:
AS 64503 receives:
p1/24 AS_PATH "64505 64501"
p2/24 AS_PATH "64505 64502"
p4/24 AS_PATH "64505 64504"
(p3/24 is NOT announced back to AS 64503)
Note: The aggregate p/22 is NOT announced to contributing ASes
to prevent forwarding loops.
Not advertising the aggregate to contributing ASes
RFC 9774 reinforces a crucial loop-prevention rule: the aggregate SHOULD NOT be announced to any of the contributing ASes. Instead, the more-specific prefixes (excluding the one learned from that particular contributing AS) should be announced back to each contributor. This prevents the scenario where a contributing AS installs the aggregate and creates a black hole or loop when the more-specific routes are withdrawn.
Impact on BGP security technologies
The deprecation of AS_SET is not merely a housekeeping exercise. It is a deliberate, necessary step to enable the full deployment of the next generation of BGP security infrastructure.
| Security Technology | Relationship to AS_SET | Benefit from RFC 9774 |
|---|---|---|
| RPKI-ROV Route Origin Validation | Routes with AS_SET can never be Valid under RPKI-ROV. The origin AS is ambiguous. | Aggregate routes now have a single, stable origin AS that can be covered by ROA. |
| BGPsec | BGPsec does not support AS_SET. Routes with AS_SET are incompatible with BGPsec processing. | Removes an entire class of routes that block BGPsec deployment. |
| ASPAAS Provider Authorization | In ASPA-based path verification, routes with AS_SET are always considered Invalid and excluded from route selection. | Aggregate routes become eligible for ASPA verification once AS_SET is absent. |
What this means for the operators
RFC 9774 includes a transition provision: operators may explicitly configure their routers to continue generating or accepting AS_SET during a migration phase. But the expectation is clear – this is a temporary escape hatch, not a permanent exemption. Here’s what network operators should be doing:
Audit your aggregation configurations
Review any BGP aggregate-address statements or route summarization policies in your routers. Identify every instance where AS_SET generation is enabled (common in Cisco IOS as aggregate-address X.X.X.X/Y as-set). These must be migrated to consistent brief aggregation.
Switch to consistent brief aggregation
Configure your aggregation to truncate the AS_PATH at a designated, stable origin AS, ideally your own AS. Attach ATOMIC_AGGREGATE and AGGREGATOR attributes. Verify that the origin AS in the resulting aggregate is deterministic across all contributing route combinations.
Register ROAs for your aggregate prefixes
Once you have a stable origin AS for each aggregate, register a corresponding ROA in the RPKI. Without a matching ROA, RPKI-ROV will mark your aggregate as NotFound; still better than Invalid, but not ideal. ROA creation is available through your Regional Internet Registry (RIR) portal.
Filter incoming AS_SET routes
Per RFC 9774’s “treat-as-withdraw” requirement, configure your BGP speakers to drop any incoming UPDATE containing AS_SET silently. Most major router vendors have already implemented or are in the process of implementing this behavior.
Update peering filter policies
Review your inbound BGP filtering policies to reject routes with AS_SET path segments explicitly. This protects your network even if a peer’s router has not yet been updated. For a broader framework of routing security best practices, MANRS (Mutually Agreed Norms for Routing Security) provides an actionable baseline applicable to any network operator.
State of play: ten months after RFC 9774
RFC 9774 was published on 21 May 2025. As of March 2026, the broader BGP security ecosystem has continued to move, and understanding that context makes the AS_SET deprecation feel less like a housekeeping RFC and more like one tile clicking into place in a much larger mosaic.
RPKI-ROV: Past the tipping point
The single most important development reinforcing the logic of RFC 9774 has been the accelerating deployment of RPKI Route Origin Validation. By mid-2024, a landmark was crossed: for the first time in RPKI history, the majority of IPv4 routes in the global routing table were covered by Route Origin Authorizations, with IPv6 having crossed the 50% threshold even earlier.
More recently, more than half of both the IPv4 routes and the IPv6 routes in the BGP Internet routing system are now secured with RPKI, and, perhaps more significantly, three-quarters of all IP traffic is now bound for RPKI-secured destinations. The gap between “routes covered” and “traffic covered” reflects the fact that the largest content providers and eyeball networks, which carry the bulk of global traffic, were early adopters.
On the enforcement side, the reduction in the propagation of RPKI-invalid routes can be primarily attributed to the tier-1 backbone providers that reject invalids, with invalid routes achieving propagation no greater than 50% of BGP sources in Routeviews, and often far less. Any operator still generating AS_SET on an aggregate prefix is, by definition, generating a route that will fail validation for the majority of Internet traffic.
ASPA: The next layer is arriving
RFC 9774’s deprecation of AS_SET was explicitly designed to unblock the next generation of BGP path security. The most immediate beneficiary is ASPA (Autonomous System Provider Authorization) – a mechanism that extends RPKI-based verification beyond route origins to the full AS_PATH, enabling routers to detect route leaks that origin validation alone cannot catch. Routes containing AS_SET are always considered Invalid under ASPA-based path verification, which means the removal of AS_SET from the routing table is a direct prerequisite for ASPA to function correctly on aggregated prefixes. With ARIN and RIPE NCC having reached full ASPA production capability, and major networks already deploying ASPA validation globally, the ecosystem that RFC 9774 enables is now arriving in earnest.
A real-world reminder: July 2025 hijack incident
Theory is one thing; operational reality is another. In July 2025, a routing hijack incident – the kind covered in depth in Noction’s guide to BGP hijacking and prevention – illustrated exactly the kind of attack that the RFC 9774 → RPKI → ASPA chain is designed to prevent. Three short-duration attacks occurred between 9 and 12 July 2025, using social engineering: the attacker hijacked an ASN and used it to convince a multinational transit provider to propagate the hijacked prefixes, involving IP addresses in the Americas and an ASN from Asia. Coordination among the three Regional Internet Registries resolved the issue.
The incident was ultimately contained, but it demonstrated that the tools to prevent it (RPKI ROAs for origin, ASPA records for path verification) must be deployed by all parties involved, not just the victim. An aggregate route with an unambiguous origin AS and a valid ROA would have been far harder to hijack without detection.
Where vendors and operators stand
RFC 9774 includes a transition provision that permits operators to continue generating or accepting AS_SET during the migration phase. In practice, the community is moving in the right direction, though unevenly. Most major router platforms from Juniper, Cisco, and others have long supported suppressing AS_SET generation (typically via “brief” aggregation modes), and RFC 9774 simply makes that the required default rather than an operator choice.
The real migration work is at the operational layer: auditing aggregate-address configurations, confirming that ATOMIC_AGGREGATE and AGGREGATOR are being attached correctly, and registering ROAs for all aggregate prefixes. ROV adoption remains uneven globally, but the critical tier-1 and major transit providers are already enforcing it, meaning that any operator still generating AS_SET on aggregate prefixes is increasingly likely to have those routes suppressed or treated as unknown by downstream networks.
