James Kempf writes: Supposing that SEND nodes use CGAs, is DAD really
required?

CGAs eliminate the possibility of DoS attack, and configuration conflicts
would occur only if two nodes have the same public key. I suppose an
implementation with a faulty random number generator could run into this
problem, but it seems extremely unlikely, and quickly self correcting, since
a customer would quickly report the problem. Calculations on the probability
of collision for standard IID-based host prefixes show it is something like
10^-12, with CGA, it should be even less.

If that's true, then the only case where a conflict could occur is with
nonSEND nodes. Wouldn't it be sufficient for a SEND node to monitor the
solicited node multicast address and respond to any attempt by a nonSEND
node to claim the address? A nonSEND node could persist in a DOS style
attack, but the SEND node could just change its public key for addresses.

-----------

Jari Arkko writes: One practical approach for us to deal with the DAD
issue in SEND is that we take the "secure ND" and "optimize DAD"
problems separately. That is, SEND takes IPv6 as-is, now. Then an
extension is built later to provide security for optimistic DAD.

-----------

Hesham Soliman responds to Jari Arkko: Completely agree.

-----------

Nick Moore writes:Yeah, the Optimistic DAD draft is still looking for
a home, but it probably isn't SEND!  I'm happy to include SEND
considerations in the draft though, if there need to be any.  At the
moment the Optimistic DAD draft states "[...] a suffix MUST be chosen
based on a strongly random algorithm [...]", and if I updated that to
read "[...] a suffix MUST be chosen based on a strongly random
algorithm or well-distributed hash function [...]" it'd fit right in
with SEND/CGA otherwise unmodified, I think.

-----------