On Tue, Nov 21, 2000 at 09:40:42PM +0100, Niels M�ller wrote:
> If also non-anonymous adresses, based on the link-level address, are
> used, som knowledge about the address are leaked.
>
> For instance, consider a link with a few dozen nodes, each of them
> having
>
> (i) a globally unique addess, constructed as prefix + EUI-64,
> (ii) link-level address, also based on the same EUI-64 id,
> (iii) a bunch of anonymous addresses based on, say,
> md5(EUI-64 + small counter), using the same prefix as the global
> address
IF there is *small* counter. Indeed the draft gives me more of
an idea of using some good randomness source, like hosts need to
have against TCP sequence number start spoof attacks anyway.
Algorithm at chapter 3.2.1 seems to have very strong randomness
property, not a trivial counter at all.
Indeed doing pure pick of 8 random bytes, masking some, and doing
DAD driven duplicate avoidance does yield similar result as the
whole complicated scheme of calculating new value from real EUI-64 +
previous (8) history pseudorandom bytes. But being purely random,
they have no relationship with the real EUI-64 at the machine.
For second and third reasons mentioned at chapter 4, I still prefer
DHCP approach. ISC's DHCP does fluently issue (IPv4) addresses out
of pool to machines: first come, first free issued.
The only problem at the DHCP approach is that it doesn't support
time variability of the address in gracefull manner.
... but that is developeable, perhaps as an extension.
(chapter 6 mentions this issue also.)
The DHCP does give traceability for local network administrators
(presuming it is used -- not an absolute requirement, after all),
while external people have no clue as to who is where when.
The "blame-traceability" is important thing to many network admins,
anonymization should not make that too difficult.
(A thing analogous to 'arpwatch' can handle Layer2/Layer3 binding
tracking for IPv6, but it mandates a set of machines not otherwise
needed.)
> You probably also don't want to assume that the "arbitrary remote
> peer" isn't cooperating with other less arbitrary and more determined
> peers.
If the badies are at your local L2 network, you have been had
anyway... Your privacy, at least, possibly also your data.
> /Niels
/Matti Aarnio
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
