2009-8 Previous Version [Archived]


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.

View the current policy proposal text.

The following version was archived on 24 November 2009.

Draft Policy 2009-8
Equitable IPv4 Run-Out

Version/Date: 31 August 2009

Policy statement:

Replace NRPM with; Subscriber Members After One Year

After an organization has been a subscriber member of ARIN for one year, they may choose to request up to a 12 month supply of IP addresses.

As the IANA free pool decreases, the length of supply that an organization may request will be reduced at the following thresholds. This reduction does not apply to resources received via section 8.3. An organization receiving a transfer under section 8.3 may continue to request up to a 12 month supply of IP addresses.

When IANA reaches 20 or fewer unallocated /8s, an organization may choose to request up to a 6 month supply of IP addresses;

When IANA reaches 10 or fewer unallocated /8s, an organization may choose to request up to a 3 month supply of IP addresses;

Create a new subsection in section 4 of the NRPM;

4.X Maximum Allocation or Assignment during and following Run-Out

When ARIN receives its last /8, by IANA implementing section, a proportionally decreasing maximum allocation, and assignment, size will be put into effect. The maximum allocation will be the next whole CIDR prefix less than or equal to one quarter (1/4) of the total ARIN free pool available at the time of each allocation, but no longer than the applicable minimum allocation.

An organization may request additional resources when it can demonstrate it has properly utilized all previous allocations per applicable policies. However, the total of all allocations received within the last three (3) month period and the current request, cannot exceed the current maximum allocation size.

This maximum allocation size is applicable to allocations from the ARIN free pool only. It is explicitly not applicable to resources received via transfer under section 8.3, or any other specially designated resources.


This proposed policy is intended to ensure an equitable distribution of IPv4 resources as run-out of the IANA free pool and subsequently the ARIN free pool occurs. This is achieved in two parts; first, changing section of the NRPM to reduce the length of supply of IPv4 resources that may be requested in steps as the IANA free pool runs-out. This helps accomplish equity by reducing the window that an advantage or disadvantage can exist between competitors, that will be created when one competitor receives a final allocation just before run-out and another competitor does not.

The reductions in the length of supply will be triggered by IANA reaching defined levels of unallocated /8s, including the /8s reserved as part of section 10.4 of the NRPM. These triggers have been chosen base on the current rate of consumption of /8s by the RIRs.

The first part of this policy is similar to ideas in RIPE policy proposal 2009-03 ((http://www.ripe.net/ripe/policies/proposals/2009-03.html) , and has been adapted by discussion and for use within the ARIN region.

The second part of this policy, allows a maximum of one quarter (1/4) of the then current total IPv4 resources to be allocated in a single request, once ARIN has received its last /8 from IANA. This helps achieve equity by ensuring the available resources are spread among multiple organizations and that no single organization may monopolize all of the resources available through a single request, at least until the maximum allocation size has been reduced down to the minimum allocation size.

Incrementally reducing the length of supply and then reducing the maximum allocation size in proportion to the amount of resources available should minimize, or possibly eliminate, the need to fulfill requests with multiple smaller blocks.

As in the current NRPM, the length of supply only applies to ISP allocations. However, the maximum allocation size is intended to apply to both ISP allocations and End-user assignments.

This policy is intended to be independent of other policies or proposals to reserve address space for IPv6 transition or other purposes. Neither part is intended to limit Transfers to Specified Recipients per section 8.3 of the NRPM.

The current maximum allocation size should be published on the ARIN website, preferably in real-time, as it may change rapidly as the ARIN free pool resources are exhausted. In the worst-case the maximum allocation size will decrease every forth allocation, when all four are the then current maximum allocation size. However, in the beginning there will likely be many smaller allocations before the maximum allocation size is decreased, accelerating as the resources are exhausted.

Following the run-out phase, this policy provides an equitable means of distribution of resources if or when additional resources become available after ARIN has initially exhausted such resources. Such as if resources are returned, recovered by other means, or additional resources are obtained from IANA. Further, whenever ARIN receives a sufficiently large amount of additional resources, this policy intends for the maximum allocation size to be increased accordingly.

After ARIN receives its last /8, the intent is to normally limit an organization to a single maximum allocation within a three month period. However, saying it that simply opens this policy to gamesmanship in requesting less than a maximum allocation. Requiring a maximum allocation to cover new requests and all allocations received in the previous three month period, should eliminate this kind of gamesmanship.

There is a beneficial side effect of stating it this way, in the special situation when the maximum allocation size is increased, due to ARIN obtaining a sufficiently large amount of additional resources, an organization may receive additional resources earlier than the normal three month period. But, only in this special situation and when an organization properly utilizes a previous maximum allocation in less than three months, may an organization receive additional resources in less than the normal three month period.

Other ratios, such as one half (1/2) or one eighth (1/8) could be considered. One eighth (1/8) would provide greater assurance of eliminating the need to use multiple blocks to fulfill requests and ensure a greater number of organizations receive resources. However, one eighth (1/8) is more likely to be seen as rationing and an attempt to artificially extend the lifetime of IPv4. During the ARIN XXIII policy discussion there seemed to be a consensus that attempts to extend the lifetime of IPv4 resources would be undesirable. While on the other hand, one half (1/2) is even less likely to ration resources, but it would likely result in the resource being spread across significantly fewer organizations and increase the need to use multiple blocks to fulfill requests.

In conclusion, combining the final 3 month length of supply with the one quarter (1/4) ratio provides roughly an annualized equivalent of the whole ARIN free pool being made available to a single organization. While it is not possible for a single organization to receive the whole ARIN free pool within one year under this policy, it is a virtual certainty that multiple organization will be requesting resources, and that the ARIN free pool will not likely last a full year following the exhaustion of the IANA free pool anyway. Therefore, the ratio one quarter (1/4) seems to strike a balance between making resources available with as little restriction as possible and ensuring an equitable distribution of those resources during and following the run-out phase.

EDITORIAL NOTE: This Draft Policy 2009-8 merges ideas from two separate policy proposals, 93. Predicable IPv4 Run Out by Prefix Size and 94. Predictable IPv4 Run Out by Allocation Window.

Timetable for implementation: Immediate


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.