On 2005-11-06, Christian Vogt wrote: > > I see, it's an implementation issue.
Sadly, true. Whilst we're not really meant to worry about these, sometimes they can't be ignored. > (3) Given that you cannot really know whether the ON is stationary or > mobile, the following may be a good approach: Send the pair of MLD > Report and NS multiple times with incremental de-synchonization delays, > but allow for immediate use of the OA: Now, I'm not saying that this is a bad idea, but I do think it's adding unwarranted complexity for OptiDAD's purposes. On the other hand, a more flexible desync backoff algorithm might e a good research paper topic perhaps. Given that the original (RFC2462, 5.4.2) is a "should delay": | | If the Neighbor Solicitation is the first message to be sent from an | interface after interface (re)initialization, the node should delay | sending the message by a random delay between 0 and | MAX_RTR_SOLICITATION_DELAY as specified in [DISCOVERY]. I'm happy to just recommend a "SHOULD NOT delay" in OptiDAD, as this was something I'd been assuming all along. Does anyone in here object? -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
