I think the problem is half solved with securing-neighbour discovery.
Ole Troan wrote:
On Thu, 12 Feb 2004 00:07:39 +0000, Ole Troan <[EMAIL PROTECTED]> said:
one solution could be to add a optional identifier option to DAD NS packets, so that the sender can recognise the case when its own packets are looped around.
too big a change for 2462bis?
I think this is too big to merge into 2462bis (sorry), but I agree this is worth considering as an extension in a separate document (depending on how this is popular and severe).
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.
/ot
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).
Greg Daley
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
