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

[Fernando Gont <[e-mail]>]

Hi, Ran,

On 09/03/2011 12:51 p.m., RJ Atkinson wrote:
>> 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.

Will clarify this in the next rev of the document.



> 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.

Will do.



> 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.

Will do. And will reference the corresponding RFCs (EUI-64 stuff).

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1