[sig-policy] prop-091: Limiting of final /8 policy to specific /9

  • To: APNIC Policy SIG List <sig-policy at apnic dot net>
  • Subject: [sig-policy] prop-091: Limiting of final /8 policy to specific /9
  • From: Gaurab Raj Upadhaya <gaurab at lahai dot com>
  • Date: Thu, 20 Jan 2011 08:52:40 +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,
      
      The proposal, 'Limiting of final /8 policy to specific /9', has been
      sent to the Policy SIG for review. It will be presented at the Policy
      SIG at APNIC 31 in Hong Kong, 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?
               - 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-091-v001: Limiting of final /8 policy to specific /9
      _______________________________________________________________________
      
      
      Author:        David Woodgate
      
      Version:       1
      
      Date:          20 January 2011
      
      
      
      1.  Introduction
      - ----------------
      
      This is a proposal to modify the policies for distribution of the
      "final /8" to only apply to a specific /9 block of the final /8, on the
      basis that the current policies would unnecessarily prevent the use of
      over 8 million IPv4 addresses that otherwise should be used to enable
      user connections.
      
      
      2.  Summary of the current problem
      - ----------------------------------
      
      The original final /8 policy proposal assumed that small amounts of
      IPv4 addressing would still be needed for some years into the future to
      successfully operate an Internet business, even with IPv6 use growing
      rapidly in the industry. Therefore, the aim of the final /8 policy was
      to ensure that new ISPs and other businesses would continue to have
      access to IPv4 addresses to initiate their services.
      
      The current final /8 policy [1] allows for one minimum allocation per
      APNIC account holder from the entire final APNIC /8. This results in
      the following potential numbers of allocations:
      
           No. of /22s available from /8:                        16,536
           No. of /22s available from /8 (reserved /16 removed): 16,320
      
      
      This is a large number of potential allocations when compared with
      APNIC's current numbers of account holders and recent annual growth:
      
           No. of APNIC account holders (Aug 2010) [2]:            3,132
           APNIC acount holder growth per annum [3]:          around 320
      
      
      If the APNIC account holder growth rate were to increase up to 480 new
      account holders per year (a 150% increase on the current growth
      rate), it would take over 27 years to make every one of the possible
      16,320 allocations from the final /8 (minus the reserved /16).
      
      It is reasonable to expect that within the next 10 years IPv6 will be
      thoroughly deployed throughout the Internet as the preferred protocol
      and that IPv4 address allocation will no longer be sought. Looking at a
      10-year forecast of annual account holder growth of 480, only a /9
      would be consumed within this timeframe, leaving another /9 never used
      under current final /8 policy.
      
      This would seem to be an undesirable situation for the APNIC community,
      as this unused space could be used to provide IPv4 Internet connections
      to millions of users (whether that be prior to or as part of dual-stack
      IPv6 deployments). The release of these addresses would not be expected
      to make a significant change to the overall IPv4 exhaustion timeframes,
      but it would allow the addresses to be used for their designed purpose
      of enabling user connections.
      
      If the pool reserved for the final /8 allocation policies were to be
      reduced to a /9, it would result in the following potential numbers of
      allocations:
      
           No. of /22s available from /9:                         8,192
           No. of /22s available from /9 (reserved /16 removed):  8,128
      
      
      3.  Situation in other RIRs
      - ---------------------------
      
      AfriNIC:
      
           AfriNIC do not have a confirmed final /8 policy yet, but are
           considering the "IPv4 Soft Landing Proposal". If this proposal is
           adopted, AfriNIC would continue to allocate from their final /8,
           but with greater limitations on allocations particularly for their
           final /11:
      	
      	    http://www.afrinic.net/docs/policies/AFPUB-2010-v4-005.htm
      
      
      ARIN:
      
           Section 4.10, "Dedicated IPv4 block to facilitate IPv6 Deployment",
      	of the ARIN Number Resource Policy Manual, specifies that ARIN will
      	reserve a /10 from their final /8 to facilitate IPv6 deployment.
      	
      	    https://www.arin.net/policy/nrpm.html#four10
      
      LACNIC:
      
           Section 11, "Policies Relating to the Exhaustion of IPv4 Address
      	Space", of the LACNIC Policy Manual specifies that LACNIC will
      	restrict allocations for their final /12:
      	
      	    http://www.lacnic.net/en/politicas/manual11.html
      
      RIPE:
      
           Proposal 2010-02, "Allocations from the last /8", which appears to
           be based on APNIC's current final /8 policy is currently "Awaiting
           Decisions from WG Chairs".
      
               http://www.ripe.net/ripe/policies/proposals/2010-02.html
      
      It therefore appears that most of the RIRs have policies or are
      considering proposals that will reserve blocks that would be smaller
      than the /9 being considered by this proposal. Only RIPE is considering
      a proposal that would duplicate APNIC's current policy for the entire
      final /8.
      
      
      4.  Details
      - -----------
      
      It is proposed that the policy, "Distribution of the final /8 worth of
      space in the unallocated APNIC IPv4 address pool" be adjusted as
      follows:
      
      4.1 The policies be applied to a specific contiguous /8 block received
           from IANA.
      
      4.2 The specific block from IANA be divided into two /9 blocks.
      
      4.3 One of the two /9 blocks will have the following policies applied
           to it:
      
               - The policy for allocations to LIRs currently described in
                 section 9.10.1, "Allocations to LIRs"
               - The policy for reserving a /16 for future use, currently
                 described in section 9.10.2, "Allocations for future uses"
      
      4.4 The other /9 block will be allocated according to current IPv4
           allocation policies, and in particular the policies described by:
      
               - 9.3 Criteria for initial allocation
               - 9.4 Criteria for subsequent allocations
      
      
      5.  Pros/Cons
      - -------------
      
      Advantages:
      
      - - Adoption of this proposal would provide over 8 million additional
         IPv4 addresses for use by the APNIC community for user connections
      
      
      Disadvantages:
      
      - - If there were an unforeseen explosion of APNIC account holders in the
         the near future, there would be a slight risk that new Internet
         businesses might not be able to obtain IPv4 addresses for their
         business before IPv6 were generally deployed. However, historical
         data [2][3][4] indicates that this would seem a very unlikely
         scenario within a 10-year timeframe.
      
      
      6.  Effect on APNIC
      - -------------------
      
      Adoption of this proposal would require APNIC to manage the allocation
      of an additional /9 prior to moving to the "exhaustion phase" of
      allocations. This would be expected to add only a couple of months at
      most of allocations according to current practices, and this extra work
      would be within the standard scope of APNIC's purpose.
      
      
      7.  Effect on NIRs
      - ------------------
      
      There would be no significant impact on NIRs arising from this proposal
      other than the potential allocation of additional IPv4 address space
      to them by APNIC.
      
      
      8.  References
      - --------------
      
      [1] Section 9.10.1, "Allocations to LIRs", in "Policies for IPv4
           address space management in the Asia Pacific region"
           http://www.apnic.net/policy/add-manage-policy#9.10.1
      
      [2] Slide 12, "APNIC Service Levels", APNIC Services Area Report,
           APNIC 30
      	http://meetings.apnic.net/30/Services-Report-Sanjaya.pdf
      	
      [3] Inferred from slide 2, "APNIC Service Levels", APNIC Services Area
           Report, APNIC 29, http://meetings.apnic.net/29/Services-Report.pdf
      	and by comparison with the figures in reference [2]
      
      [4] APNIC Membership graph, page 3, APNIC Annual Report 2009
      	http://www.apnic.net/2009-APNIC-Annual-Report.pdf
      -----BEGIN PGP SIGNATURE-----
      Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
      Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
      
      iEYEARECAAYFAk0399gACgkQSo7fU26F3X1nyACgm0vAMFHNpnJHe3lugy8bydYo
      mvMAn1R2pGGp6nsuwpJaJRT8A0F08oo4
      =3pwv
      -----END PGP SIGNATURE-----