ASN assignment criteria revisited

Summary of Proposal

This policy proposal changes the requirements for ASN assignments.

Under the new policy, LIRs and End Users 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 acknowledge that the current requirements are unenforceable in practice [1] and that ASNs are no longer a scarce resource, given the full introduction and global acceptance of 32-bit ASNs.

The aim of this policy is to simplify requirements for new ASNs, while ensuring that the requirements are enforceable in practice and preventing the exponential exhaustion of 32-bit 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

LIRs and End Users may be issued the first Autonomous System Number (ASN) upon request without justification.

LIRs and End Users may be issued additional ASNs.

Requirements for additional ASNs are:

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

When requesting an AS Number to be visible in the Global Routing Table (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. When requesting an AS Number not to be visible in the GRT, 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 must fulfil the criteria for which the application was approved within six months after the ASN is issued.

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

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

In case of an off-GRT ASN, RIPE NCC may request operational proof that the criteria are fulfilled. Failing to provide sufficient proof is considered as not fulfilling the criteria.

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."

Rationale

There are valid technical reasons for having a single-homed ASN. Using BGP and RPSL has appeared to be a very robust way of exchanging routing information. Customers with their own IP space would benefit from using a dedicated ASN to communicate routing information over BGP.

The conservation measures currently in place are not really helpful anymore; they reduce visibility and make operating and troubleshooting of networks more complex.

a. Arguments supporting the proposal

Four-octet (32-bit) ASNs were defined in May 2007 in RFC4893. It has taken several years for routing equipment in general use to catch up, but with 32-bit AS numbers, ASNs are no longer a scarce resource.

IANA has assigned 402,332 ASN to RIRs, which represents approximately 0.01% of the available 32-bit ASN space. In comparison, RIRs have assigned only around 88,400 ASNs to network operators, which accounts for about 0.002% of the available 32-bit ASN space.

Our policies should reflect this, and we should utilise number resources in a way that helps network operators reduce operational complexity, while increasing visibility for network operation and troubleshooting.

Lastly, the current ASN requirements have proven to be unenforceable in practice. Many ASes fulfil the multihomed requirement at first, but become single-homed over time. Others never become multihomed. In fact, half of the ASNs allocated by RIPE do not meet the requirements. [1]

This proposal removes all requirements for the first ASN assigned to an End User and introduces a set of reasonable requirements that will not deplete the pool of available ASNs while remaining enforceable for the RIPE NCC.

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

b. Arguments against the proposal

Simplifying the availability of ASNs will lead to an increase in the number of Autonomous Systems on the GRT. While ASN depletion is not a concern in the foreseeable future, there could be an increase of complexity of the GRT, which in its turn may increase the requirements for processing power and memory of network equipment.

Counterarguments:

• An increase of Autonomous Systems might not have such a significant effect on hardware requirements as one might initially anticipate. The conservation measures outlined in RFC1930, RFC2270, and others only conserve the AS numbers and not the power and memory needed to process the announced prefixes. When a foreign prefix (e.g., PI) is announced (via, for example, a private ASN) by an AS (e.g., an ISP), it still creates a separate entry in the routing table.
• This policy shouldn't lead to a significant increase in the complexity of the GRT, because best practices from RFC1930 have not been used.

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

Counterarguments:

• The new RIPE NCC fees, particularly the "per ASN" fee, help mitigate this to some extent. That said, the current “per ASN” fee of 50€ would, in practice, not prevent the development of such technologies based on cost alone. On the other hand, an increase of fees could negatively impact small and private ASN end-users. There is a risk of mass (hundreds or thousands) ASN requests.

The impact of this policy should be reviewed within a reasonable timeframe after implementation.