Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis

[Philip Homburg <[e-mail]>]

> If you want random, a PRNG can create any length of IID. A 48-bit
> IID would be just as reasonable, and it could be formed from a
> randomly changing link layer address.

The way I see it is that for pseudo-random IIDs we should set the minimum
length such that statistically a collision between addresses never happens.
Obviously collossions will happend due to implementation errors, but I
think the abstract model should have an extremely low chance of collossions,
ever.

It is easy enough to argue that 64 bits is enough. It is also easy enough
to argue that 32 bits is not enough. Would 48 bits work? That's a matter
of estimating how big the IPv6 network will grow. 

Another way of looking at this, why would we need IIDs that are less than
64 bits? The current IPv6 address architecture has no problems supporting
64 bit IIDs. There doesn't seem to be any technical reason to risk a higher
chance of collissions by lowering the number of bits.

Instead, the argument used for those is that some operators did something
stupid and assign only a single /64 to a collection of links. This,
despite all efforts initially to make sure that /48s were assigned. 

So it is reasonable to assume that if we would fully support /80 prefixes
in SLAAC, that some operators would again not read/understand our address
architecture and just assign a single /80 and we a back to square one.

So modifying hosts to generate IIDs smaller than 64 bits would have benefits
in the short run, but it the long run trades an increase in risk of
collission for no benefit at all.