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

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

-----Original Message-----
From: ipv6 [mailto:[e-mail]] On Behalf Of Philip Homburg

> The first interface identifier concept is that for any prefix of
> length n, the length of the interface identifier is 128-n. Let me
> call this prefix-iid.
>
> The second iid concept is in auto configuration of addresses. I'll
> call this slaac-iid.
>
> The way I see it, any slaac-iid that is based on (pseudo)-random
> number has to be at least 64 bits. I don't see any reason for more
> than 64 so exactly 64 sounds about right.

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.

I would stay away, at this point, from any mention of 64 as a constant. We are (I think) beyond that, even for a particular 2000::/3 subset of globally unique unicast addresses.

Secondly, RFC 4862 states:

      Note that a future revision of the address architecture [RFC4291]
      and a future link-type-specific document, which will still be
      consistent with each other, could potentially allow for an
      interface identifier of length other than the value defined in the
      current documents.  Thus, an implementation should not assume a
      particular constant.  Rather, it should expect any lengths of
      interface identifiers. 

Which is where we are today, in fact.

> In theory, a link that has hardware MAC addresses with less than 64
> bits could define a slaac-iid that is shorter, however that precludes
> the use of pseudo-random slaac-iids.

I don't think it does.

Bert