On Feb 3, 2015, at 8:12 PM, Robert Hudson <hudrob@gmail.com> wrote:

On 4 February 2015 at 14:54, Dean Pemberton <dean@internetnz.net.nz> wrote:

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 I read it...

The proposal addresses only organisations who already have /32 allocations in the legacy IPv6 block (the IP ranges this includes are defined in the proposal).  The allocation policy in the legacy block was effectively to carve out a /29, but then only provide the applicant with a /32 out of this /29 - meaning the gap between the /29 and the /32 remains un-allocated.

That is correct. However, rather than expanding this swamp, I would support issuing additional /28s to these organizations and draining the early allocation swamp through attrition.

Prop-112 simply proposes that the owner of one of these /32 allocations can, if the require it, request to "fill out" the /29 which is allocated to them in the back-end, so that they end up with a contiguous block of IP address space.  It is not possible to stretch this to a nibble boundary (/28), because the next allocation in the legacy IPv6 block could/would overlap this.

Correct, hence my suggestion that they simply be issued new /28s.

The proposal does NOT impact /32 allocations that were made since the newer policy of sparse allocation was introduced.  Those are left to be dealt with under the existing rules.

If the proposal is not accepted, the gap between /32 and /29 is "wasted" for every allocation within the legacy IPv6 block.  This "wastes" 30,064,771,072 /64 networks, unless a policy is proposed and approved to somehow use this address space in another fashion.

Note there are actually multiple blocks as pointed out. Forever is a very long time.

The better solution, which does not waste all of them forever, is to allocate new /28s to those organizations that need more than a /32 ask that they not make any new allocations or assignments within the original /32, and return the /32 when or if they ever vacate it through attrition.

For organizations that are lucky enough to have the correct neighbor vacate their /32, their prefix could, then, be expanded to a /28 without issue.

Even with this policy, most of that space will remain wasted anyway, it will just be wasted in a different place where it can never be used for a different purpose.

I'm happy to be corrected on any of this.  But if my understanding is correct, the benefits of this proposal vastly outweigh any negatives, and I believe SAGE-AU will be supporting it.

They do not, actually. While 30,064,771,072 sounds like a lot of /64s, the simple reality is that when you’re handing them out to end-users 65,536 at a time and to ISPs 4,294,967,296 at a time (minimum), it’s really not so many. When you consider that RIRs are given more than 1024 times that amount of space each time they apply to IANA and that no RIR has even come close to needing a second /12 from IANA so far, I think it is better to hold that particular space in reserve until its current mess is cleaned up through attrition, even if that never happens.

Owen

*              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