Search rpd Archives
Limit search to: Subject & Body Subject Author
Sort by:

[AfriNIC-rpd] Policy Proposal "Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA" now Available Online

Mukom Akong T tamon at afrinic.net
Fri May 6 10:59:30 SAST 2011


Dear Colleagues,

The policy proposal "Global Policy for Post Exhaustion IPv4 Allocation 
Mechanisms by the IANA" is now available on our website at 
http://www.afrinic.net/docs/policies/AFPUB-2011-v4-004-draft-01.htm

A text version of the proposal is included below:

Regards

_____

Unique identifier:AFPUB-2011-v4-004-draft-01
Draft Policy Name: Global Policy for Post Exhaustion IPv4 Allocation 
Mechanisms
by the IANA
Authors:        Douglas Onyango    | ondouglas at yahoo.com
                     Alejandro Acosta      | alejandro.acosta at bt.com | 
British Telecom
                     S. Moonesamy    | sm+afrinic at elandsys.com
                     Nicolas Antoniello | nantoniello at gmail.com
                     Medel Ramirez | medel at globetel.com.ph | Globe 
Telecom, Inc
                     Masato Yamanishi | myamanis at bb.softbank.co.jp | 
Softbank BB Corp                     Philip Smith |pfs at cisco.com  | 
Cisco Systems
Draft Version: 01
Submitted:    2011-03-29

1. Summary of the Problem Being Addressed by this Policy Proposal

The IANA has now exhausted its pool of IPv4 /8 blocks, having
distributed its remaining IPv4 addresses according to the "Global
Policy for the Allocation of the Remaining IPv4 Address Space".[1]
However, there is the possibility that IANA will receive returned
addresses post-exhaustion of its pool of /8s.

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 AfriNIC region,
this was AFPUB-2009-v4-002, "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
the ARIN 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 AfriNIC region,
it is AFPUB-2010-v4-003-draft-02. To see the proposal reference number 
for this proposal
in all five RIRs, see Appendix A. However, there are significant issues
with AFPUB-2010-v4-003-draft-02. These are:

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

       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
          managed.

       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 AFPUB-2010-v4-003-draft-02 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
       periods.

         - 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 
AFPUB-2010-v4-003-draft-02, 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 RIRs to take only a certain fraction of the
           IANA pool at each allocation period.


A problem with both AFPUB-2009-v4-002 and AFPUB-2010-v4-003-draft-02 is 
related to the policy for
the return of addresses by the RIRs to IANA:

     - In AFPUB-2009-v4-002, the return of addresses to the reclamation 
pool was
        mandatory. This restriction was of significant concern to the
       ARIN community.

     - In AFPUB-2010-v4-003-draft-02, 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.


2. Summary of How this Proposal Addresses the Problem

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.

- 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.


A problem with AFPUB-2009-v4-002, AFPUB-2010-v4-003-draft-02, and the 
first version of AFPUB-2011-v4-004-draft-01
is that attempts to find ways to make "eligibility" and "exhaustion"
meet the differing needs of all five RIRs caused problems for at least
of the RIRs.

     - To avoid this situation, this second version of 
AFPUB-2011-v4-004-draft-01 invokes
       the precedent of last global policy for IPv4 distribution by the
       IANA[1] to propose an alternative way to distribute space from the
       IANA. That is, that there be an equal distribution of addresses
       between all RIRs.


3. The Proposal

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.

3.1 Recovered IPv4 Pool

     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 stated in Section 4.2 below.


3.2 Allocation of returned IPv4 address space by the IANA

     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.


3.3 Reporting

     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 [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.


4.  Pros/Cons
-------------

Advantages:

     - The policy provides a mechanism for the ongoing distribution of
       IPv4 address space, while removing the areas of AFPUB-2009-v4-002 
that
       were problematic for the ARIN community, and removing the
       problematic areas of AFPUB-2010-v4-003-draft-02. 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


Disadvantages:

     - This proposal does not provide details of how address space may
       be returned to the IANA IPv4 Recovered Pool.


5.  Timetable for implementation
Once consensus has been reached in each of the five RIR regions, the
policy will be forwarded to ICANN for approval and then implemented
by the IANA



6.  References
-----------------------------

6.1. "Global Policy for the Allocation of the Remaining IPv4 Address
     Space"

     http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm

6.2. "IANA IPv4 Address Space Registry", February 2011
     
http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml


Appendix A
-------------------------

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

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-003-draft-02
APNIC:      prop-086
ARIN:        ARIN-2010-10
LACNIC:    LAC-2010-04
RIPE:         RIPE 2010-05


_____

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tamon.vcf
Type: text/x-vcard
Size: 656 bytes
Desc: not available
Url : https://lists.afrinic.net/pipermail/rpd/attachments/20110506/2ca2b7a2/tamon-0001.vcf


More information about the rpd mailing list