Re: [sig-policy] prop-094: Adding alternative criteria to renumbering re
It seems unreasonable to cap the amount of space one can get AND require them
to renumber out of their existing space at the same time.
I believe this policy corrects what is likely an unintended consequence of the
confluence of the two existing policies.
Owen
On Jan 24, 2011, at 12:06 PM, Gaurab Raj Upadhaya wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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-----
> * sig-policy: APNIC SIG on resource management policy *
> _______________________________________________
> sig-policy mailing list
> sig-policy at lists dot apnic dot net
> http://mailman.apnic.net/mailman/listinfo/sig-policy