From: Urban Suhadolnik via address-policy-wg <address-policy-wg@ripe.net>
Date: Saturday, 29 March 2025 at 10:44
To: address-policy-wg@ripe.net <address-policy-wg@ripe.net>
Cc: tfiebig@mpi-inf.mpg.de <tfiebig@mpi-inf.mpg.de>
Subject: [address-policy-wg] DRAFT ASN assignment critera revisited

[EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources.

Dear Colleagues,

Following RIPE 89 Address policy WG, I was asked to prepare a new policy for ASN assignment criteria together with Tobias. We've compared the ASN assignment criteria at other RIRs, current proposals at other RIR and followed various conversations at RIPE community events.
After some internal feedback from Alex, Leo and PDO we feel that this draft is ready for the mailing list.

I would like to ask all of you for feedback on the proposal and on the text of the proposal.

Best,
Urban and Tobias

_____________________________

Summary of Proposal

This policy proposal changes the requirements for ASN assignments.

Under the new policy, any organization or LIR (in case of multiple LIR per ASN) may request a single ASN without justification. Additional ASNs can be assigned if the requester provides a unique external routing policy and demonstrates peering with a third party.

The proposed changes reflect the reality that the current requirements are unenforceable in practice [1] and that ASNs are no longer a scarce resource since the complete introduction and global acceptance of 32-bit ASNs.

The aim of this policy is to simplify requirements for new ASN, while making the requirements enforceable in practice and avoiding exponential burn of 32bit ASN space.

[1] - Personal ASN Open House Recap - RIPE NCC - Page 5 https://ripe89.ripe.net/wp-content/uploads/presentations/88-Personal-ASN.pdf

Policy text:

Current policy text

2.0 Assignment Criteria

In order to help decrease global routing complexity, a new AS Number should be used only if a new external routing policy is required, see RFC1930.

A network must be multihomed in order to qualify for an AS Number.

When requesting an AS Number, the routing policy of the Autonomous System must be provided. The new unique routing policy should be defined in RPSL language, as used in the RIPE Database.

The RIPE NCC will assign the AS Number directly to the End User upon a request properly submitted to the RIPE NCC either directly or through a sponsoring LIR. AS Number assignments are subject to the policies described in the RIPE NCC document entitled “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region”.

New policy text

2.0 Assignment Criteria

Any organization OR LIR, in case an organization has more than one LIR, may be issued a single Autonomous System Number (ASN) upon request.

Organizations and LIRs may be issued additional ASNs.

Requirements for additional ASNs are:

Unique external routing policy of the Autonomous System must be provided. The uniqueness of the routing policy includes the announced prefixes.
Autonomous System must peer with a third party.

When requesting an AS Number to be visible in the GRT, the routing policy of the Autonomous System must be provided. The new unique routing policy should be defined in RPSL language, as used in the RIPE Database. Otherwise, documentation on the non-visible purpose, e.g., a reference to the assigned IXP LAN prefixes, must be provided.

Reasonable periodic use cases MAY be allowed. A benefit statement for such MUST be provided.

The requester has 6 months after the ASN has been issued to fulfil the criteria for which the application was approved.

Approval of an additional ASN MAY depend on fulfilment of criteria and up-to-date documentation on existing ASNs.

In case of an ASN visible in the GRT, RIPE NCC confirms that the ASN fulfils the criteria by checking publicly visible state in the GRT.

In case of off-GRT ASN, RIPE NCC may ask for operational proof of fulfilling the criteria. Failing to provide sufficient proof is considered as not fulfilling the criteria.

Rationale

There are valid technical reasons for having a single homed ASN. BGP and RPSL has appeared to be a very robust way of exchanging routing information. Schemes where customer's have their own IP space would benefit by using a dedicated ASN to communicate routing information over BGP.

Conservation measures currently implemented are not really helpful anymore. They reduce visibility and make operating and troubleshooting of networks more complex.

Arguments supporting the proposal

Four octet (32 bit) ASNs were defined in May 2007 in RFC 4893. It has taken several years for routing equipment in general use to catch up, but with 32 bit AS numbers, ASN are not a scarce resource anymore.

IANA has assigned 402332 ASN to RIRs which is ~0.01 % of available 32 bit ASN space. While RIRs have assigned only around, 88400 to network operators, which represents ~0,002 % of available 32 bit ASN.

Our policies should reflect that, and we should utilize number resources in such a way to help network operators reduce operational complexity and increase visibility for operating and troubleshooting networks.

Lastly, the current ASN requirements have appeared to be unenforceable in practice. Many AS start by fulfilling the multihomed requirement, but then turn single-homed over time, while others have never become multihomed in the first place. Half of allocated ASN by RIPE don't fulfil the requirements [1]

This proposal removes the requirement for the first Autonomous System Number for an organisation or LIR (in case an organisation has more than one LIR) and introduces a set of requirements that are reasonable, will not deplete the pool of available ASN and be enforceable for RIPE NCC.

[1] - Personal ASN Open House Recap - RIPE NCC - Page 5 https://ripe89.ripe.net/wp-content/uploads/presentations/88-Personal-ASN.pdf

Arguments against the proposal

Simplified availability of ASN will result in an increase of Autonomous Systems on the GRT. While depletion of available ASN will not be a problem in the foreseeable future, there could be an increase of complexity of the GRT which will increase the requirements on processing power and memory of network equipment.

Counterarguments:

An increase of Autonomous systems might not have as big of effect on hardware requirements as one might think at first. Conservation measures for cases presented in RFC1930 and RFC2280 and others conserve only the AS number, and do not conserve the processing power and memory needed to process the announced prefixes. When a foreign prefix (e.g. PI) as announced (via e.g. private ASN) from an AS (e.g. ISP) it still creates a separate entry in the routing table.
This policy shouldn't cause any significant increase of complexity of GRT, because best practices from RFC1930 were not used.

New technologies built on easy availability of AS numbers could exponentially increase the request rate for new AS numbers

Counterarguments:

New RIPE NCC fees, particularly "per ASN" fee, mitigates this to some extent. However, current per ASN fee of 50€, would in practice not stop such technology from being developed based on cost alone. On the other hand, an increase of fees would jeopardize small and private ASN end-users. Risk of mass (hundreds or thousands) ASN requests exist.

The effect of this policy should be reviewed within a reasonable timeframe after implementing.