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