All,
>
> Ok, first definitions:
>
> - Node A, has "globally unigue" id = AI, implements "link local"
> optimization (does DAD only on fe80::AI).
>
> - Node B is the evil one :-). It has its own "globally unique" id = BI
> for it's link local
>
I agree. Our implementation won't allow an application to assign an address
to an interface which has the the "u" bit set. Not even an application that
has root privileges. Addresses of that form can only be assigned to interfaces
if the id has been derived directly from the EUI-64 of the network interface.
Yes, yes, that can be circumvented by diddling the MAC address of the network
interface but requires more work. We don't allow the fumble fingered
administrator to abscond with someone else's id without putting some effort
into it.
I would say that Node B's implementation is kind of broken.
My general opinion on this topic is that all "statically" configured addresses
should have DAD performed on them. This includes privacy addresses. The
only addresses which don't require DAD are addresses which are derived
directly from an advertised prefix and a real EUI-64 which has been used to
derive a link-local address, which itself has had DAD performed on it.
I have no problem with changing our implementation to do DAD on every
address but I would have some serious reservations about creating and defending
a link-local address associated with every privacy address. That is crazy.
If complexity is the enemy then such a scheme can't be characterized as
anything but an enemy.
tim
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
