[arin-ppml] IPv4 Run Out Proposals

David Farmer farmer at umn.edu
Thu Jul 30 17:58:05 EDT 2009

On 27 Jul 2009 David Farmer wrote:

> I've been meaning to ask this for several weeks now, where 
> has the summer gone?
> Leo and I are the AC Shepards for the two IPv4 Run Out 
> Proposals, they are;
> 93. Predicable IPv4 Run Out by Prefix Size 
> http://lists.arin.net/pipermail/arin-ppml/2009-June/014635.html
> 94. Predictable IPv4 Run Out by Allocation Window
> http://lists.arin.net/pipermail/arin-ppml/2009-June/014392.html
> Leo, I, and I believe much of the AC, think that these proposals 
> shouldn't move forward separately, but that one or the other, or 
> a merged version of the two, should move forward to Draft 
> Policy to be discussed at ARIN XXIV in Dearborn.
> Therefore, Leo and I would like feed back on these two 
> proposals, and your ideas on the following options;
> 1. Should they be merged together and move forward as a 
> single Draft Policy?
> 2. Should "Predicable IPv4 Run Out by Prefix Size" move 
> forward to Draft Policy alone?
> 3. Should "Predictable IPv4 Run Out by Allocation Window" 
> move forward to Draft Policy alone?
> 4. Should they move forward as two separate Draft Policies?
> 5. Should they both be abandoned? 

I've only received feedback from a few of you but what I have 
seems to mostly support the idea of merging the two and 
moving forward with that.
> In order to make it on to the agenda for Dearborn, Draft Policy 
> text must be ready for Staff and Legal Review by the end of 
> this week.  
> So please get any suggestions you have in as soon as 
> possible, I'm going to start on a merged version of the text in 
> case the consensus is to go that way, I will share it on PPML in 
> the next day or two.
> Thank you for your feed back.

Here is the merged text I've been working on, including 
incorporating comments about changing the first part from 
dates to thresholds based on the number of /8s IANA has left.  

Please get me any additional comments ASAP;

1. Policy Proposal Name: Equitable IPv4 Run-Out

2. Proposal Originator:
	a. name:  David Farmer
	b. email:  farmer at umn.edu
	c. telephone:  612-626-0815
	d. organization:  University of Minnesota

3. Proposal Version: 1.2

4. Date: 30 July 2009

5. Proposal type: new

6. Policy term: permanent

7. Policy statement:

Replace the text in NRPM with:

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 Transfers to Specified Recipients per section 8.3, 
in this case an organization may continue choose to request up 
to a 12 month supply of IP addresses.

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

When the IANA free pool reaches 10 or fewer /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 

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 OrgID 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, and is explicitly not applicable to 
resources received through Transfers to Specified Recipients 
per section 8.3, or any other specially designated resources.

8. Rationale:

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 NRPM section 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 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 

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 

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.

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

9. Timetable for implementation:  Immediate

David Farmer                                      Email:farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota		       Phone: 612-626-0815
2218 University Ave SE		       Cell: 612-812-9952
Minneapolis, MN 55414-3029	       FAX: 612-626-1818

More information about the ARIN-PPML mailing list