Hi Jahangir, Thank you for your comments.
From: Jahangir Hossain <jrjahan...@gmail.com> Subject: Re: [sig-policy] prop-111-v001: Request-based expansion of IPv6 default allocation size Date: Mon, 27 Jan 2014 01:23:23 +0600 | 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 . In the global routing table, we find some /35, and some of them may be used for traffic control purpose. Prefixes longer than /32 are possibly filtered, since IPv6 minimum allocation size is /32. Yours Sincerely, -- Tomohiro Fujisaki From: Jahangir Hossain <jrjahan...@gmail.com> Subject: Re: [sig-policy] prop-111-v001: Request-based expansion of IPv6 default allocation size Date: Mon, 27 Jan 2014 01:23:23 +0600 | 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 <aftab.siddi...@gmail.com>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 <a...@lpnz.org> 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 | >> fujis...@syce.net | >> | >> | >> 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 | >> sig-policy@lists.apnic.net | >> http://mailman.apnic.net/mailman/listinfo/sig-policy | >> | >> | > | > * sig-policy: APNIC SIG on resource management policy | > * | > _______________________________________________ | > sig-policy mailing list | > sig-policy@lists.apnic.net | > http://mailman.apnic.net/mailman/listinfo/sig-policy | > | > | | | -- | Regards // Jahangir * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
