On 2004-02-24, Francis Dupont wrote: > [Jari Arkko wrote:] > > > => what we need is collision avoidance, no collision detection after > > damage. > > > [...] 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.
Optimistic DAD explicitly excludes manually configured addresses -- because in my opinion they're FAR MORE LIKELY to collide than randomly chosen ones. Human error dwarfs N/2^62 for any sane N. EUI-derived addresses may be configured Optimistically, but if they collide the node instead configured with a random address. (or CGA-derived addresses resalt). > > 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 that is all that the current RFC2461/2462 behaviour provides! > > > 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. So, which problem would you like to see solved? -----Nick -- Nick 'Sharkey' Moore <[EMAIL PROTECTED]> <http://zoic.org/sharkey/> "(I never even thought of using a radio controlled toy on an airplane, but now that they say I can't, I'm guessing it's way fun.)" -- Penn Jillette -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
