[ppml] Policy Proposal 2007-27 - Staff Assessment
Policy Proposal 2007-27
Title: Cooperative distribution of the end of the IPv4 free pool
Proposal Submitted: Nov 20, 2007
Date of Assessment: Mar 21, 2008
ARIN Staff Assessment
The assessment of this proposal includes comments from ARIN staff and
the ARIN General Counsel. It contains analysis of procedural, legal, and
resource concerns regarding the implementation of this policy proposal
as it is currently stated. Any changes to the language of the proposal
may necessitate further analysis by staff and Counsel.
Policy Proposal is available as Annex A below and at:
II. Understanding of the proposal
Staff understands that this policy will establish a mechanism for the
allocation of IPv4 address blocks between RIR's once the IANA global
pool of addresses has been depleted.
III. Issues and concerns
A. ARIN Staff
1. This policy would have to adopted as an Inter-RIR policy and would
have to remain the same in each region for it to work properly.
2. There is no way of reliably predicting when an RIR is within 30 days
of depleting their remaining pool of IPv4 addresses since this is
dependent upon the number and size of the resource requests they receive.
3. This policy would require constant monitoring of the available IPv4
inventory of all the RIRs. To be timely, a software tool would need to
be developed that monitored all RIR available IPv4 inventory and
produced a daily report. This same tool would need to be used by all 5
of the RIRs for consistency and accuracy.
4. When the recipient RIR approaches the source RIR for a 3 month supply
of addresses, will fees be charged to the recipient RIR?
5. It is likely that AfriNIC and LACNIC will be the two RIRs who
typically would have the largest inventory of IPv4 at any given time
since they currently allocate address space at a slow rate and in lessor
amounts than the other three RIRs. If the three larger RIRs
consistently approach them for address space, it is likely that their
remaining supply will quickly dwindle.
6. If one RIR will be required to review requests from another region,
all such requests must be made in an agreed upon common language.
7. Process and procedures training may be required for those parties
making requests to an RIR in a region other than their own.
8. If the source RIR reviews and approves requests from the recipient
RIR’s customers, there are likely to be business, legal, and other
administrative issues that arise. For example:
- Which RIR would the requestor pay?
- In what currency would the fee paid?
- Which RIR would have to report the registration fee as income?
- Which RIR would the requestor sign a contract with?
- Which RIR would maintain the record?
- Will the requestor become a member of the source RIR and if so,
will they be required to pay an annual fee to the source RIR?
B. ARIN General Counsel
Counsel sees no significant legal or litigation issues related to this
IV. Resource Impact – Major
The resource impact of implementing this policy is viewed as major.
Barring any unforeseen resource requirements, this policy could be
implemented within 180 days from the date of the ratification of the
policy by the ARIN Board of Trustees. It would also be dependent upon
the policy being adopted in all other RIRs.
• Tracking tool with built in metrics needed to attempt to estimate the
30 day depletion mark
• Survey needs to be created to ask other RIR to estimate their
remaining available space
• Inter RIR coordination process needs to be established for this
process of surveying and follow up actions.
• New guidelines
• Staff training
American Registry for Internet Numbers (ARIN)
Policy Proposal 2007-27
Cooperative distribution of the end of the IPv4 free pool
Author: Tony Hain
Date: 20 November 2007
Proposal type: new
Policy term: permanent
This policy will establish a process for RIR-to-RIR redistribution of
the tail-end of the IPv4 pool, taking effect after the IANA Reserve is
exhausted. Each redistribution Allocation will be triggered by the
recipient RIR depleting its reserve to a 30 day supply, and will result
in up to a 3 month supply being transferred from the RIR with the
longest remaining time before it exhausts its own pool.
At the point when any given RIR is within 30 days of depleting its
remaining IPv4 pool, a survey will be taken of the other 4 to determine
the remaining time before each of them exhausts their pool (including
both member use and recent redistribution allocations to other RIRs).
The one with the longest window before exhausting its pool will be
designated as the source RIR. The recipient RIR will follow procedures
for an LIR in the source RIR region to request a block that is expected
to be sufficient for up to 3 months, but is no larger than 1/8th of the
source RIR's remaining pool. At the point where no RIR can supply a
block that is less than 1/8th of their remaining pool that will sustain
the recipient RIR for 30 days, the recipient RIR will collect its
requests each week, and forward those individual requests to the source
RIR designated that week.
This policy will establish a mechanism for the Allocation of IPv4
address blocks between RIR's, but will not go into effect until the IANA
pool has been depleted.
It is really bizarre to watch the maneuvering as the global RIR
community grapples with 'fairness' of distributing the last few IANA
Reserve /8 blocks. On one level this just appears to be petty sibling
rivalry, as people are bickering over who gets the last cookie and
whimpering about 'fairness'. At the same time, each RIR is chartered to
look after the interests of its membership so it is to be expected that
they will each want to get as much as possible to meet the needs of
their respective membership.
Existing practice requires RIR's to acquire blocks from IANA, which
leads to the current round of nonsense about optimal distribution of the
remaining pool based on elaborate mathematical models.
This globally submitted policy proposal attempts to resolve the issue by
shifting to an RIR-to-RIR Allocation model after the IANA pool is depleted.
This policy would effectively result in each RIR becoming a virtual LIR
member of all of the other RIR's for the sole purpose of managing the
tail-end of the IPv4 pool.
Timetable for implementation: Before 1/1/2009