Policy Proposal 2007-19: IANA Policy for Allocation of ASN Blocks to RIRs [Archived]
OUT OF DATE?
Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.
Status: Adopted - To be implemented after ratification by the ICANN Board of Directors
Tracking Information
Discussion Tracking
Mailing List:
Formal introduction on PPML on 28 August 2007
Staff assessment - 14 October 2007
Last Call - 23 October through 6 November 2007
Adopted - 11 December 2007Public Policy Mailing List
ARIN Public Policy Meeting:
ARIN Advisory Council:
23 August 2007
20 September 2007
18 October 2007
15 November 2007
20 December 2007
ARIN Board of Trustees:
Revisions:
Implementation:
To be implemented after ratification by the ICANN Board of Directors
Author(s):
Axel Pawlik
Policy Proposal 2007-19
IANA Policy for Allocation of ASN Blocks to RIRs
Author: Axel Pawlik
Proposal type: New
Policy term: renewable
Policy statement:
Abstract
This document describes the policy governing the allocation of Autonomous System Numbers (ASNs) from the IANA to the Regional Internet Registries (RIRs).
This policy document does not stipulate performance requirements in the provision of services by the IANA to an RIR. Such requirements will be specified by appropriate agreements between ICANN and the Number Resource Organization (NRO).
- Allocation Principles
IANA allocates ASNs to RIRs in blocks of 1024 ASNs. In this document the term “ASN block” refers to a set of 1024 ASNs. Until 31 December 2009, allocations of 2-byte only and 4-byte only ASN blocks will be made separately and independent of each other [1].
This means until 31 December 2009, RIRs can receive two separate ASN blocks, one for 2-byte only ASNs and one for 4-byte only ASNs from the IANA under this policy. After this date, IANA and the RIRs will cease to make any distinction between 2-byte only and 4-byte only ASNs, and will operate ASN allocations from an undifferentiated 4-byte ASN allocation pool.
- Initial Allocations
Each new RIR will be allocated a new ASN block.
- Additional Allocations
An RIR is eligible to receive (an) additional ASN block(s) from the IANA if one of the following conditions is met:
-
The RIR has assigned/allocated 80% of the previously received ASN block, or
-
The number of free ASNs currently held by the RIR is less than two months need. This projection is based on the monthly average number of ASNs assigned/allocated by the RIR over the previous six months.
An RIR will be allocated as many ASN blocks as are needed to support their registration needs for the next 12 months, based on their average assignment/allocation rate over the previous six months, unless the RIR specifically requests fewer blocks than it qualifies for.
- Announcement of IANA Allocations
The IANA, the NRO and the RIRs will make announcements and update their respective websites/databases when an allocation is made by the IANA to an RIR. ICANN and the NRO will establish administrative procedures to manage this process.
[1. http://www.ripe.net/ripe/policies/proposals/2005-12.html]
Rationale:
There are global policies governing the allocation of IPv4 and IPv6 blocks from the IANA to RIRs. At this point there is no specific policy regarding the allocation of Autonomous System Numbers from the IANA to the RIRs. This proposal will create a policy to fill this gap.
The criteria being proposed has already been the practice between IANA and RIRs so far and it has been proven to work. It is designed to allow RIRs to request ASN blocks from the IANA in a timely fashion and maintain enough ASNs in holding to ensure that their registration services can be sustained.
It is also proposed that the RIRs be allocated as many ASN blocks as are needed to support their registration needs for the next 12 months. This will generally mean that each RIR will only need to make one ASN request from the IANA each year, thus lowering operational overhead for the RIRs.
Timetable for implementation: Immediate
OUT OF DATE?
Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.