The US DOD does not have a /13. I do not know why this myth continues to propagate.
Owen On Sep 15, 2014, at 2:11 PM, 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 > 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] > 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
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list [email protected] http://mailman.apnic.net/mailman/listinfo/sig-policy
