5. Explain the advantages of the proposal
-----------------------------------------
- It will be possible for LIRs to control traffic easier.
I think most of LIRs control traffic for present initial allocation .
- It is possible to use current reserved blocks efficiently.
True .
6. Explain the disadvantages of the proposal
--------------------------------------------
Some people may argue this will lead to inefficient utilization of
IPv6 space. However, the space up to /29 is reserved by APNIC
secretariat for each /32 allocation.
True, specially for development phases . By considering justification might
be encourage the efficient utilization but organization miss the
opportunity of initial IPv6 allocation up to a /29 by request basis.
On Sun, Jan 26, 2014 at 1:38 PM, Aftab Siddiqui <[email protected]>wrote:
>
>
> 5. Explain the advantages of the proposal
> -----------------------------------------
>
> - It will be possible for LIRs to control traffic easier.
> And I guess traffic is under control with existing minimum initial
> allocation.
>
> - It is possible to use current reserved blocks efficiently.
> The idea is to use the allocated block (no matter how big or small it is)
> efficiently.
>
>
> 6. Explain the disadvantages of the proposal
> --------------------------------------------
>
> Some people may argue this will lead to inefficient utilization of
> IPv6 space. However, the space up to /29 is reserved by APNIC
> secretariat for each /32 allocation.
>
> No, the argument is nothing is broken here to be fixed. Option is already
> there to request for larger then minimum initial allocation with proper
> justification. If the need is there to have larger address block then
> justification won't be an issue. The only purpose this policy serve is
> remove the "Justification" portion.
>
> Regards,
>
> Aftab A. Siddiqui
>
>
> On Sun, Jan 26, 2014 at 6:22 AM, Andy Linton <[email protected]> wrote:
>
>> Dear SIG members
>>
>> The proposal "prop-111-v001: Request-based expansion of IPv6 default
>> allocation size" has been sent to the Policy SIG for review. It will be
>> presented at the Policy SIG at APNIC 37 in Petaling Jaya, Malaysia, on
>> Thursday, 27 February 2014.
>>
>> 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 policy proposals is available from:
>>
>> http://www.apnic.net/policy/proposals/111
>>
>> Andy, Masato
>>
>> ----------------------------------------------------------------------
>> prop-111-v001: Request-based expansion of IPv6 default allocation size
>> ----------------------------------------------------------------------
>>
>> Author: Tomohiro Fujisaki
>> [email protected]
>>
>>
>> 1. Problem statement
>> --------------------
>>
>> Currently, IPv6 minimum allocation size to LIRs is defined as /32 in
>> the "IPv6 address allocation and assignment policy", while APNIC
>> currently reserves up to /29 for each /32 allocation. It's better to
>> expand this minimum allocation size up to /29 since:
>>
>> - For traffic control purpose, some LIRs announce address blocks
>> longer than /32 (e.g. /35). However, some ISPs set filters to block
>> address size longer than /32. If LIRs have multiple /32, they can
>> announce these blocks and its reachability will be better than
>> longer prefix.
>>
>> - If an LIR needs address blocks larger than /32, LIRs may tend to
>> announce as a single prefix if a /29 is allocated initially at
>> once. i.e., total number of announced prefixes in case 1 may be
>> smaller than in case 2.
>>
>> case 1:
>> The LIR obtains /29 at the beginning of IPv6 network construction.
>>
>> case 2:
>> The LIR obtains /32, and /31, /30 additionally with the subsequent
>> allocation mechanism.
>>
>> - Before sparse allocation mechanism implemented in late 2008, /29
>> was reserved for all /32 holders by sequence allocation mechanism
>> in the early years. It is possible to use these reserved
>> blocks efficiently with this modification.
>>
>>
>> 2. Objective of policy change
>> -----------------------------
>>
>> This proposal modifies the eligibility for an organization to receive
>> an initial IPv6 allocation up to a /29 by request basis.
>>
>>
>> 3. Situation in other regions
>> -----------------------------
>>
>> RIPE-NCC:
>> The policy "Extension of IPv6 /32 to /29 on a per-allocation vs
>> per-LIR basis" is adopted in RIPE-NCC and LIRs in RIPE region can get
>> up to /29 by default.
>>
>>
>> 4. Proposed policy solution
>> ----------------------------
>>
>> - Change the text to "5.2.2 Minimum initial allocation size" of
>> current policy document as below:
>>
>> Organizations that meet the initial allocation criteria are
>> eligible to receive an initial allocation of /32. For allocations
>> up to /29 no additional documentation is necessary.
>>
>> - Add following text in the policy document:
>>
>> for Existing IPv6 address space holders
>>
>> LIRs that hold one or more IPv6 allocations are able to request
>> extension of each of these allocations up to a /29 without meeting
>> the utilization rate for subsequent allocation and providing
>> further documentation.
>>
>>
>> 5. Explain the advantages of the proposal
>> -----------------------------------------
>>
>> - It will be possible for LIRs to control traffic easier.
>> - It is possible to use current reserved blocks efficiently.
>>
>>
>> 6. Explain the disadvantages of the proposal
>> --------------------------------------------
>>
>> Some people may argue this will lead to inefficient utilization of
>> IPv6 space. However, the space up to /29 is reserved by APNIC
>> secretariat for each /32 allocation.
>>
>>
>> 7. Impact on resource holders
>> -----------------------------
>> NIRs must implement this policy if it is implemented by APNIC.
>>
>>
>> * sig-policy: APNIC SIG on resource management policy
>> *
>> _______________________________________________
>> sig-policy mailing list
>> [email protected]
>> http://mailman.apnic.net/mailman/listinfo/sig-policy
>>
>>
>
> * sig-policy: APNIC SIG on resource management policy
> *
> _______________________________________________
> sig-policy mailing list
> [email protected]
> http://mailman.apnic.net/mailman/listinfo/sig-policy
>
>
--
Regards // Jahangir
* sig-policy: APNIC SIG on resource management policy *
_______________________________________________
sig-policy mailing list
[email protected]
http://mailman.apnic.net/mailman/listinfo/sig-policy
