Policy Proposal 93: Predicable IPv4 Run Out by Prefix Size - Revised

Member Services info at arin.net
Thu Jun 18 13:58:33 EDT 2009


Policy Proposal 93
Predicable IPv4 Run Out by Prefix Size

The proposal originator submitted a revised version of the proposal.

The AC will review this proposal at their next regularly scheduled
meeting and decide how to utilize the proposal. Their decision will be
announced to the PPML.

In the meantime, the AC invites everyone to comment on this proposal on
the PPML, particularly their support or non-support and the reasoning
behind their opinion. Such participation contributes to a thorough
vetting and provides important guidance to the AC in their deliberations.

The ARIN Policy Development Process can be found at:
http://www.arin.net/policy/pdp.html

Mailing list subscription information can be found at:
http://www.arin.net/mailing_lists/

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


#####


1. Policy Proposal Name: Predicable IPv4 Run Out by Prefix Size

2. Proposal Originator:  David Farmer

3. Proposal Version: 1.1

4. Date: 18 June 2009

5. Proposal type: new

6. Policy term: permanent

7. Policy statement:

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 proposal is intended to ensure an equitable distribution of
the remaining ARIN free pool resources once additional
resources are no longer abundantly available from IANA.
Equity is achieved 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.

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.

The maximum allocation size is intended to apply to both ISP
allocations and End-user assignments.

The current maximum allocation size should be publish in real-
time on the ARIN website, as it may change rapidly as the
ARIN free pool resources are exhausted.

Following the run-out phase, this proposal 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 resources, this policy intends for
the maximum allocation size to be increased accordingly.

The intent of the second paragraph is to normally limit an
organization to a single maximum allocation within a three
month period.  However, saying it that simply opens the 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 the second paragraph as
stated, 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, it would likely
result in the resource being spread across significantly fewer
organizations and increase the need to use multiple blocks to
fulfill requests.

Finally, combining the 3 month period 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.

9. Timetable for implementation:  Immediate




More information about the Info mailing list