Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies

From: Francis Dupont <[email-masked]>
Date: Tue, 24 Feb 2004 16:07:35 +0100

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-masked]

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

---

From: Brian Haberman <[email-masked]>
Date: Tue, 24 Feb 2004 10:41:05 -0500

<chair hat on>

While the topic of Optimistic DAD is interesting, I believe we are
getting work items crossed here.  The consensus I see is to not make
changes to 2462 wrt Optimistic DAD.  Therefore, we can drop this
discussion as it relates to the 2462 update.

There is a slot in Seoul to discuss Optimistic DAD in general.  If
people wish to discuss it prior to Seoul, please do so in another
thread.

We now return you to your regular programming...

<chair hat off>

Regards,
Brian

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Wed, 25 Feb 2004 06:49:23 +1100

On 2004-02-24, Francis Dupont wrote:
> [Jari Arkko wrote:] 
> >    [...] Generally, for the last two we can only provide detection

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).

> => 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.
>    

So, which problem would you like to see solved?

-----Nick
-- 
Nick 'Sharkey' Moore  <[email-masked]>  <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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 25 Feb 2004 16:27:16 +0200

Hi Francis,

> and no DAD is a part of the specific tuning.

Ok. I'm beginning to understand your point... Yes, disabling
DAD is indeed possible today via setting DupAddrDetectTransmits
to zero. And some important link layers are using this approach,
typically combined with something else that ensures duplicates
are not generated in the first place. For instance, RFC 3316 says
what 3G mobile phones do in this respect. For these link layers
optimistic DAD will not help, as there was no delay to begin
with.

On the other hand, these link layers are not the only ones
available. Ethernet-type link layers are important too, and
there we don't have any convenient mechanism to avoid duplicates
besides DAD; and I personally would say that I'd rather leave
DAD turned on in my wireless LAN.

Now, from the point of view of an end user, this implies
that there are the following choices:

1. Start using a link layer technology where dedicated links are
    possible and DAD disabling does not cause duplicates. No
    delays involved.

2. Use a link layer where dedicated links are not possible,
    and disable DAD, accept the risk of collisions. No delays
    involved here either.

3. Use a link layer where dedicated links are not possible,
    keep using DAD. Delay introduced into movements and
    attachments.

I think the desire to provide an optimized DAD procedure
comes from the fact that people are stuck with a given
link layer technology but are still uncomfortable with
either option 2 or 3. That is, they would rather have

4. Use a link layer where dedicated links are not possible,
    keep using DAD to prevent collisions, but do this in
    a smarter way which avoids delays.

This would be the "eat the cake and save it too" option,
which in this case is possible if new protocols are
introduced.

--Jari