Ole Troan wrote:
Greg,
This essentially the problem with DAD on wifi, right? That should make a general solution more interesting then just a corner case.
no, this is a general problem. I've seen this on Ethernet. I've spoken to the DAD/WIFI draft owners and we've agreed to add the id option to that draft and rename it to something less wifi specific.
SEND has already defined a random Nonce option for Neighbour Solicitation messages.
Also defined are Timestamp options for these messages.
Send requires both of these to be present in a DAD-NS.
In this case, a node can keep track of (only) its fresh Nonces, and it will be able to check if received DAD NS's are its own.
These options would even be able to be used in non-SEND solicitations under the constraint that there's no trust associated with them (since they're not signed messages).
There's no further identifier definition required (although it would be valuable to write a short draft on it).
thanks for pointing out the SEND draft to me, I haven't followed that work for a while.
yes, it seems that the Nonce option should work. a SEND node receiving these would interpret this message as a unsecured message as long as there is no trust association, right? if there is a trust association the message would be silently discarded.
I believe that the messages aren't interpreted as 'secured' unless they have a valid signature. (the key used to verify the signature is often included in the SEND message).
For DAD-NS/NA messages though, there's likely to be no existing relationship between the configuring node and a receiver. The SEND message in and of itself typically provides enough information to prove its ownership of a public key (and thus an address if CGA is used).
This doesn't actually mean that unsecured DAD messages get silently discarded though. For the first DAD attempt, SEND actually allows unsecured NA's to indicate address duplication (though subsequent address configurations only listen to SEND).
agree, that a short draft on how non-SEND nodes can use these options is needed.
The shorter, the better...
Greg
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
