I think Nick was expressing frustration in this case, rather than proposing to adopt a bad solution.
Jun-ichiro itojun Hagino wrote:
Yes, DIID probably (or something similar). I believe that simplest solution is that a specific ID value can be allowed only for single node on the link. Any use of same ID part with any prefix by another node should be viewed as an address collision.
I can see where you are coming from: for DAD to safely interoperate with DIID it must send even more messages: wouldn't it be nice to just send a single NS/NA pair? After all, DIID is already compatible with DIID.
this i remember very precisely. we have already discussed DIID/DAD to death and picked DAD already. i don't think it necessary to open the topic up again.
What we really need is a way to ensure that we can use DAD in a way which prevents existing DIID nodes from causing troubles.
We can tell people that DIID exists, but is deprecated, and has to be dealt with to ensure backward compatability with old devices.
We can handle this by ensuring that addresses which are in use by a DAD node aren't assumed to be available by DAD nodes. This will may need algorithmic modification in some cases.
Essentially, a newly configuring DIID node MUST send a DAD NS for the fe80::suffix address. This goes to the solicited nodes' address for the suffix.
Whan the existing node has completed DAD on a prefix::suffix address, it is already a member of the same solicited nodes' address.
Therefore, even if it doesn't have the particular target address configured (it hasn't got fe80::suffix configured itself) it will see the DAD NS from the DIID node.
Since we know that nodes attempting to do DIID will do DAD on the link-local address, any other addresses configured for DIID should be tentative at the time. Transmission of an DAD defence for the currently configured prefix::suffix address should work to prevent DAD.
If the host already posesses the fe80::suffix address, that would be used instead (and is sufficient for defending against DIID).
Only in the case where the link local address wasn't configured (CGA addresses for SEND, rfc-3041 addresses) would the algorithmic modification be required. In the SEND case, it is unlikely that any suffix will be configured more than once on an interface (which means only one message will respond to the DAD attempt).
In the case that the configuring node was doing full DAD for a number of addresses with the same suffix, it will have already joined the solicited nodes' group. Therefore, it should receive the DAD defence NA from the node.
Even if it hasn't already sent the DAD NS for a global prefix, it may still receive the DAD defence NA, since it receives the solicited nodes' datagram.
In the worst case, the defending node will transmit a defence for both the link-local and the global prefix DAD NS's.
Greg
Greg
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
