>>>>> On Fri, 27 Feb 2004 18:59:25 +1100,
>>>>> "Nick 'Sharkey' Moore" <[EMAIL PROTECTED]> said:
>> 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*.
I'm now a bit confused (probably I still did not understand your
previous scenario correctly)...
Suppose that a DIID node has an interface identifier (which is
probably derived from the hardware address) "I". The DIID node first
tries "DAD" for fe80::I. If the node does not see a duplication, then
it will configure a global address P::I without doing DAD. This is
the optimization described in RFC2462.
Then, also assume the DIID node has some "suffix" which is different
from the interface identifier, "I", and even does not have any kind of
relationship with I. For example, a suffix prepared for an RFC3041
temporary address might be related to I, since a part of the seed for
the suffix might be I. On the other hand, a suffix for a SEND CGA
address would probably have no relationship with I. Let's call the
former type of suffix "S1" and the latter type of suffix "S2".
Are you worried about the case where the DIID node omits DAD for the
address P:S1 because fe80::I is proved to be unique but a different
node happens to have already used the same address P:S1? Then yes,
this may cause a problem. From a practical point of view, however,
the only example of this kind of suffix that I know of is a suffix for
an RFC3041 temporary address. And, in this case, we have already
agreed that each temporary address should be tested for its uniqueness
and the specification is updated (though currently expired,
unfortunately). So, practically, there should currently no
new compatibility issue. And if we take the proposed change in
rfc2462bis, we will be able to avoid similar compatibility issues in
the future.
Now, are you worried about the case where the DIID node omits DAD for
the address P:S2 simply because fe80::I is proved to be unique, even
though S2 is not related to I at all? If so, I'd say that this is a
bug of the specification that specifies the creation and usage of this
type of suffix, or a bug of the implementation of the DIID node.
In either case, I don't see the need for an additional workaround in
rfc2462bis.
Or, am I totally missing the point?
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
--------------------------------------------------------------------
