Re: Last Call: <draft-ietf-6man-rfc4941bis-10.txt> (Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6) to Proposed Standard

[Brian E Carpenter <[e-mail]>]

On 11-Sep-20 01:24, Fernando Gont wrote:
...
>> 2. I think the text mentioning shorter IID lengths (3.3.1 bullet #2) is 
>> not useful to implementers, because all it says is that it is possible 
>> to implement a behaviour that for in all practical cases is forbidden by 
>> RFC 4291.
> 
> Just double-checking: Are you arguing that this:
> 
> "         We note that [RFC4291] requires that the Interface IDs of all
>            unicast addresses (except those that start with the binary
>            value 000) be 64 bits long.  However, the method discussed in
>            this document could be employed for generating Interface IDs
>            of any arbitrary length, albeit at the expense of reduced
>            entropy (when employing Interface IDs smaller than 64 bits)
>            and increased likelihood of collision.  The privacy
>            implications of the IID length are discussed in [RFC7421]."
> 
> should be removed?

It emphatically should not be removed. It's been a matter of principle
since the earliest work on IPv6 address allocation that the /64
boundary is treated like a parameter that could be changed, so
underlying code should treat it as a parameter and not as a constant.
(And RFC7421 discusses a lot more than just the privacy implications.)

So this is very important information for implementers.

   Brian