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

From: Jari Arkko <[email-masked]>
Date: Tue, 24 Feb 2004 16:49:57 +0200

Francis Dupont wrote:

 >    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-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 26 Feb 2004 16:05:38 +0900

>>>>> On Tue, 24 Feb 2004 13:16:02 +0200, 
>>>>> Jari Arkko <[email-masked]> said:

>> So I really believe in the DAD usefulness and if you'd like to remove
>> or "optimize" DAD on one of my networks my answer will be "NO!".

> I believe the optimistic DAD folks are very keen on keeping the DAD
> functional. That is, it is a requirement that networks and nodes must
> be able to recover from a collision situation. No one is proposing
> removing DAD.

> Since most folks appear to agree that any optimization is not
> a part of 2462bis and that Jinmei's option 1 is reasonable, I
> think we can close the issue for 2462bis.

> As for the rest, I believe we should discuss optimistic or optimized
> DAD schemes under a different thread, since this really has nothing
> to do with 2462bis. And for that discussion, let's not label someone's
> method a priori as "removal". There may be specific concerns in the
> specific methods, but if that's the case then they have to be
> corrected or rejected.

I totally agree with you, especially in the sense that whether
optimistic DAD is good or not can/should be discussed separately from
this particular issue for rfc2462bis.

Thanks for the prudent clarification.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]