>>>>> On Fri, 27 Feb 2004 07:09:02 +1100,
>>>>> "Nick 'Sharkey' Moore" <[EMAIL PROTECTED]> said:
> I'm convinced that a change needs to be made to the wording to
> resolve this issue, but I'm not sure which is the better option.
> I'm also dubious about relying on votes at IETF meetings for
> technical issues ... because often an option which seems 'obvious'
> at the time actually isn't once the drafts have been considered
> in detail. And most of the WG attendees won't have considered
> them in detail before the meeting. Sad but true.
> Questions for the group:
> * 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).
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.
The important thing is that we had discussed these tradeoffs long
before, and we made a decision for DAD. I admit there are some new
issues (e.g., SEND CGAs are obviously new), but I personally don't
think they are powerful enough to revisit the decision.
> * Does DAD retain these advantages when made compatible with DIID?
> (by testing/defending LL::X, as per my earlier suggestion)
> * Can backwards compatibility be dispensed with?
> (I'm going to be a hard sell on that one ...)
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. Since there
are currently always-DAD implementations as well as DIID ones, we
already have the "compatibility" issue. That is, this is not a new
compatibility issue introdueced by the proposed change (MUST do DAD,
period.) in rfc2462bis.
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.
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.
- this does not make the current status worse in the sense of
"compatibility" with DIID, since there are already always-DAD nodes.
- as implementations gradually migrate to rfc2462bis, the
"compatibility" issue will go away automatically. Even if DIID
implementations remain forever, the situation will basically be the
same as the current one.
But as I said in a previous message, it's not my purpose to invalidate
existing DIID implementations. For example, I don't want to see a
DIID implementation be called "non-compliant" in a spec-conformance
test event, etc. If I can avoid the scenario by adding some careful
note in rfc2462bis, I'm willing to do that.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
