Require newly created AS-SETs to have hierarchical names

Details

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

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 (authoritative meaning the five IRR DBs operated by the five RIRs). 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 any 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, Why Network Operators Should use Hierarchical as-sets - MANRS . At the time of writing Google's official source for their AS-SET is RADB as documented in their PeeringDB entry PeeringDB , but AS-GOOGLE currently exists as an empty AS-SET in the RIPE DB Webupdates .

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 authorize 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 authorizes 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.

Proposal

3. Proposal

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

Proposed
7.8 AS-SET AS-SETs need to have hierarchical names at the time of creation in the AFRINIC whois database. 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: The colon character (:) is used to separate the elements of the hierarchical name (the AS number from the AS-SET name) There must be at least one colon (:) character in the hierarchical name The first element of the hierarchical name must be an ASN preceded with 'AS' e.g., 'AS65535' Any further elements can be either ASNs or AS-SET names AS-SET names must start with 'AS-' e.g., 'AS-EXAMPLE' Existing AS-SETs MUST 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. Existing AS-SETs which have a non-hierarchical name MAY continue to do so; Editing an existing AS-SET MUST NOT require the maintainer to also rename the set to have a hierarchical name. Exceptions MUST be allowed on a case-by-case basis. For example, a non-hierarchically named AS-SET was deleted by mistake, so it should be possible to restore this AS-SET without having to rename it.

Proposed

7.8 AS-SET

AS-SETs need to have hierarchical names at the time of creation in the AFRINIC whois database.
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:
- The colon character (:) is used to separate the elements of the hierarchical name (the AS number from the AS-SET name)
- There must be at least one colon (:) character in the hierarchical name
- The first element of the hierarchical name must be an ASN preceded with 'AS' e.g., 'AS65535'
- Any further elements can be either ASNs or AS-SET names
- AS-SET names must start with 'AS-' e.g., 'AS-EXAMPLE'
Existing AS-SETs MUST 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.
Existing AS-SETs which have a non-hierarchical name MAY continue to do so;
Editing an existing AS-SET MUST NOT require the maintainer to also rename the set to have a hierarchical name.
Exceptions MUST be allowed on a case-by-case basis. For example, a non-hierarchically named AS-SET was deleted by mistake, so it should be possible to restore this AS-SET without having to rename it.

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.

AFRINIC Policy Impact Assessment

1. DPP Details

Field	Details
Policy ID	AFPUB-2026-ASN-001-DRAFT02
Policy Name	Require newly created AS-SETs to have hierarchical names
URL of Policy Proposal	Require newly created AS-SETs to have hierarchical names -AFPUB-2026-ASN-001-DRAFT02
Date of Assessment	15 June 2026
Affected CPM Section	New Section 7.8 (AS-SETs — hierarchical naming requirement)
Version of IA	[v1 Draft / Internal]

2. Previous Versions — Impact Assessments

Version	URL
v1	[None — first assessment]

3. AFRINIC Staff Assessment

3.1 Staff Interpretation & Understanding of the Proposal

Problem context. AS-SET names are not currently required to be unique across authoritative IRR databases, including the five IRR databases operated by the Regional Internet Registries (RIRs). Where name collisions occur, resolving them is extremely difficult because network operators do not own specific AS-SET names. Although industry practice is to choose a name that clearly identifies the associated network (e.g., "AS-AMAZON" for Amazon), any name may be used, making AS-SET names inherently ambiguous. If AS-SET name squatting is carried out intentionally or maliciously, the affected party has limited recourse to have the squatted AS-SET removed, particularly when it exists in a different IRR database.

What the proposal mandates. To address this, the proposal mandates that any newly created AS-SET in the AFRINIC WHOIS database must use a hierarchical name as defined by RFC 2622 Section 5. Practically, the name must contain a colon, start with the holder's ASN as the first element (e.g., AS12345:AS-CUSTOMERS), followed by an AS-SET element beginning with "AS-", with optional further colon-delimited elements. The rule applies only at creation time: existing non-hierarchical AS-SETs are not to be renamed, and edits to existing objects must not force renaming. Other set types (e.g., route-sets) are explicitly excluded.

How this solves the problem. Hierarchical naming makes AS-SET names unique because the AS number at the front is uniquely assigned by the RIR. This also authorises the user of the AS-SET, since only the operator of that AS number can create hierarchical AS-SET names starting with it — the creator is required to have the authentication details of their AS Number. Furthermore, contact details for the AS-SET will be apparent from the WHOIS database, enabling traceability back to the responsible operator.

Assumptions: Enforcement is limited to authoritative AFRINIC IRR creation workflows; mirroring/resolver behaviour is out of scope. Validation will occur server-side and in any exposed create-forms/APIs. No retroactive clean-up or bulk migration is intended.
Benefit to AFRINIC: Reduced risk of global name collisions and squatting; clearer authorisation linkage between ASNs and sets; fewer misconfigurations propagated via resolvers; alignment with other RIR practices (APNIC, RIPE, LACNIC; ARIN accepted request), improving ecosystem consistency.
Impact on Resource Members: New AS-SET creators must follow hierarchical syntax; minor learning curve and potential updates to automation/tooling that currently assume flat names. Existing non-hierarchical sets remain valid and editable, limiting disruption. Members may need guidance and examples to avoid creation failures.

3.2 Clarity of Policy Text

Can the author consider the following text for the purpose of clarity?

7.8 AS-SET

7.8.1 Any AS-SET created within the AFRINIC Whois Database shall, at the time of its creation, bear a hierarchical name.

7.8.2 For the purposes of this provision, the term “hierarchical name” shall have the meaning ascribed to it in Section 5 of RFC 2622 and shall comply with the following requirements:

(a) the name shall contain at least one colon (:) character;
(b) the first element of the name shall consist of an Autonomous System Number (“ASN”);
(c) the second element of the name shall consist of an AS-SET name prefixed with “AS-”; and
(d) any subsequent element of the name may consist of either an ASN or an AS-SET name.

7.8.3 The present provision shall apply exclusively to AS-SETs and shall not extend to other set types, including but not limited to route sets.

7.8.4 Existing AS-SETs bearing non-hierarchical names shall not be subject to mandatory renaming, in view of the substantial risk of data inconsistencies and the absence of a reliable programmatic method to determine the ASN associations of such existing AS-SETs within the AFRINIC Database.

7.8.5 Any AS-SET existing as at the date of commencement of this provision and bearing a non-hierarchical name may continue to retain and operate under such name.

7.8.6 The modification or editing of an existing AS-SET shall not impose upon the maintainer any obligation to rename the relevant AS-SET so as to conform to the hierarchical naming requirements set out herein.

7.8.7 Exceptions for the creation of hierarchical names may be granted where necessary. AFRINIC shall document the reason for any exception.

Ambiguities/clarifications:

None

3.3 Areas of Impact

3.3.1 Interaction with Existing CPM

No overlaps or conflicts with current CPM sections and any policies awaiting ratification or implementation have been identified.

3.3.2 Interaction with Other DPPs Under Discussion

None

3.3.3 Impact on IP Numbers Registry Systems

System	Impact
WHOIS	The WHOIS systems will require software changes to restrict the creation of non-hierarchical AS-SETs through all its touch points.
RDAP	Will reflect the change on whois for queries on as-sets
MyAFRINIC (Hostmaster, Member Portal, Transfer Tool)	The MyAfrinic IRR interface will require software changes to restrict further creation of non-hierarchical AS-SETs
NetSuite	None
NMRP	None
RPKI	None

3.3.4 Member Services Operations

Procedures: There will be minimal impact on the current processes and procedures as the hierarchical sets are already functional in the WHOIS database

3.3.5 IT

None. Will be implemented on WHOIS and myafrinicv2 systems.

3.3.6 HR

Existing skill sets will be used for the implementation

3.3.7 Legal

No legal issue

3.3.8 Finance

None, subject to existing skill sets being used for implementation

4. Recommendations on Policy Wording

See 3.2 above

5. Staff Clarification Requests

None

6. Staff Observations

We note the exception highlighted in 7.8.6 that could allow restoration of deleted objects. However, we feel that such recalls may introduce operational loopholes, and it may also reduce the effective objective for the policy in general. In the instance that an unintended deletion happens, the affected members may take the opportunity to create aligned AS-SETs.

7. Implementation Plan

Policy can be implemented as written.

The CPM mandates that the implementation date should be less than six months after the end of the Last Call unless a waiver is requested.

Since at present, all resources have been channelled to the myafrinic v2 project which expected to go live by 15 November 2026, the implementation of this policy proposal shall be prioritised once the myafrinicv2 implementation is concluded.

Policy Proposal

Last Modified on - 19 June 2026