RE: draft-bourbaki-6man-classless-ipv6-00

["Manfredi, Albert E" <[e-mail]>]

-----Original Message-----
From: ipv6 [mailto:[e-mail]] On Behalf Of Alexandre Petrescu

> So, if that category of problems is not sufficient, a similar
> category of problems is other major IoT or M2M devices that run
> other major OS distribution than smartphones.

Yes, I think this is the broader issue. The cellphone example is an easy way to illustrate the problem, and as far as I can tell, the available solutions treat the lower 64 bits as a flat address space exclusively. Which may be fine for the smartphone hotspot, but hardly fine as a scalable solution.

If nothing else, allowing for 48-bit IIDs should be a no brainer. The collision potential with SLAAC is every bit as low as it was with SLAAC-cum-EUI-64, and *in effect*, such a solution would restore those wasted upper 16 bits of EUI-64 to usefulness. It provides the same benefit as assigning /48s to every customer, but without the egregious waste of address space. And if IIDs get shorter, then DAD will detect collisions more often, but that doesn't have to end up in failure necessarily? Try, try again. Or use DHCP-PD.

I'm not so taken by the privacy benefits of an overly sparsely used block of 64 bits. Other, more address-space-efficient techniques can be used to achieve that goal, like very short address lifetimes.

Anyway, as I see it, such updates can be introduced gracefully, fully backward compatible. A host updated to generate IIDs of various lengths can obviously also generate 64-bit IIDs!

Bert