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> 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 > <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 <mailto: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 > <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 > 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
