(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
--------------------------------------------------------------------
