Dear all,

Thank you so much for your feedback on prop-112, and I'm sorry for not to reply soon.

Again, main objective of prop-112 is to utilize reserved IPv6 address in 'legacy' block. Legacy blocks are: 2001:0200::/23, 2001:0c00::/23, 2001:0e00::/23 and 2001:4400::/23. Here is current usage information of these blocks.

Block # of /32 # of < /32 Reserved ----------------------------------------------------------- 2001:0200::/23 62 0 84.8% 2001:0c00::/23 56 1 76.6% 2001:0e00::/23 61 1 83.4% 2001:4400::/23 30 5 41.0% (used for /48 assignment etc.)

RIPE-NCC has same kind of legacy blocks and their usage information is:

Block # of /32 # of /29 Reserved ----------------------------------------------------------- 2001:600::/23 46 16 62.9% 2001:800::/23 45 16 61.5% 2001:a00::/23 47 13 64.3% 2001:1400::/23 54 6 73.8% 2001:1600::/23 22 8 30.1% 2001:1a00::/23 50 14 68.4% 2001:4000::/23 53 7 72.5% 2001:4a00::/23 24 8 32.8% 2001:4c00::/23 52 9 71.1%

It looks that RIPE-NCC has utilized reserved address blocks in legacy space. I suppose this is because they have implemented a policy that allow to distribute up to /29 IPv6 address space.

And one point, some legacy space holders in APNIC have obtained larger address blocks than /29.

I think we need to any take action to utilize these reserved space.

-- Tomohiro Fujisaki

From: Masato Yamanishi myamanis@gmail.com Subject: Re: [sig-policy] [New Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space [SECURITY=UNCLASSIFIED] Date: Mon, 23 Feb 2015 12:13:10 -0600

| Dear Colleagues, | | Regarding prop-112, | | 1. Dean Pemberton summarized concerns for this proposal | | http://mailman.apnic.net/mailing-lists/sig-policy/archive/2015/02/msg00020.h... | | 2. Robert Hudson claimed that the benefit (utilizing dead space) is larger | than the concern | | http://mailman.apnic.net/mailing-lists/sig-policy/archive/2015/02/msg00023.h... | | 3. Owen DeLong is against for the benefit he proposed alternative solution | (giving another /28 and wait) | | http://mailman.apnic.net/mailing-lists/sig-policy/archive/2015/02/msg00033.h... | Mike Henderson support this alternative. (I believe, Sanjeev Gupta will | also support, but correct me if different) | | So, I would like to ask your views for following questions. | | Q1. Is the benefit larger than the concern or not? | Q2. Does the alternative solution proposed by Owen resolve this problem | also? | | Tomohiro> Can you express your view as original author for 2nd point? | | Regards, | Masato Yamanishi, Policy SIG Chair (Acting) | | | | 2015-02-04 10:26 GMT-06:00 Owen DeLong owen@delong.com: | | > | > 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 | > | >