[sig-policy] prop-094: Adding alternative criteria to renumbering requir

  • To: APNIC Policy SIG List <sig-policy at apnic dot net>
  • Subject: [sig-policy] prop-094: Adding alternative criteria to renumbering requirement in final /8 policy
  • From: Gaurab Raj Upadhaya <gaurab at lahai dot com>
  • Date: Mon, 24 Jan 2011 20:06:13 +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, 'Adding alternative criteria to renumbering requirement
      in final /8 policy', after IANA exhaustion 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?
              - 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-094-v001: Adding alternative criteria to renumbering requirement in
                      final /8 policy
      ________________________________________________________________________
      
      Authors:       Izumi Okutani
                      Terence Zhang
      
      
      Version:       1
      
      Date:          24 January 2011
      
      
      
      1.  Introduction
      - ----------------
      
      This is a proposal to add an alternative criteria to the requirement for
      organizations receiving their initial allocation from APNIC to renumber
      out of their previously deployed space when they are allocated
      addresses under the final /8 policy [1].
      
      
      
      2.  Summary of the current problem
      - ----------------------------------
      
      Under the current final /8 policy, allocations made to LIRs must meet
      the criteria specified under one of the two following sections of the
      "Policies for IPv4 address space management in the Asia Pacific
      region":
      
           - Section 9.3, Criteria for initial allocation
           - Section 9.4, Criteria for subsequent allocations
      
      One of the criteria for initial allocations is that the LIR:
      
            "commit to renumber from previously deployed space into the new
            address space within one year."
      
      Under current IPv4 allocation policy, that is, before the final /8
      policy is activated, LIRs can receive any sized allocation they are
      able to justify. In the case of initial allocations, for the sake of
      conservation and aggregation, policy requires that any LIR that has
      previously used non-portable IPv4 addresses from their upstream
      provider must agree to renumber out of those addresses and into their
      new portable APNIC allocation within one year. This allowed the LIR
      to maintain the size of its previous non-portable address block plus
      add its next 12 months worth of addressing needs to its new portable
      allocation from APNIC.
      
      However, when we have reached the final /8, the size of allocation will
      be restricted to a single /22. As a result, APNIC will no longer be able
      to consider the loss of address space caused by renumbering, when
      determining the size of an LIR's initial allocation.
      
      As a result, the renumbering requirement for initial allocations will in
      practice result in reclamation of a new LIR's address holding, without
      the ability to sufficiently compensate the LIR with a corresponding
      allocation size.
      
      In such cases, it would be unreasonable to expect these organizations to
      number out of a upstream block into a single /22 from APNIC.
      
      
      3.  Situation in other RIRs
      - ---------------------------
      
      RIPE:
      
           The "Allocations for the last /8" policy does not define additional
           requirements for the renumbering of address space. See Section 5.6,
           "Use of last /8 for PA Allocations," in "IPv4 Address Allocation and
           Assignment Policies for the RIPE NCC Service Region":
      
               http://www.ripe.net/ripe/docs/ripe-509.html
      
      
      There is no similar policy or proposal in the AfriNIC, ARIN or LACNIC
      regions.
      
      
      4.  Details
      - -----------
      
      It is proposed that the final /8 policy be expanded to give
      organizations applying for IPv4 addresses under the initial allocation
      criteria (section 9.3 of the current policy document) the ability to
      choose from:
      
           - The existing criteria:
      
                 Commit to renumber from previously deployed space into the
                 new address space within one year, OR
      
           - A new alternative criteria:
      
                 Demonstrate that the usage rate of previous IPv4 address
                 space holding from their upstream provider(s) reached 80%
      
      
      5.  Pros/Cons
      - -------------
      
      Advantages:
      
           - It will allow new LIRs to receive a /22 under the final /8 policy
             without restricting its total current address holdings.
      
      
      Disadvantages:
      
           - Some people might suggest that increased fraudulent applications
             might result from this proposed policy. However, adding or
             removing the renumbering requirement does NOT increase or
             decrease the possibility of fraud. Fraud is already a potential
             risk in address requests, and it is assumed that APNIC would
             detect and respond to any fraud related to this proposed policy
             in a proper manner.
      
      
      6.  Effect on APNIC
      - -------------------
      
      It will allow APNIC members to receive a /22 allocation under the final
      /8 policy from APNIC without renumbering its current address holdings.
      
      
      8.  Effect on NIRs
      - ------------------
      
      Just as the final /8 policy applies to NIRs, this amendment to the final
      /8 policy would apply to NIRs.
      
      
      9. 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
      -----BEGIN PGP SIGNATURE-----
      Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
      Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
      
      iEYEARECAAYFAk0927UACgkQSo7fU26F3X1obQCgiOIui9d3Q9XqbaGpby4+ehD9
      SZkAoKRleS9tdg/+4QYHGURZnfX+6+4o
      =lMS4
      -----END PGP SIGNATURE-----