[ppml] Policy Proposal: globally-coordinated-RIR-pie-IPv4 - AC postponed decision

Member Services info at arin.net
Tue Nov 20 13:51:05 EST 2007


On 15 November 2007, the ARIN Advisory Council (AC) postponed their
decision regarding "globally-coordinated-RIR-pie-IPv4" in order for the
shepherds to work with the author. The AC will review this proposal at
their next regularly scheduled meeting.

The proposal text is below and can be found at:
http://www.arin.net/policy/proposals/submission_archive.html

The ARIN Internet Resource Policy Evaluation Process can be found at:
http://www.arin.net/policy/irpep.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal Name: globally-coordinated-RIR-pie-IPv4

Author: Brian Dickson

Proposal Version: 1

Submission Date: 26 October 2007

Proposal type: new

Policy term: renewable

Policy statement:

This policy concerns the globally-coordinated allocations of IPv4
address space from IANA to the RIRs.

The policy is intended to be compatible with 2007-23 (in its expected
final form).

The overview of the policy is:
At the last reasonable time to do so, divide up the remaining IPv4 space
based on currently projected use between that time and the date at which
  no more IPv4 space is available at any RIR for new allocations.

Here is how the policy is to be implemented:

1) RIRs should provide up-to-date assignment projections for their
respective regions, and provide up-to-date utilization on their current
IANA-assigned block(s) from which assignments are made.

2) RIRs should provide an official projection on IANA Exhaustion Date
(IED) to the community through their website, at their Policy Meetings
and through any other effective means.

3) When any RIR requests a /8 from IANA, the current assignment
projections for that RIR should be combined with the RIR's currently
available IANA  blocks (i.e. from which RIR assignments are made). This
should be compared with the global available IANA unused space (for
allocating to RIRs), the current projected usage rate of the RIR, and
the current projected IED.

If the RIR projection shows that the RIR would not expect to use up two
/8 blocks before IED, the "Pie-splitting" event will be triggered.

4) Splitting the Pie - the following method will be used to determine
the final IPv4 global IANA allocations to the RIRs:
For each RIR, the following calculation will be done:
     (i) Determine from the current projection, the total allocations
the RIR will make from present to IED
     (ii) Subtract from this, unallocated RIR space already received
from ARIN (if any)
     (iii) Round the result to the nearest /12
     (iv) Subtract from this amount, one /8 (to be set aside to satisfy
the 2005-23 policy proposal for "End Policy for IANA IPv4 allocations to
RIRs")
     (v) Allocate this amount to the RIR immediately. Every effort
should be made to divide these allocations among RIRs in as aggregatable
a fashion as possible.

5) The allocations made will result in just 5 * /8 being left in the
IANA pool, which will trigger 2007-23.

6) This in turn, will result in the last 5 * /8's being allocate to the
RIR's, one for each.


Rationale:

The objective of this policy is to ensure that the remaining IPv4 pool
is distributed so as to provide each RIR with a quantity of IPv4
addresses that will last for an expected duration.

The intent is for this duration to be as close to the same for each RIR
as possible.

By following the rules above, the "pie split" is done:
- as late as possible
- as fairly as possible
- in a consistent manner for all RIRs
- early enough that each RIR is guaranteed at least one /8

The final /8 allocations are done *after* this allocation, so that there
can be no issue of fairness, with each RIR being guaranteed to get one
of the final /8's at the same time.

The "pie split" is timed so that no RIR will have so much (relative)
IPv4 address space, as to expect to have IPv4 space after any other RIR
has exhausted its own IPv4 space.

By providing a "pie split" which is based on the same data as the IED
projection, the following results occur:
- there is no contention over the process by which the division of
resources occur
- all RIRs have the ability to project, well in advance of the "pie
split", exactly when their own IPv4 space will be exhausted. It will
happen at the IED date -- no sooner, no later.
- No RIR "shopping" is likely to occur. Consequently, no inter-RIR "land
grab" is likely to occur, and thus the projections for IED itself are
likely to remain consistent, as will the per-RIR projections.
- LIRs are likely to view the policy as neutral, and thus fair.
- Because it removes the incentive for RIR shopping, the rules
preventing RIR shopping will become largely moot (but still
recommended). The perception then of anti-shopping provisions might then
   be that it maintains stability, rather than penalizing any
RIR/LIR/region.

Additional Observations about Fast vs Slow RIRs

Fast-consuming RIRs will contribute more heavily towards the consumption
rate. In turn, these RIRs will be the largest component of the
projections of IED.

Low-consuming RIRs will have less impact on IED. However, the low rate
means that these RIRs will have *greater* proportional accuracy when it
comes to knowing how much space they need between present time and IED.
(This is because, the uncertainty on allocation needs, will be the
result of multiplying the uncertainty on IED date, by the rate of
consumption. Low-consuming LIRs, will have less uncertainty on their
penultimate allocation.)

The uncertainty on exact date of IED, is expected to be largely
invariant across RIRs.

Any changes to individual RIR allocation trends, after the "pie split"
date, are not expected to exceed the individual RIR's own uncertainty at
"pie split" date. In other words, the accuracy of each RIR's IED is
expected to increase over time, and to continue to fall within the range
of the original upper and lower limits (based on rounding to /12) of the
RIR's allocation from IANA.

Timetable for implementation: immediate





More information about the ARIN-PPML mailing list