Jinmei,
> 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?
>
When an address suffix is formed from a different key or subnet prefix,
including link local addresses, SEND will DAD it. This is in conformance
with RFC 2462 and has the effect of the SEND node DADing all autoconfigured
addresses (LL as well as unicast global). The NS sent by a SEND node will
include the SEND ND options. A nonSEND node will receive the NS, ignore the
options (as per 2462) and reply with an unsecured NA if it has a duplicate.
Section 8, paragraph 9 of the SEND spec describes what the SEND node does in
this case. Briefly, it will accept the first unsecured NA, but will reject
unsecured NAs after the first. So a node that has DIIDed an address first
will have the opportunity to defend it.
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.
So, unless I'm missing something, I don't think there would be any problem
between SEND nodes and DIID nodes that would not also occur betwee, say, RFC
3041 nodes and DIID nodes.
jak
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
