In your previous mail you wrote:
> => what we need is collision avoidance, no collision detection after
> damage.
Here I have a slightly different opinion. There are two questions:
do we want avoidance or detection, and whether optimistic DAD
implies "possible problems". Regarding the first question, I think
what we can achieve depends on how the address is assigned, random/
eui/conf. Generally, for the last two we can only provide detection
and then wait for further input from the user; for the first we can
still continue and use another address. But this has little to
do with regular or optimistic DAD, both provide detection as the
name implies.
=> I have a different conclusion from your argument: detection is enough
when the recovery is always easy and without drawback, i.e., only
in the first assignment method (random). With other methods (eui/conf),
a collision is a major problem so it is important to avoid it and
not only to detect it.
Regarding the second question, I do not agree that an optimistic
DAD implies problems. It seems reasonable that an optimized
variant would detect duplicates with an equivalent reliability as
regular DAD; both send similar messages and expect other nodes to
answer. Would you agree?
=> yes but my argument is that detection is not enough.
But perhaps you are worried about the
possible temporary disruptions to ongoing traffic?
=> yes.
Is that your concern?
=> no only because one of the two collided systems should loose its
address.
I looked at Nick's draft, and did not find it alarming
myself. But others may have a different opinion. Let me ask you
this: if it was shown that a particular optimistic DAD protocol
did not have even temporary disruptions, would you still think
it implies "possible problems"?
=> read my answer to the next comment.
> I am unable to say for sure if, say, draft-moore, accomplishes this goal.
> It probably needs more analysis before we can be certain. However,
> I do not see any obvious problems.
>
> => the problem is the goal of optimistic/optimized DAD has no interest.
I'm not sure I can parse what you are saying.
=> easy: the optimistic/optimized DAD stuff solves the wrong problem.
There seems to be some
people who do have an interest in quick startup & movement times.
=> in this case they should use dedicated links where DAD is disabled,
RAs are used at a silly high rate, etc.
I agree that DAD is not the only issue to look at here -- I once
calculated the number of messages that were required on a wireless
LAN for L2 & L3 network attachment if you needed access control, link layer
security, mobility, and so on. That number was pretty high, over a
dozen even in the most optimistic scenario, significantly worse in
others. And then there were multiple delay periods, all contributing
to the overall delay. DAD is one of these delay periods.
=> so you should agree that dedicated links are a good solution,
and no DAD is a part of the specific tuning.
Regards
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
