[sig-policy] prop-094-v002: Removing renumbering requirement from final

  • To: APNIC Policy SIG List <sig-policy at apnic dot net>
  • Subject: [sig-policy] prop-094-v002: Removing renumbering requirement from final /8 policy
  • From: Gaurab Raj Upadhaya <gaurab at lahai dot com>
  • Date: Tue, 01 Mar 2011 04:07:04 +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
      
      Below is an updated version of the proposal that includes elements
      changed during the APNIC 31 Policy SIG meeting.
      
      The following changes were made:
      
             - The name of the proposal was updated to more accurately
               reflect the changed details
      
             - Section 4 was changed to propose that criteria 'd' of section
               9.3 be removed once we move into the final /9 phase of
               allocation.
      
      The proposal's history can be found at:
      
            http://www.apnic.net/policy/proposals/prop-094
      
      This proposal reached consensus at the Policy SIG meeting during the
      Policy SIG at APNIC 31 in Hong Kong SAR, China, 21-25 February 2011.
      
      It will be presented to the Policy SIG mailing list soon for a formal
      eight-week final call for comments.
      
      Gaurab, Terence, and Andy
      
      
      ________________________________________________________________________
      
      prop-094-v002: Removing renumbering requirement from final /8 policy
      ________________________________________________________________________
      
      Authors:       Izumi Okutani
                      Terence Zhang Yinghao
      
      
      Version:       2
      
      Date:          24 February 2011
      
      
      
      1.  Introduction
      - - - ----------------
      
      This is a proposal to remove 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 once APNIC starts allocations under the final /8
      policy(*1), initial allocation criteria be changed to remove the
      requirement to renumber from previously deployed space.
      
      Specifically, section 9.3(*2) should be adjusted with a clause that
      criteria (d) "Commit to renumber from previously deployed space into the
      new address space within one year" be removed once we apply the final /8
      policy(*1).
      
        (*1) section "9.10 Distribution of the final /8 worth of space in the
             unallocated APNIC IPv4 address pool" under the current document
             http://www.apnic.net/policy/add-manage-policy#9.10
      
        (*2) defined in section "9.3 Criteria for initial allocation" of the
             current policy document
             http://www.apnic.net/policy/add-manage-policy#9.3
      
      
      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/
      
      iEYEARECAAYFAk1scOgACgkQSo7fU26F3X1P5ACgxhH7kzaJo7zNOdWOQq7Sleqt
      TUYAmwTYA5+EbA8YEzKFoy0VStxvazZP
      =28Lz
      -----END PGP SIGNATURE-----