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

[Alexandre Petrescu <[e-mail]>]

Le 11/03/2017 à 13:17, Philip Homburg a écrit :
>> 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?

In order to run SLAAC on links on which a /63 is routed to.

Alex

> 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.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list [e-mail] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>