On Sep 3, 2014, at 2:12 PM, Masato Yamanishi <myama...@japan-telecom.com> wrote:
> Hi Mike, > > Thank you for you comment and let me clarify your one point. > > On 2014/09/02 16:07, "HENDERSON MICHAEL, MR" <michael.hender...@nzdf.mil.nz> > wrote: > >> I do not favour IPv6 allocations on “non-nibble” boundaries, I believe that >> allocations ought to be made on “nibble” (i.e. 4-bit) boundaries. On that >> basis, the next allocation larger than /32 would be /28, not /29. >> Address masking and calculation on /29 boundaries will in my view be quite >> nasty, and the size of the IPv6 address space is sufficiently large that we >> need not, and therefore should not, impose such inconveniences on ourselves. >> >> Hence, in my IPv6 allocation world, a resource holder who has a demonstrated >> need (for whatever value of ‘need’ seems appropriate) for address space >> larger than /32, should be allocated a /28. >> If they are ‘growing’ an existing /32, then the new /28 would very >> preferably be one that includes the currently-allocated /28. >> >> >> However, I understand the current situation is that the ‘legacy’ IPv6 >> address allocation was for smaller allocations within blocks on /29 >> boundaries, if I read the Proposition correctly. >> As a special case only, I would support the allocation of these ‘legacy /29’ >> blocks. The provisos being that firstly they do fall into this ‘legacy’ >> category, and that secondly it is not possible (owing to allocation to a >> third party) to allocate a /28 to the relevant resource holder >> >> > > > But this proposal is NOT ONLY for the special case. > Every organizations, which are new comers, “legacy” IPv6 space holder, and > existing IPv6 space holder with sparse allocation mechanism, > will be eligible for /29 by providing necessary information as shown in Sec.4. Which I believe is a flaw in the proposal. > > So, can you share your preference for current proposed text as it is? I do not support the proposal as written. I would support it if /28s were issued whenever possible and /29s were only issued in cases where the existing assignment or allocation cannot be expanded to at least /28. Owen > >> 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. The organizations >> can receive up to /29 by providing utilization information of the whole >> address space. >> >> - 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 by explaining >> how the whole address space will be used. >> > Rgs, > Masato > * 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
