Require newly created AS-SETs to have hierarchical names

Details

Name of Proposal	Require newly created AS-SETs to have hierarchical names
ID:	AFPUB-2026-ASN-001-DRAFT01	Date Submitted:	15/05/2026
Author(s):	James Bensley james[at]inter.link Inter.link GmbH	Version:	1.0
Obsoletes:		Amends:	New Section in CPM

1. Summary of the problem being addressed by this proposal

There is a long running issue of AS-SET names not being unique across authoritative IRR databases. This happens because at the time of AS-SET creation, an authoritative IRR server can't be sure that the proposed set name doesn't exist in all other IRR databases.

This creates a problem for resolving IRR servers in particular. Resolving IRR servers typically mirror multiple authoritative IRR databases and as a result contain AS-SETs with non-unique names. When a resolving IRR server is queried to compile a prefix or AS path filter list for example, the wrong data may be returned, leading to prefix leaking, or no data may be returned in the case an empty AS-SET is referenced instead of a populated one, resulting in the disconnection of networks.

There has been many incidents over the years, but incidents which relate to hyperscalers are implicitly more visible to the community. MANRS documented the incident with AS-AMAZON back in 2022, https://manrs.org/2022/12/why-network-operators-should-use-hierarchical-as-sets/. At the time of writing Google's official source for their AS-SET is RADB as documented in their PeeringDB entry https://www.peeringdb.com/net/433, but AS-GOOGLE currently exists as an empty AS-SET in the RIPE DB https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=AS-GOOGLE&type=as-set.

Not only do name collisions exist, but getting them fixed is extremely difficult because a network operator does not own a specific AS-SET name. AS-SET names are essentially ambiguous, meaning any name can be used, however it has become industry standard practice to use an AS-SET name which easily identifies the network using the AS-SET i.e, AS-AMAZON is used by Amazon. If name squatting takes place intentionally as part of a malicious act, the victim has no rights to get the squatting AS-SET removed, especially if it is in a different IRR DB.

Therefore, there is a need for AS-SET names to be unique across authoritative IRR database, and to authorise the name assigned to the AS-SET. This can be achieved by enforcing newly created AS-SETs to have hierarchical names. This makes the AS-SET name unique because the AS number at the front of the AS-SET is uniquely assigned by the RIR which assigned the AS number. This also authorises the user of the AS-SET because only the operator of the AS number can create hierarchical AS-SET names which start with that AS number.

2. Summary of how this proposal addresses the problem

The creation of an AS-SET in the AFRINIC DB requires the AS-SET name to be hierarchical.

By using hierarchical set naming which starts with an AS number, only the maintainer of the AS number is able to create such an AS-SET. Enforcing hierarchical names for AS-SETs doesn't rectify existing naming collisions, but it stops the problem from growing any larger than it already has.

Proposal

Adds new section 7.8 article to the CPM, as follows:

Proposed
7.8 AS-SET 1. AS-SETs need to have hierarchical names at the time of creation in the AFRINIC whois database. 2. The definition of a hierarchical set name is already defined in RFC 2622 Section 5 (https://www.rfc-editor.org/rfc/rfc2622.html#page-13). A summary is provided below: There must be at least one colon (:) character in the name The first element of the name must be an ASN The second element of the name must be an AS-SET name starting with 'AS-' Any further elements can be either ASNs or AS-SET names 3. Other set types such as route sets are excluded. 4. Existing AS-SETs will not be renamed due to the massive data inconsistencies this would create, and because there is no way to programmatically determine which ASNs the existing AS-SETs in the AFRINIC DB relate to. 5. Existing AS-SETs which have a non-hierarchical name may continue to do so; 6. Editing an existing AS-SET MUST NOT require the maintainer to also rename the set to have a hierarchical name.

Proposed

7.8 AS-SET

1. AS-SETs need to have hierarchical names at the time of creation in the AFRINIC whois database.

2. The definition of a hierarchical set name is already defined in RFC 2622 Section 5 (https://www.rfc-editor.org/rfc/rfc2622.html#page-13). A summary is provided below:

There must be at least one colon (:) character in the name
The first element of the name must be an ASN
The second element of the name must be an AS-SET name starting with 'AS-'
Any further elements can be either ASNs or AS-SET names

3. Other set types such as route sets are excluded.

4. Existing AS-SETs will not be renamed due to the massive data inconsistencies this would create, and because there is no way to programmatically determine which ASNs the existing AS-SETs in the AFRINIC DB relate to.

5. Existing AS-SETs which have a non-hierarchical name may continue to do so;

6. Editing an existing AS-SET MUST NOT require the maintainer to also rename the set to have a hierarchical name.

4. References

In other regions, all IPv4 addresses have been exhausted and it seems that the equivalent to the soft-landing is not any more an issue, because most of the existing members only can access IPv4 addresses via transfers.

5. References

- APNIC have implemented this under PROP-151: https://www.apnic.net/community/policy/proposals/prop-151/

- RIPE have implemented this under NWI-19: https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items/

- LACNIC implemented this as part of their initial IRR daemon deployment.

- ARIN have accepted the request to enforce hierarchical naming: https://www.arin.net/participate/community/acsp/consultations/2025/2025-1/

AFRINIC is the only major RIR which has not currently implemented this feature, or is not currently working towards implementing it. If/when AFRINIC implements it, AS-SET squatting in the 5 major RIRs will no longer be possible and AS-SETs will be have become more secure globally.

Policy Proposal

Last Modified on - 20 May 2026