Draft Policy ARIN-2011-9 (Global Proposal): Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA [Archived]

Status: NRPM 10.5

Tracking Information

Discussion Tracking

Mailing List:

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

Public Policy Mailing List

ARIN Public Policy Meeting:

ARIN XXVIII

ARIN Advisory Council:

AC Shepherds:
David Farmer and Chris Grundemann

• 18 August 2011
• 15 September 2011
• 14 October 2011
• 16 November 2011

ARIN Board of Trustees:

16 December 2011

Revisions:

Previous version(s)

Implementation:

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

Policy statement:

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
contain:
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
follows:
a. Allocations from the IANA may begin once the pool is declared
active.
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
(power-of-2) boundary.
No RIR may get more than this calculation used to determine
the IPv4 allocation unit even when they can justify a need for
it.
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.

Rationale:

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
  place

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.