[arin-ppml] ARIN-2011-9 (Global Proposal): Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA - Last Call
The ARIN Advisory Council (AC) met on 14 October 2011 and decided to
send the following draft policy to last call:
ARIN-2011-9 (Global Proposal): Global Policy for post exhaustion IPv4
allocation mechanisms by the IANA
Feedback is encouraged during the last call period. All comments should
be provided to the Public Policy Mailing List. Last call for 2011-9 will
expire on 2 November 2011. After last call the AC will conduct their
last call review.
The draft policy text is below and available at:
The ARIN Policy Development Process is available at:
Communications and Member Services
American Registry for Internet Numbers (ARIN)
## * ##
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.