(I'm going to concentrate on one specific issue, so I've changed the subject.)
>>>>> On Wed, 2 Jun 2004 08:03:18 +0300 (EEST), >>>>> Pekka Savola <[EMAIL PROTECTED]> said: >> > > What might be useful is specifying with which kind of addresses >> > > oDAD should be assumed: [...] Manual addresses or DHCPv6 in >> > > particular should be disallowed. >> > >> > [...] >> > But is also isn't clear to me that the probability, even in the >> > manual case, is high enough to warrant pessimistic mode. >> >> I (personally) tend to agree, but I (editorially) am trying to steer >> a course between paranoia and recklessness :-) > Sure, but the main concerns about the need for DAD have come from the > manually configured addresses, so with them, we might say for example > that the optimistic mode SHOULD NOT be used, and if it is still > enabled by default, there MUST be a way to disable it (or whatever). > So, if vendors or operators would believe optimistic behaviour for > everything is a good one, they could still go for it, but we might > want to stick to the original DAD plan for those addresses where the > collision probability is not (practically) zero. > I don't feel strongly about this either way, but I think this was an > important argument from those people who were resisting DAD > optimizations in the first place.. I would vote for disabling optimistic DAD for manually configured addresses and addresses assigned via DHCPv6. The main reason is that the default strategy of optimistic DAD should be conservative and very careful not to break anything deployed without the optimistic behavior. I believe this is the basic deal (perhaps implicitly) when we agreed on working on this draft in this wg. It is obvious that the probability of collision among manually configured addresses is higher than that among (e.g.,) EUI-64 based addresses. Regarding addresses assinged by DHCPv6, they can still collide with addresses configured by a different method (typically by manual configuration), as I thought Ralph pointed out. DHCPv6 addresses can even collide each other with misconfiguration. It's true that this is an operational error, but detecting such an error should be one of the main purposes of DAD in the first place. I don't know how high the collision possibility is for these addresses comparing to EUI-64 or randomly generated addresses. But, according to the "conservative" strategy, the appropriate logic I should take is that we do not perform the optimistic behavior for addresses unless we are very sure that the collision probability for these addresses is low as that for EUI-64 or randomly generated addresses (IMO). Besides, if I understand it correctly, the original motivation of optimistic DAD should be helping mobile end devices roam networks as fast as possible. I believe these devices are very unlikely to configure their addresses manually, so disabling the optimistic behavior for manually configured addresses would not decrease the value for the original motivation. (The case of DHCPv6-configured addresses might be controversial in this sense, though.) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------