>>>>> On Thu, 26 Feb 2004 11:46:58 +0200,
>>>>> Markku Savela <[EMAIL PROTECTED]> said:
>> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <[EMAIL PROTECTED]>
>> So, I'd now like to propose a concrete change. The simplest way to
>> implement the option would be to remove the second exception shown in
>> Section 5.4 of RFC2462. That is, the revised text would be:
>>
>> 5.4 Duplicate Address Detection
>>
>> Duplicate Address Detection is performed on unicast addresses prior
>> to assigning them to an interface whose DupAddrDetectTransmits
>> variable is greater than zero. Duplicate Address Detection MUST take
>> place on all unicast addresses, regardless of whether they are
>> obtained through stateful, stateless or manual configuration. On the
>> other hand, Duplicate Address Detection MUST NOT be performed on
>> anycast addresses.
>>
>> The procedure for detecting duplicate addresses uses Neighbor
>> Solicitation and Advertisement messages as described below...
>>
>> Can we live with this simple resolution?
> You are ignoring the installed base. There are already out and
> delivered, and in real use, implementations which do the DAD only for
> the link local.
If I were really ignoring the installed base, I would simply declare
the new text without asking the questions (in my previous message). I
would be happy if I could get the above comment from you while I'm
listening to others since the first message of this thread...
Anyway, any comments at this stage are, of course, welcome.
> This is valid as per currently valid RFC,
Yes, but:
> and still consider this a
> sensible implementation. Apparently, nobody else truly supports the
> multiple IDs and prefixes, with full combination? In such case, doing
> DAD on each new combination for each announced prefix on RA is
> frightening.
basically, you seem to argue for DIID (against) DAD. Though I agree
that DIID vs DAD is somewhat controversial and there is surely a
tradeoff between those two, I believe the wg consensus was we should
honor DAD rather than DIID (as Francis showed some pointers). And, I
don't see the need for revisiting the discussion.
I proposed the text for rfc2462bis in my previous message because it
will make the specification simpler and clearer based on the
"consensus", and three others apparently agreed (I admit I cannot call
this a "majority" though)
Of course, it is not my goal in rfc2462bis to invalidate existing
implementations compliant to RFC2462, including those that implement
"DIID".
Fortunately, the tightened requirement will not introduce
interoperability issue (IMO): when a (global) address collide, if a
DAD node comes after a DIID node, the DAD node will detect the
duplication and stop using the address. If a DIID node comes after a
DAD node, and the corresponding link-local address happens to not
collide, the DIID node cannot detect the duplication, and the two
nodes will continue to use the duplicate address. This is bad, but is
not worse than the RFC2462 world.
So, I'm wondering if we can deal with this by some moderate wording.
(for example, "future implementations MUST do DAD").
> And even with single id and new prefix this is not good: on RA with a
> new global prefix, every node on the link is going to do DAD based on
> its ID and new prefix. And, as far as I know, there is no delay
> requirement here, so everyone is doing it at same time.
Hmm, this is a good point. An obvious workaround is to impose a
random delay when the node is starting a DAD process for an address
configured by multicasted RA.
Does this kind of additional requirement make sense? > all
If so, should we include this in rfc2462bis?
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
--------------------------------------------------------------------
