On 16/09/2014, at 9:11 am, HENDERSON MIKE, MR michael.hender...@nzdf.mil.nz
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: sig-policy-boun...@lists.apnic.net
[mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Tomohiro -INSTALLER-
Fujisaki/?? ??
Sent: Monday, 15 September 2014 11:56 a.m.
To: sig-pol...@apnic.net
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
sig-policy@lists.apnic.net
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
sig-policy@lists.apnic.net
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
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy
