Waste will kill ipv6 too

Thomas Bellman bellman at nsc.liu.se
Thu Dec 28 22:31:25 CST 2017


On 2017-12-28 22:31, Owen DeLong wrote:

> Sure, but that’s intended in the design of IPv6. There’s really no need
> to think beyond 2^64 because the intent is that a /64 is a single subnet
> no matter how many or how few machines you want to put on it.

> Before anyone rolls out the argument about the waste of a /64 for a point
> to point link with two hosts on it, please consider that the relative
> difference in waste between a /64 with 10,000 hosts on it and a /64 with
> 2 hosts on it is less than the rounding error in claiming that a /64 is
> roughly 18 quintillion addresses. In fact, it’s orders of magnitude less.

[...]

> We may, someday, wish we had gone to some value of N larger than 128,
> but I seriously doubt it will occur in my lifetime.

My problem with the IPv6 addressing scheme is not the waste of 64 bits
for the interface identifier, but the lack of bits for the subnet id.
16 bits (as you normally get a /48) is not much for a semi-large organi-
zation, and will force many to have a dense address plan, handing out
just one or a few subnets at a time, resulting in a patch-work of
allocations.  24 bits for subnet id would be more usable.

Consider e.g. a university or company campus.  There are probably at
least 16 departments, so I would like to use 8 bits as department id.
Several departments are likely to have offices on more than one floor,
or in more than one building, so I would like to let them have 4 bits
to specify location, and then 8 bits to specify office/workplace within
each location.  And allow them to hand out 16 subnets per workplace.
That adds up to 24 bits.  So a /40 would be nice, not a /48.

Similarly, an ISP that wants a structured address plan, e.g. to encode
prefecture, city and part of city in the address, will quickly use up
bits in the customer id part of the address.


	/Bellman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20171228/b07b96f4/attachment.sig>


More information about the NANOG mailing list