[arin-ppml] Fwd: FW: [sig-policy] prop-097: Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA

Martin Hannigan hannigan at gmail.com
Tue Jan 25 22:45:06 EST 2011

FYI -- another global proposal in the struggle for the control of
legacy addresses post exhaustion.



------ Forwarded Message
From: Terence Zhang YH <zhangyinghao at cnnic.cn>
Date: Tue, 25 Jan 2011 07:35:46 -0500
To: Policy SIG <sig-policy at apnic.net>
Subject: [sig-policy] prop-097: Global Policy for post exhaustion IPv4
allocation mechanisms by the IANA

Dear SIG members,

The proposal, 'Global Policy for post exhaustion IPv4 allocation
mechanisms by the IANA', has been sent to the Policy SIG for review. It
will be presented at the Policy SIG at APNIC 31 in Hong Kong SAR,
China, 21-25 February 2011.

We invite you to review and comment on the proposal on the mailing list
before the meeting.

The comment period on the mailing list before an APNIC meeting is an
important part of the policy development process. We encourage you to
express your views on the proposal:

       - Do you support or oppose this proposal?
       - Do you see any disadvantages in this proposal?
       - Is there anything in the proposal that is not clear?
       - What changes could be made to this proposal to make it more

Information about this and other policy proposals is available from:


Gaurab, Ching-Heng, and Terence


prop-097-v001: Global Policy for post exhaustion IPv4 allocation
               mechanisms by the IANA

Authors:       Alejandro Acosta
               Nicolas Antoniello
               S. Moonesamy
               Douglas Onyango
               Medel Ramirez
               Masato Yamanishi

               Note: The co-authors are actively seeking authors from
                     all regions to ensure all RIR community's needs
                     are met. We encourage interested community members
                     to become co-authors of this proposal.

Version:       1

Date:          25 January 2011

1.  Introduction

This proposal describes the process that IANA will follow to allocate
IPv4 resources to Regional Internet Registries (RIRs) after the central
pool of addresses is exhausted.

The processes for how IPv4 space may be placed in the IANA Recovered
IPv4 Pool is out of the scope of this proposal.

2. Definitions

2.1 IPv4 address holdings

    IPv4 address holdings are all unallocated IPv4 address space held
    by an RIR.

2.2 Aggregated address blocks

    Aggregated address blocks are contiguous prefixes that can be
    aggregated on natural bit boundaries.

3.  Summary of the current problem

An earlier global policy proposal authored by a team consisting of
people from each of the five RIRs reached consensus at four RIRs, and
was subsequently endorsed by these RIRs' Boards. In the APNIC region,
this was prop-069, "Global policy proposal for the allocation of IPv4
blocks to Regional Internet Registries". To see the proposal reference
number for this proposal in all five RIRs, see Appendix A.

The version approved in the fifth region was substantially rewritten by
that community to meet some of their concerns. However, given the
nature of the rewrites, it would have been difficult to reconcile that
version with the version that reached concensus in the other four RIRs.
Therefore, some members of the ARIN community wrote a new global
proposal, "Global Policy for IPv4 Allocations by the IANA Post
Exhaustion", which has been adopted in the ARIN region. It is under
discussion in the AfriNIC, APNIC and RIPE regions. In the APNIC region,
it is prop-086. To see the proposal reference number for this proposal
in all five RIRs, see Appendix A. However, there are significant issues
with prop-086. These are:

    - The reclamation pool could be exhausted by RIR(s) with high
      allocation rates after the first (or first few) allocation

      There are two main reasons RIRs will have differing allocation
      rates after the IANA pool is exhausted:

      1. Rate of Internet growth in the region

      2. Policies developed by different regions governing
         how the last part of their IPv4 addresses are to be

      In response to IPv4 exhaustion, some RIR communities have chosen
      to apply policies to a part of their last IPv4 addresses that aim
      to assist with a smooth transition to IPv6. An effect of such
      policies is that it can slow down the consumption of IPv4
      addresses allocated under these policies. This side effect would
      put RIRs that have chosen to adopt such policies at a
      disadvantage, as they will take far longer to qualify for space
      under prop-086 compared to RIRs that have chosen not to adopt
      such policies. Therefore, to ensure that regional variation in
      runout policy amongst RIRs is accounted for, it is important to
      have an IANA redistribution method that can continue to provide
      resources to RIRs over more than one (or only a few) allocation

- The definitions of when an RIR is considered to be "exhausted",
 and therefore eligible for space from IANA, should be more
 flexible given the very different RIR policy environments and the
 number of addresses available at any given time.

- Under the redistribution formula proposed in prop-086, it is
 possible for one RIR to be the single eligible RIR in the first
 IANA allocation period and for that RIR to claim the entire
 reclamation pool. It is also possible that only one RIR could
 be eligible during subsequent allocation periods, and take the
 total IANA pool available at that time.

 To prevent this from happening, it is better to have a formula
 that would allow eligible RIRs to take only a certain fraction
 of the IANA pool at each allocation period.

A problem with both prop-069 and prop-086 is related to the policy for
the return of addresses by the RIRs to IANA:

- In prop-069, the return of addresses to the reclamation pool was
 mandatory. This restriction was of significant concern to the
 ARIN community.

- In prop-086, return of addresses by RIRs is optional, but there
 is nothing to prevent an RIR which has contributed nothing
 towards IANA's return pool from claiming part, or indeed all, of
 the return pool.

    - Because of the two above issues, this new proposal separates the
      return of address space to the IANA from the redistribution of
      that space by the IANA. Instead, the authors of this new proposal
      treat the return and redistribution as two separate issues that
      should be treated as separate policies.

4.  Situation in other RIRs

This proposal will be submitted to all RIRs with a view to becoming
global policy.

5.  Details

Upon adoption of this IPv4 address policy by the ICANN Board of
Directors, the IANA shall establish a Recovered IPv4 Pool to be
utilized post RIR IPv4 exhaustion as defined in Section 1. 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.

5.1 Recovered IPv4 Pool

    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
    exhausts its inventory of IPv4 address space as defined in
    Sections 5.3b below.

    Once active, IP addresses from the Recovered IPv4 Pool will be
    allocated as stated in Section 5.2 below.

5.2 Allocation of returned IPv4 address space by the IANA

    a. Allocations from the IANA may begin once the pool is declared

    b. For the purposes of this policy, an "IPv4 allocation period" is
       defined as a 6-month period following 1 March or 1 September in
       each year.

    c. 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/10 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.

    d. In each allocation period, each eligible RIR may issue one IPv4
       request to the IANA.

       Providing that the RIR satisfies the allocation criteria
       described in section 5.3, the IANA will allocate a single
       allocation unit, composed of the smallest possible number of
       blocks available in its IPv4 address pool.

5.3 Allocation criteria

    a. To be eligible for an allocation from the Recovered IPv4 Pool,
       an RIR must:

       - Have returned addresses to the Recovered IPv4 Pool.
       - Report on the status of its IPv4 address pool as described in
         Section 5.4d below.
       - Have not already received an IPv4 allocation unit from the
         IANA during the current IPv4 allocation period.

    b. In addition, if the RIR is requesting its first allocation from
       the Recovered IPv4 Pool, it must:

       - Have less than a total of /9 in its unallocated IPv4 address

    c. If the RIR is requesting a subsequent allocation from the
       Recovered IPv4 Pool, it must:

       - Have less than 50% of the size of the current IANA IPv4
         allocation unit remaining in its unallocated IPv4 address

    d. RIRs are permitted to reserve up to one /10 of their
       unallocated IPv4 addresses for special purposes (such as
       policies tying IPv4 allocations to IPv6 deployment, or future
       use). Any reservations larger than a /10 will be considered to
       be "unallocated" and part of the RIR's total unallocated IPv4
       address pool.

5.4 Reporting

    a. All allocated space is to be recorded in a publicly available
       IANA-published log of IPv4 address space transactions, with each
       log entry detailing the address blocks, the date of the
       allocation, and the recipient RIR.

    b. The IANA will maintain a public registry of the current
       disposition of all IPv4 address space, detailing all
       reservations and current allocations and current IANA-held
       address space that is unallocated.

    c. The IANA may make public announcements of IPv4 address block
       transactions that occur under this policy. The IANA will make
       appropriate modifications to the "Internet Protocol V4 Address
       Space" page of the IANA website [2] 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.

    d. To be eligible for address allocations, RIRs must report
       monthly, and at least for 3 months prior to any request, all
       address allocations made and the total of its IPv4 address
       holdings and reservations.

6.  Pros/Cons


    - The policy provides a mechanism for the ongoing distribution of
      IPv4 address space, while removing the areas of prop-069 that
      were problematic for the ARIN community, and removing the
      problematic areas of prop-086. That is, 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


    - This proposal is unlikely to finish the global policy development
      process before the IANA pool exhausts. However, the exhaustion of
      the IANA pool is an independent event that will not affect this
      proposal's eventual implementation.

    - This proposal does not provide details of how address space may
      be returned to the IANA IPv4 Recovered Pool. However, since it
      limits the eligibility for addresses from the IPv4 Recovered Pool
      to those who have contributed to it, it will encourage RIRs to
      actively return addresses to IANA.

7.  Effect on APNIC

This policy governs the allocation relationship between the IANA and
the RIRs. It does not imply any change to allocation relationships
between APNIC and its Members.

8.  Effect on NIRs

This policy governs the allocation relationship between the IANA and
the RIRs. It does not imply any change to allocation relationships
between APNIC and the NIRs.

9.  References

[1] "Global Policy for the Allocation of the Remaining IPv4 Address


[2] "IANA IPv4 Address Space Registry", January 2011.


Appendix A

Proposal number given to "Global policy proposal for the allocation of
IPv4 blocks to Regional Internet Registries" in each of the five

AfriNIC:     AFPUB-2009-v4-002
APNIC:       prop-069
ARIN:        ARIN-2009-3
LACNIC:      LAC-2009-01
RIPE:        RIPE 2009-01

Proposal number given to "Global Policy for IPv4 Allocations by the
IANA Post Exhaustion" in each of the five regions:

AfriNIC:     AFPUB-2010-v4-006
APNIC:       prop-086
ARIN:        ARIN-2010-10
LACNIC:      LAC-2010-04
RIPE:        RIPE 2010-05
*              sig-policy:  APNIC SIG on resource management policy
sig-policy mailing list
sig-policy at lists.apnic.net

------ End of Forwarded Message

More information about the ARIN-PPML mailing list