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: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
