Require newly created AS-SETs to have hierarchical names
| 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.
3. Proposal
Adds new section 7.8 article to the CPM, as follows:
| Proposed |
|---|
|
7.8 AS-SET
|
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.
Revision History
|
Date |
Details |
| 8th June 2026 |
Version 2: Revised with feedback to version 1.0 from the mailing list |
| 15th May 2026 |
Version 1: AFPUB-2026-ASN-001-DRAFT01 Initial Draft Posted to RPD |
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.