> Sure. But aren't you assuming that they have to go in and manually > recover? > > => it is the case for IPv4 because this kind of event is very rare > so there is no need to add an automatic recover tool. But IMHO > the real question is where are these problems for? They don't come > from hazard but in 99.99% of cases from configuration errors.
Yes.
> Note: In some cases the collisions is due to L2 address collision, > which I agree is quite troublesome. > > => L2 address collisions are fatal. And IMHO we should not even try to > solve them at L3 (:-).
Agreed.
> And in many cases the address collision is not based on L2. > > => currently there are three common ways to assign addresses: > - EUI64 based, i.e., relying on L2 address universal uniqueness > (read my EMEI draft to use it on mobile phones too) > - RFC 3401, i.e., relying on the "birthday" paradox > - manual, i.e., relying on the care of node managers. > Obviously only the last one is a real source of trouble.
Agreed.
> 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. > > => this is a half baked solution, i.e., either you don't want duplicates > on your network and you enforce DAD, or you accept possible problems > and you makes the live of mobile nodes (and of implementors) far easier.
(snip)
> => 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.
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? But perhaps you are worried about the possible temporary disruptions to ongoing traffic? Is that your concern? 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"?
> 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. There seems to be some people who do have an interest in quick startup & movement times. 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.
--Jari
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
