[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 4.2.4.4 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
Run-Out
When ARIN receives its last /8, by IANA implementing section
10.4.2.2, 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 4.2.4.4 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
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-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