[sig-policy] prop-097-v002: Global Policy for post exhaustion IPv4 alloc

  • To: APNIC Policy SIG List <sig-policy at apnic dot net>
  • Subject: [sig-policy] prop-097-v002: Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA
  • From: Gaurab Raj Upadhaya <gaurab at lahai dot com>
  • Date: Sun, 20 Feb 2011 06:47:53 +0000
  • Delivered-to: sig-policy at mailman dot apnic dot net
  • List-archive: <http://mailman.apnic.net/mailing-lists/sig-policy>
  • List-help: <mailto:sig-policy-request@lists.apnic.net?subject=help>
  • List-id: APNIC SIG on resource management policy <sig-policy.lists.apnic.net>
  • List-post: <mailto:sig-policy@lists.apnic.net>
  • List-subscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=subscribe>
  • List-unsubscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=unsubscribe>
  • User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
    • Hash: SHA1
      
      Dear SIG members,
      
      Version 2 of 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.
      
      Changes in version 2:
      
            - Section 2, "Definitions", which  has been removed and all
              subsequent sections renumbered.
            - A new paragraph has been added to the beginning of section 2
              (previously 3), "Summary of the current problem", to note
              exhaustion of the IANA IPv4 pool has occurred.
            - Section 4.2 (previously 5.2) has been amended to simplify
              process for the allocation of returned IPv4 address space by
              the IANA.
            - Section 5.3 from version one of the proposal has been removed.
            - Section  4.3 (previously 5.4) has been amended to simplify
              reporting requirements.
      
      
      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?
               - Does this proposal solve a problem you are experiencing? If
                 so, tell the community about your situation.
               - 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
                 effective?
      
      
      Information about this and other policy proposals is available from:
      
                 http://www.apnic.net/policy/proposals
      
      
      Gaurab, Ching-Heng, and Terence
      
      
      _______________________________________________________________________
      
      prop-097-v002: Global Policy for post exhaustion IPv4 allocation
                      mechanisms by the IANA
      _______________________________________________________________________
      
      
      Authors:       Alejandro Acosta
                      Nicolas Antoniello
                      S. Moonesamy
                      Douglas Onyango
                      Medel Ramirez
                      Masato Yamanishi
                      Philip Smith
      
      Version:       2
      
      Date:          20 February 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.  Summary of the current problem
      - ----------------------------------
      
      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 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
             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 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
             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 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 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.
      
      
      A problem with prop-069, prop-086, and the first version of prop-097
      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 prop-097 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.  Situation in other RIRs
      - ---------------------------
      
      This proposal will be submitted to all RIRs with a view to becoming
      global policy.
      
      
      4.  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.
      
      4.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.
      
      
      4.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.
      
      
      4.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.
      
      
      5.  Pros/Cons
      - -------------
      
      Advantages:
      
           - 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
      
      
      Disadvantages:
      
           - This proposal does not provide details of how address space may
             be returned to the IANA IPv4 Recovered Pool.
      
      
      6.  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.
      
      
      7.  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.
      
      
      8.  References
      - --------------
      
      [1] "Global Policy for the Allocation of the Remaining IPv4 Address
           Space"
      
           http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm
      
      [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-006
      APNIC:       prop-086
      ARIN:        ARIN-2010-10
      LACNIC:      LAC-2010-04
      RIPE:        RIPE 2010-05
      
      - -- 
      
      http://www.gaurab.org.np/
      
      
      -----BEGIN PGP SIGNATURE-----
      Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
      Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
      
      iEYEARECAAYFAk1guRkACgkQSo7fU26F3X3vXQCfYSFwXwrBUqfty3dgDytJq21B
      vB4AoNUvXA//pw9QhV+FfY27F8JXjvh5
      =Kok0
      -----END PGP SIGNATURE-----