[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rfc2462bis issue 275] DAD text inconsistencies



On 2004-02-27, JINMEI Tatuya / ?$B?@L@C#:H wrote:
> "Nick 'Sharkey' Moore" <sharkey@zoic.org> said:
> >
> > * DIID offers less signalling.   What advantages does DAD offer?
> 
> An obvious advantage is less probability of (missing) duplication (as
> was pointed out even in this thread several times).

... if you're testing multiple addresses with the same suffix,
there'll be more chance of collision with another node using the
same suffix, true.  But it'd be more elegant to increase
DupAddrTransmits if that were your aim.  And SEND-CGA nodes 
will configure different suffixes per prefix: odds are, only
one will collide.

But honestly, I don't really want to reopen the DAD vs DIID
debate either.  I'm happy to do DAD.  I'd be happier if it
was interoperable with DIID, because of the installed base.

> A supplemental advantage would be simplicity and clarity in the
> specification (and probably in implementations).  I know this kind of
> argument is more or less subjective and may not be convincing though.

It's pretty close to convincing me -- the concept of an Interface
Identifier is unnecessary and can be done without, so I 'like'
DAD better.

> Honestly speaking, I don't see the need for making DAD "compatible"
> with DIID in the first place.  Recall that DAD is not "compatible"
> with DIID in this sense, even with the current RFC2462.

There is not currently a true DAD vs. DIID division.
2462 specifies that nodes SHOULD test all addresses, and they MUST
test the LL.  That bit is written on the assumption that all
suffixes will be the same -- otherwise it is meaningless.

All I'm proposing (see my previous post with the very short
bit of suggested text) is to clarify the rules for the post-IID era,
with a check for the link-local to maintain compatibility with
2462-compliant nodes *whether they check all addresses or just the LL*.

> Meanwhile, even DAD is not perfect in that we can still miss
> duplication due to a timing problem or packet loss.  Even if we
> introduce some new effort to make DAD compatible with DIID, it will
> not be perfect either.

True, true, I suggest increasing DupAddrTransmits in Optimistic DAD
for this reason.

> I thus conclude that we don't need a change, at least in rfc2462bis,
> to make DAD compatible with DIID.
> 
> Again, my plan is simple.
> 
> - just say "MUST do DAD for all unicast addresses" (or SHOULD if we
>   need a wording compromise) in rfc2462bis.

I'm happy with MUST.

> - this does not make the current status worse in the sense of
>   "compatibility" with DIID, since there are already always-DAD nodes.

see above.  If I haven't explained myself properly, just let me
know.  Again, this is only an individual opinion that backwards
compatibility in this case is acheivable and important.

Anyway, see you all in Seoul,

-----Nick

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------