Re: 64bit MAC addresses and SLAAC

[Fernando Gont <[e-mail]>]

On 17/6/20 14:52, [e-mail] wrote:
> Fred,
> 
>>>> Fernando, I think an unspoken assumption in these past several messages is that
>>>> privacy is ALWAYS a required property. However, there are cases where address
>>>> privacy is not only not required, but it is also desirable and useful to be able to
>>>> track a node by a stable and unchanging IP address or prefix.
>>>>
>>>> This is not intended to challenge the non-use of MAC addresses in Interface
>>>> Identifiers per your documents, but just to say that in some environments the
>>>> randomization and constant changing of IP addresses may actual run counter to
>>>> operational objectives.
>>>
>>> Implementations and operational deployments or other link-types are of course free to choose whatever recommendation (or none)
>>> for default IID generation.
>>> IID mechanisms are not protocol specifications. They are recommendations taking various parameters into account (stability, tracking
>>> etc).
>>> These are not required for interoperability.
>>> Configure IIDs manually if you like.
>>
>> You seem to be acknowledging my point that privacy is not always a required property,
>> and that in some environments stability, tracking, etc. are desirable. And, for those types
>> of environments, placing a constant-value token somewhere in the address (whether it
>> came from a hardware code, administrative setting or algorithmic generation) should be
>> fine. Did I understand correctly?
> 
> Yes, largely.
> Strictly speaking, standardizing mechanisms for generating IIDs is in the grey area of over-specifying.

In a way, *the RFCs updated by RFC8064* were the ones specifying IID 
generation algorithms. In a way, RFC8064 relaxes such specs, and 
replacing a hard-coded algorithm (embedding MAC addresses) with actual 
requirements for the IIDs, and recommends an algorithm (RFC7217), so 
that you don't need to figure out how to comply to the aforementioned 
requirements by yourself.

-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492