>>>>> On Sun, 29 Feb 2004 16:30:19 -0800,
>>>>> "James Kempf" <[EMAIL PROTECTED]> said:
> Conversely, however, there is a problem with a DIID node that just DADs its
> LL address and assumes from there that the IID can be used for a global
> address, since the SEND node will just check against its LL address, due to
> the difference in prefixes. The SEND node's already configured unicast
> global address might then conflict with the DIID node's. However, this
> problem would occur between any DIID node and a node that uses different
> address suffixes for LL and uncast global addresses.
Since I seem to have been failing to understand the point, please let
me rephrase that to be sure. Are you talking about a scenario like
this?
We have two nodes, a "SEND node" and a "DIID node".
SEND node:
- (for simplicity) do not implement the DIID-style optimization
- have an (e.g.,) EUI-64 based interface identifier, I.
- configure a SEND (CGA) address P:A (where A is the identifier, A != I)
DIID node
- implement the DIID-style optimization
- (for simplicity) do not implement SEND
- happen to have A as an interface identifier
The SEND node comes to a link. It perform DAD for both fe80::I and
P:A, and confirms that these are unique.
Then the DIID node comes to the same link. It performs DAD for
fe80::A, and confirms it is unique. So the DIID node start using
P:A without doing DAD while P:A is actually duplicate.
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
--------------------------------------------------------------------
