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. agree, that a short draft on how non-SEND nodes can use these options is needed. cheers, Ole -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
