Sorry to respond to my own e-mail. But I wanted to clarify one thing. Manual recovery is fixing the problem, like reconfiguring the address.

The recovery that optimistic DAD provides is however different. It
just corrects a temporary disruption that the optimistic assumption
may have caused. Whether you have DAD or optimistic DAD running at
the bottom is insignificant to the network manager, iff optimistic DAD
detects collisions reliably.

Jari Arkko wrote:
Francis Dupont wrote:

In your previous mail you wrote:

> => in the real world this kind of problem cannot be corrected...
> The only thing you can do is to avoid to reproduce the same error again.
Was there a specific non-recoverable scenario you had in mind there?
=> just ask large network managers. Address duplication is a real
nightmare to fix in the real world.


Sure. But aren't you assuming that they have to go in and manually
recover? I believe what the optimistic or optimized DAD
folks intend to do is to provide a *protocol* that allows both
(a) faster operation and (b) recovery if a collision happens.

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.

Note: In some cases the collisions is due to L2 address collision,
which I agree is quite troublesome. But optimistic DAD does not
appear to change anything with regards to this. If you get a collision
then you detect that with optimistic DAD as well, and then follow
2462bis rules to disable the interface, or whatever that was required.
And in many cases the address collision is not based on L2.

--Jari


-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------




-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------

Reply via email to