Hi all, I'm sorry but I've been reading the mail from top of my mailbox.
Thank you again, for your valuable comments. | My position is exactly aligned with Owen's: | "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." I understand this might be one option, but I think this is not fair for many LIRs who has been tackling IPv6 from the early stage. Yours Sincerely, -- Tomohiro Fujisaki From: "HENDERSON MIKE, MR" <michael.hender...@nzdf.mil.nz> Subject: Re: [sig-policy] New version of prop-111: Request-based expansion of IPv6 default allocation size [SECURITY=UNCLASSIFIED] Date: Wed, 3 Sep 2014 22:00:20 +0000 | Masato, | | My position is exactly aligned with Owen's: | "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." | | | Regards | | | Mike | | From: Owen DeLong [mailto:o...@delong.com] | Sent: Thursday, 4 September 2014 9:27 a.m. | To: Masato Yamanishi | Cc: HENDERSON MIKE, MR; sig-pol...@apnic.net | Subject: Re: [sig-policy] New version of prop-111: Request-based expansion of IPv6 default allocation size [SECURITY=UNCLASSIFIED] | | On Sep 3, 2014, at 2:12 PM, Masato Yamanishi <myama...@japan-telecom.com<mailto: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<mailto: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<mailto:sig-policy@lists.apnic.net> | http://mailman.apnic.net/mailman/listinfo/sig-policy | | | The information contained in this Internet Email message is intended | for the addressee only and may contain privileged information, but not | necessarily the official views or opinions of the New Zealand Defence Force. | If you are not the intended recipient you must not use, disclose, copy or | distribute this message or the information in it. | | If you have received this message in error, please Email or telephone | the sender immediately. * 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
