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

[Mark Smith <[e-mail]>]

Hi Ran,

On Wed, 9 Mar 2011 10:51:59 -0500
RJ Atkinson <[e-mail]> 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.