>>>>> On Sun, 29 Feb 2004 17:16:30 +0900,
>>>>> JINMEI Tatuya <[EMAIL PROTECTED]> said:
> 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".
Oops, I should have been more careful...the suffix for a SEND CGA
address also belongs to the former category.
> 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.
So we should also consider the CGA case. Realistically, however, does
this really cause a compatibility issue? The compatibility issue only
happens when we have a DIID based implementation that supports SEND
CGA and it is deployed. Is this really the case in the real world so
we need to worry about the compatibility?
I not, then the following logic will still apply.
> 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.
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
--------------------------------------------------------------------
