- Legend
- Added
- Deleted
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.
ASNs are required to:
- Have a
Requirements for additional ASNs are:A
policy for the Autonomous System must be provided.The uniqueness of the routing policy includes the announced prefixes. - Have a routing policy defined in the RIPE Database.
- Peer
The Autonomous System must peerwith a third party. - In case the ASN is used for a purpose that is not
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 bevisible in the GRT, documentation on the non-visible purpose (e.g., a reference to the assigned IXP LAN prefixes) must be provided.
ASNs should be in use
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
Intermittent usage such as research, measurements, events, etc. may be allowed at the discretion of the RIPE NCC. A benefit statement for such usage must be provided.
To request additional ASNs you must provide:
- A unique external routing policy for the new Autonomous System. The uniqueness of the routing policy includes the announced prefixes.
- A reason for why inactive existing ASNs cannot be used.
Approval of an additional ASN may depend on the fulfilment of ASN requirements for existing ASNs, at the discretion of the RIPE NCC.
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, numbers, ASNs are no longer a scarce resource.
IANA has assigned 402,332 ASNs 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 the RIPE NCC 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 in the of complexity of the GRT, which in its turn may increase the requirements for the 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
numbersand 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
shouldn'tlead to a significant increase in the complexity of the GRT, because best practices from RFC1930 have not been used.
New technologies built on the easy availability of AS Numbers numbers could exponentially increase the request rate for new ASNs.
Counterarguments:
- The new RIPE NCC fees, particularly the “per ASN”
"per ASN"fee, help mitigate this to some extent. That said, the current “per ASN” fee of €5050€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.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.