Hi Ran, On Wed, 9 Mar 2011 10:51:59 -0500 RJ Atkinson <rja.li...@gmail.com> wrote:
> > 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. > That may have unintended consequences. If a hardware address isn't available, IIDs can be generated randomly, so if this flag was properly obeyed, these random IID end-nodes should not acquire addresses. An example of where this might matter is on a large scale PPP deployment. If an ISP switched this flag on in the RAs it sends over PPP sessions on the BRAS, and the CPE PPP implementations did not use hardware derived IIDs (i.e. sourced from another interfaces), the PPP session may not come up. Another property of IPV6CP is to negotiate IIDs, to overcome collisions if they occur. On a BRAS, the scope of the collision detection may not only be within a single PPP session, but across all of them, which may number in the 10s of 1000s. Taking a step back, I'm wondering what the actual problem with privacy addresses is - neither of the drafts have specifically said. Is it that they're a random, non-hardware derived IID, or is it that they're random, non-hardware derived IID and that they change over time? If hardware derived IIDs are enforced, there aren't any guarantees that the underlying hardware address isn't random either, or won't be made so intentionally by somebody who wants to preserve their network layer anonimity. Temporarily changing MAC addresses on Ethernet cards is easy if you've got admin access to an OS (or at least, on Windows and Linux it is, not sure about Mac OS X). Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
