Hi Mike, Thank you for your comments!
| 1) we are still "thinking small", a mind-set caused by the scarcity | of IPv4 address space I think 'needs based' allocation is important. | 3) we are forgetting the historical precedent: the Australian | Defence Force was allocated a /20 by APNIC in 2007, and the US | Department of Defense already has a /13. So we have at least one | organisation in APNIC who already thinks that a /20 is 'just right' | rather than 'too huge'. They got those address blocks by showing their needs for that space. That means they met HD-Ratio based allocation criteria at that point, I believe. | 2) we are not considering use cases in the so-called "Internet of | Things" where there may be requirements for support of huge client | address spaces. As a mind experiment, imagine that one day in the | not too distant future Toyota will want a /60 or even a /56 for | every vehicle they manufacture. At their current rat of production, | close to 10 Million vehicles a year, they will need huge allocation | rather quickly, and of course so will all the other vehicle | manufacturers Yes, we should consider these kind of 'new address usage', and adjust address distribution policy for those purpose. My current proposal does not take into account that kind of usage. Then, IMHO, above Toyota case might be possible to get suitable huge IPv6 address space even under current IPv6 policy, if network connection will be provided by one service provider. Yours Sincerely, -- Tomohiro Fujisaki From: "HENDERSON MIKE, MR" <[email protected]> Subject: Re: [sig-policy] New version of prop-111: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED) Date: Mon, 15 Sep 2014 21:11:34 +0000 | I do not agree with the contention that allocations larger than /28 - e.g. /24 , /20 - will be "too huge". | | | | In my view there are three factors in play here: | | 1) we are still "thinking small", a mind-set caused by the scarcity of IPv4 address space | | 2) we are not considering use cases in the so-called "Internet of Things" where there may be requirements for support of huge client address spaces. As a mind experiment, imagine that one day in the not too distant future Toyota will want a /60 or even a /56 for every vehicle they manufacture. At their current rat of production, close to 10 Million vehicles a year, they will need huge allocation rather quickly, and of course so will all the other vehicle manufacturers | | 3) we are forgetting the historical precedent: the Australian Defence Force was allocated a /20 by APNIC in 2007, and the US Department of Defense already has a /13. So we have at least one organisation in APNIC who already thinks that a /20 is 'just right' rather than 'too huge'. | | | | | | Regards | | | | | | Mike | | | | -----Original Message----- | From: [email protected] [mailto:[email protected]] On Behalf Of Tomohiro -INSTALLER- Fujisaki/?? ?? | Sent: Monday, 15 September 2014 11:56 a.m. | To: [email protected] | Subject: [sig-policy] New version of prop-111: Request-based expansion of IPv6 default allocation size | | | | Hi all, | | | | Thank you again for your comments to prop-111. | | | | I got several comments for nibble boundary allocation. I think /28 might be OK, but additional allocation after /28 will be too huge with this allocation scheme (that will be /24, /20, ...). | | | | Here is current summary of nibble boundary allocation. I would appreciate your additional opinions. | | | | Advantages: | | - ease of address masking and calculation | | - ease of DNS reverse delegation set up | | | | Disadvantages: | | - LIRs in legacy space cannot extend prefix to /28 | | - allocation size will be too huge (allocations after /28 will be /24, /20..) | | | | Yours Sincerely, | | -- | | Tomohiro Fujisaki | | * sig-policy: APNIC SIG on resource management policy * | | _______________________________________________ | | sig-policy mailing list | | [email protected]<mailto:[email protected]> | | 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. * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list [email protected] http://mailman.apnic.net/mailman/listinfo/sig-policy
