Re: draft-gont-6man-managing-privacy-extensions-00.txt

[RJ Atkinson <[e-mail]>]

On 09  Mar 2011, at 09:57 , Mikael Abrahamsson wrote:
> Privacy Extensions is not the only mechanisms that might create an
> address to be used, thus I think the "disable privacy" flag is meaningless.
> 
> If you want to know the mac address of the computer who used an
> IP address at a certain time, then you need to tell the host
> to only use EUI64 based address and nothing else, you don't tell it
> to disable privacy extensions.
> 
> Just because privacy extensions is the only address widely seen
> today as being non-EUI64, doesn't mean that if you disable privacy,
> you get only single EUI64.

The above is a very helpful clarification.  

Based on that, I agree with Mikael that the correct semantic 
to the flag should be to require direct/embedded use of a 
hardware MAC value for the IPv6 IID.  That would disallow 
not only the (pseudo-)Privacy addresses, but any other kind 
of addressing that would not embed a hardware address in the IID.



REQUEST for Fernando G/Ron B:
	Separately, keeping the quoted comments above in mind, the I-D
	draft-gont-6man-managing-privacy-extensions needs clarification 
	edits to avoid using the phrase "hardware-derived" anywhere.

REASON:
	Any (pseudo-) Privacy address is derived ("computed") using the 
	MAC address as a seed (at least originally). [RFC-3041, Seection 3.2]

	So it is confusing and not clear to say "hardware-derived",
	when one means that the system ought to only use IIDs that
	are embedded IEEE MAC addresses (whether 802, Firewire, or BlueTooth)
	or some other embedded hardware address type.


Cheers,

Ran