Skip to main content

Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries

This policy proposal has been accepted

2009-07
Publication date:
06 Jan 2011
State:
Accepted
Affects
Draft document
DRAFT: IANA Policy for Allocation of ASN Blocks to RIRs
Author(s)
  • Andrew de la Haye
  • Stacy Hughes
  • Andrew de la Haye
  • Stacy Hughes
Proposal Version
1.0 - 27 May 2009
All Versions
Accepted
10 Sep 2009
Working Group
Address Policy Working Group
Proposal type
  • Modify
Policy term
Indefinite

According to the current global policy (ripe-416), IANA will cease to make any distinction between 16 bit and 32-bit only ASN blocks by 31 December 2009, when making allocations to RIRs. This proposal is to extend this date by one year, to 31 December 2010

Summary of Proposal:

According to the current global policy (ripe-416), IANA will cease to make any distinction between 16 bit and 32-bit only ASN blocks by 31 December 2009, when making allocations to RIRs. This proposal is to extend this date by one year, to 31 December 2010.

Rationale:

Arguments supporting the proposal

Due to operational issues external to the IANA/RIR policy process, 32-bit only ASNs are not being issued by the RIRs at the anticipated rate. As it stands, RIRs will likely not be able to justify a new block of ASNs from the IANA after 31 December 2009 due to a glut of free 32 bit only ASNs in the RIR’s pool. This leaves available, essential 16-bit ASNs stranded in the IANA free pool. This proposal seeks to remedy the potential problem by extending the deadline for differentiation by one year.

With this proposal the policy will be aligned with the actual reality in regards to 32-bit ASN deployment and usage.

The subject was raised during RIPE 58 and a presentation was made.

The feedback in this session suggested that a global policy proposal should be developed and should be discussed.

Arguments Opposing the Proposal

Some may think that extending the previously set timeline can be perceived as some discouragement for the deployment of 32-bit ASNs. One counter argument to this is that RIRs and Internet community have some other mechanisms and activities to raise awareness for 32-bit ASN pool (via public presentations and trainings). These activities will continue while 16-bit ASN blocks are still allocated to RIRs by the IANA as they are available and they are needed.

Impact Analysis

Note: In order to provide additional information related to the proposal, details of an impact analysis carried out by the RIPE NCC are documented below. The projections presented in this analysis are based on existing data and should be viewed only as an indication of the possible impact that the policy may have if the proposal is accepted and implemented.

A. Impact of Policy on Registry and Addressing System

Address/Internet Number Resource Consumption:
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.

Fragmentation/Aggregation:
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.

B. Impact of Policy on RIPE NCC Operations/Services

Having analysed the data that is currently available, the RIPE NCC does not anticipate that this proposal will cause any significant impact on RIPE NCC operations/services if it is implemented.

Without this policy change, however, the RIPE NCC will probably not be able to justify a new block of 16-bit ASNs from the IANA after 31 December 2009 due to a glut of free 32-bit only ASNs in the RIPE NCC pool. According to currently available numbers, the current 16-bit pool of the RIPE NCC is expected to be empty around February 2010. By extending the date by 12 months to 31 December 2010 on which the IANA will cease to make any distinction between 16-bit and 32-bit only ASNs when allocating blocks of them to RIRs, it will effectively reduce the risk of the RIPE NCC not being able to justify receiving a new block of 16-bit ASNs.