On 16/09/2014, at 9:11 am, HENDERSON MIKE, MR <[email protected]> wrote:
> 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 To the left of the mask or to the right? > 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 This sounds like double counting to me. We are already talking about giving home users a /56 and ISPs a /19 or more and I thought the point of that was that the light bulbs in my house are going to be addressed from my home /56 and my car will get its addresses from the ISP /19. So I don't see why the IoT means one big contiguous address block for all the things from one manufacturer? > 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'. 2^20 is 1,048,576 to the left and 17,592,186,044,416 to the right 2^13 is 8192 to the left and 9,007,199,254,740,992 to the right. (using only 64 bits) Does anyone honestly believe that in the next say 50 years we will have less than 1,048,576 organisations who might have ambitions one day to have a /20 or less than 8,192 who think they are as big and important as the US DoD? (Ignoring the fact that the number of /20s will be less than that given the larger allocations made). cheers Jay > > > 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] > 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 -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list [email protected] http://mailman.apnic.net/mailman/listinfo/sig-policy
