Not quite sure I entirely understand the issue, but SEND makes no change in
the basic underlying DAD algorithm. If the address suffix generated from the
key hash changes due to a change in the prefix, then the address has to be
re-DAD-ed. If the node decides to reuse the old suffix, then the address
isn't a CGA and SEND can't be used. SEND includes support for interoperation
between SEND and nonSEND nodes, so it should work if a node decides not to
use SEND.
jak
----- Original Message -----
From: "Nick 'Sharkey' Moore" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "Greg Daley" <[EMAIL PROTECTED]>
Sent: Thursday, February 26, 2004 6:44 PM
Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies
> On 2004-02-27, Greg Daley wrote:
> > Nick 'Sharkey' Moore wrote:
> > >
> > > - When configuring a global unicast address, the link-local
> > > address with the same suffix as that address MUST be configured
> > > and tested for uniqueness in order to maintain interoperability
> > > with RFC2462 behaviour.
> >
> > I think that configuring additional addresses which
> > don't match the prefix used to generate the suffix in
> > the CGA is going to cause problems.
>
> Good point. However, the MN registering A::X only needs to
> defend the LL::X against DIID-compatible nodes.
> I think we can assume that SEND-CGA nodes will follow the
> _new_ DAD standard. So the unsecured defensive NA should be okay,
> since it won't be needed against SEND-CGA nodes.
>
> ... I think. Any SENDites want to comment?
>
> NB: Is there a plan for 3041bis? It's rather bound up with
> DIID too.
>
> cheers,
> -----Nick
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [EMAIL PROTECTED]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------