On 2004-02-27, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote: > "Nick 'Sharkey' Moore" <[EMAIL PROTECTED]> said: > > > > * DIID offers less signalling. What advantages does DAD offer? > > An obvious advantage is less probability of (missing) duplication (as > was pointed out even in this thread several times).
... if you're testing multiple addresses with the same suffix, there'll be more chance of collision with another node using the same suffix, true. But it'd be more elegant to increase DupAddrTransmits if that were your aim. And SEND-CGA nodes will configure different suffixes per prefix: odds are, only one will collide. But honestly, I don't really want to reopen the DAD vs DIID debate either. I'm happy to do DAD. I'd be happier if it was interoperable with DIID, because of the installed base. > A supplemental advantage would be simplicity and clarity in the > specification (and probably in implementations). I know this kind of > argument is more or less subjective and may not be convincing though. It's pretty close to convincing me -- the concept of an Interface Identifier is unnecessary and can be done without, so I 'like' DAD better. > Honestly speaking, I don't see the need for making DAD "compatible" > with DIID in the first place. Recall that DAD is not "compatible" > with DIID in this sense, even with the current RFC2462. There is not currently a true DAD vs. DIID division. 2462 specifies that nodes SHOULD test all addresses, and they MUST test the LL. That bit is written on the assumption that all suffixes will be the same -- otherwise it is meaningless. All I'm proposing (see my previous post with the very short bit of suggested text) is to clarify the rules for the post-IID era, with a check for the link-local to maintain compatibility with 2462-compliant nodes *whether they check all addresses or just the LL*. > Meanwhile, even DAD is not perfect in that we can still miss > duplication due to a timing problem or packet loss. Even if we > introduce some new effort to make DAD compatible with DIID, it will > not be perfect either. True, true, I suggest increasing DupAddrTransmits in Optimistic DAD for this reason. > I thus conclude that we don't need a change, at least in rfc2462bis, > to make DAD compatible with DIID. > > Again, my plan is simple. > > - just say "MUST do DAD for all unicast addresses" (or SHOULD if we > need a wording compromise) in rfc2462bis. I'm happy with MUST. > - this does not make the current status worse in the sense of > "compatibility" with DIID, since there are already always-DAD nodes. see above. If I haven't explained myself properly, just let me know. Again, this is only an individual opinion that backwards compatibility in this case is acheivable and important. Anyway, see you all in Seoul, -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
