Draft Policy ARIN-2011-9 (Global Proposal): Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA [Archived]
OUT OF DATE?
Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.
Status: NRPM 10.5
Formal introduction on PPML on 24 August 2011
Origin - ARIN-prop-137
Draft Policy - 24 August 2011 (with staff assessment)
Revised rationale - 22 September 2011
Last Call - 19 October through 2 November 2011
AC recommended adoption - 22 November 2011
Adopted in region - 16 December 2011
Adopted by ICANN Board - 6 May 2012
Added to the NRPM - 31 July 2012
ARIN Public Policy Meeting:
ARIN Advisory Council:
David Farmer and Chris Grundemann
ARIN Board of Trustees:
31 July 2012
Draft Policy ARIN-2011-9 (Global Proposal)
Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA
Date: 22 September 2011
The IANA shall establish a Recovered IPv4 Pool to be utilized post
RIR IPv4 exhaustion. The Recovered IPv4 Pool will initially contain
any fragments that may be left over in the IANA. It will also hold
any space returned to the IANA by any other means.
The Recovered IPv4 Pool will be administered by the IANA. It will
a. Any fragments left over in the IANA inventory after the last
/8s of IPv4 space are delegated to the RIRs
- The IANA inventory excludes “Special use IPv4 addresses” as
defined in BCP 153 and any addresses allocated by the IANA
for experimental use.
b. Any IPv4 space returned to the IANA by any means.
The Recovered IPv4 Pool will stay inactive until the first RIR has
less than a total of a /9 in its inventory of IPv4 address space.
When one of the RIRs declares it has less than a total of a /9 in
its inventory, the Recovered IPv4 pool will be declared active, and
IP addresses from the Recovered IPv4 Pool will be allocated as
a. Allocations from the IANA may begin once the pool is declared
b. In each “IPv4 allocation period”, each RIR will receive a
single “IPv4 allocation unit” from the IANA.
c. An “IPv4 allocation period” is defined as a 6-month period
following 1 March or 1 September in each year.
d. The IANA will calculate the size of the “IPv4 allocation unit”
at the following times:
- When the Recovered IPv4 Pool is first activated
- At the beginning of each IPv4 allocation period
To calculate the “IPv4 allocation unit” at these times, the
IANA will use the following formula:
IPv4 allocation unit = 1/5 of Recovered IPv4 pool,
rounded down to the next CIDR
No RIR may get more than this calculation used to determine
the IPv4 allocation unit even when they can justify a need for
The minimum “IPv4 allocation unit” size will be a /24. If the
calculation used to determine the IPv4 allocation unit results
in a block smaller than a /24, the IANA will not distribute
any addresses in that IPv4 allocation period.
The IANA may make public announcements of IPv4 address
transactions that occur under this policy. The IANA will make
appropriate modifications to the “Internet Protocol V4 Address
Space” page of the IANA website and may make announcements to its
own appropriate announcement lists. The IANA announcements will
be limited to which address ranges, the time of allocation, and to
which Registry they have been allocated.
The policy provides a mechanism for the ongoing distribution of
IPv4 address space, while removing the areas that have been
problematic in previous attemts at this proposal. The proposal:
Permits regional variation in runout policy amongst RIRs to
be accounted for in the distribution of the Recovered IPv4 Pool
Prevents the possibility of a single RIR being eligible to
be allocated the entire Recovered IPv4 Pool in the first
(and perhaps only) allocation period
Removes two areas of policy that have failed to reach
agreement in previous attempts at this proposal:
How addresses should be placed in the Recovered IPv4 Pool
References to how transfers should or should not take
The NRO must clarify that this Global Policy is not intended to
supersede the IETF’s right to make IPv4 assignments for
“specialised address blocks (such as multicast or anycast
blocks)” as documented in section 4.3 of RFC 2860. The
NRO and IANA should coordinate with the IETF to make such
assignments as necessary, and honor any reservations made
for works currently in progress.
Timetable for implementation:
Once consensus has been reached in each of the 5 RIR regions, the
policy will be forwarded to ICANN for approval and then implemented
by the IANA.