Folks, The optimizations I did for T64 were added to by our team and we as of a previous release are doing DAD for all addresses now as Tim suggests below. What drove us was Mobile IPv6 and folks creating privacy addresses.
/jim > -----Original Message----- > From: Tim Hartrick [mailto:[EMAIL PROTECTED]] > Sent: Thursday, August 15, 2002 2:21 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Cc: Bound, Jim; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Re: DAD vs. DIID > > > > > > 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] --------------------------------------------------------------------
