On 14/01/2017 16:06, John C Klensin wrote:
>
>
> --On Friday, January 13, 2017 16:40 +0900 Lorenzo Colitti
> <lorenzo@xxxxxxxxxx> wrote:
>
>> But it's true that supporting /65-/126 increases the cost of
>> the device. The extra bits have to go somewhere. I think I've
>> seen hardware that just converted all prefixes to 128 bit if
>> there was at least one /65 - /126 prefix in the FIB. That
>> costs money for RAM. Obviously that's silly if those prefixes
>> are frequent, and you can save that money using better
>> software engineering - but software engineering costs money
>> too. Prefixes don't cost money, and if we know that we won't
>> run out of them, what's the problem?
>
> Because you can pick the scenario -- lots of "things", an
> interplanetary network, both, or something else-- but we have
> been here before. Every time someone has said "there is so
> much address space that we will never run out no matter how
> inefficiently we use them", they have eventually been proven
> wrong. That history is obviously not just with the
> ARPANET/Internet or even computer networks: "if we know we won't
> ever run out of them" has a nasty tendency to prove that we
> didn't know and didn't get it right.
Which is exactly why we have so far only delegated 1/8 of the
IPv6 address space for global unicast allocation, leaving a *lot*
of space for fixing our mistakes. Moving away from /64 as the
recommended subnet size might, or might not, prove to be necessary in
the long term future. That's why the point about routing being
classless is fundamental. I do think we need to be a bit more
precise on this point in 4291bis.
Brian