There are a number of things that concern me about this proposal. 1) it doesn't appear to support needs based allocation 2) it doesn't support allocation on nibble boundaries which operators have said repeatedly is a major issue.
As such I do not support this proposal in its current form. On Wednesday, 4 February 2015, HENDERSON MIKE, MR < michael.hender...@nzdf.mil.nz> wrote: > I agree with Owen > > > > > > Regards > > > > > > *Mike* > > > > *From:* sig-policy-boun...@lists.apnic.net > <javascript:_e(%7B%7D,'cvml','sig-policy-boun...@lists.apnic.net');> > [mailto:sig-policy-boun...@lists.apnic.net > <javascript:_e(%7B%7D,'cvml','sig-policy-boun...@lists.apnic.net');>] *On > Behalf Of *Owen DeLong > *Sent:* Wednesday, 4 February 2015 4:05 p.m. > *To:* Masato Yamanishi > *Cc:* sig-policy@lists.apnic.net > <javascript:_e(%7B%7D,'cvml','sig-policy@lists.apnic.net');> > *Subject:* Re: [sig-policy] [New Policy Proposal ] prop-112: On demand > expansion of IPv6 address allocation size in legacy IPv6 space > > > > I will again oppose this as written. I would much rather see policy > deliver nibble-boundary based allocations. > > > > I would rather see such organizations issued new /28s than expand these > /32s into /29s. > > > > Owen > > > > On Feb 3, 2015, at 9:55 AM, Masato Yamanishi <myama...@gmail.com > <javascript:_e(%7B%7D,'cvml','myama...@gmail.com');>> wrote: > > > > Dear SIG members > > The proposal "prop-112: On demand expansion of IPv6 address allocation > size in legacy IPv6 space" has been sent to the Policy SIG for review. > > It will be presented at the Open Policy Meeting at APNIC 39 in Fukuoka, > Japan on Thursday, 5 March 2015. > > 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 proposal is available at: > > http://www.apnic.net/policy/proposals/prop-112 > > Regards > > Masato > > > > > ---------------------------------------------------------------------- > prop-112-v001: On demand expansion of IPv6 address allocation size in > legacy IPv6 space > ---------------------------------------------------------------------- > > > Proposer: Tomohiro Fujisaki > fujis...@syce.net > <javascript:_e(%7B%7D,'cvml','fujis...@syce.net');> > > > 1. Problem statement > -------------------- > > IPv6 minimum allocation size to LIRs is defined as /32 in the "IPv6 > address allocation and assignment policy"[1]. > > In late 2006, sparse address allocation mechanism has implemented > to manage APNIC IPv6 address pool. The block `2400:0000::/12' has > managed with this mechanism. > > Before 2006, /29 was reserved for all /32 allocations by sequential > allocation method made from those old /23 blocks (Legacy IPv6 > block). > > These reserved blocks might be kept unused in the future. > > > 2. Objective of policy change > ----------------------------- > > This proposal modifies the eligibility for organizations in the > legacy IPv6 block to extend their IPv6 address space up to a /29 > (/32 -/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 > --------------------------- > > - define 'legacy IPv6 address blocks' > 2001:0200::/23 > 2001:0c00::/23 > 2001:0e00::/23 > 2001:4400::/23 > > - Add following text in the policy document: > > for Existing IPv6 address space holders > > LIRs that hold one or more IPv6 allocations in the legacy IPv6 > address blocks 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. Advantages / Disadvantages > ----------------------------- > > Advantages: > > It is possible to utilize address blocks which is potentially > unused into the future. > > > Disadvantages: > > Some people may argue this will lead to inefficient utilization of > IPv6 space since LIRs can obtain huge address size unnecessarily. > However, this will not happen because larger address size needs > higher cost to maintain that address block. > > > 6. Impact on resource holders > ----------------------------- > > NIRs must implement this policy if it is implemented by APNIC. > > > 7. References > ------------- > > [1] IPv6 address allocation and assignment policy > http://www.apnic.net/policy/ipv6-address-policy > > * sig-policy: APNIC SIG on resource management policy > * > _______________________________________________ > sig-policy mailing list > sig-policy@lists.apnic.net > <javascript:_e(%7B%7D,'cvml','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. > -- -- Dean Pemberton Technical Policy Advisor InternetNZ +64 21 920 363 (mob) d...@internetnz.net.nz To promote the Internet's benefits and uses, and protect its potential.
* 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
