> 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?
Yes, I agree. This solution makes sense.
- Christian
--
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/
Nick 'Sharkey' Moore wrote:
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
--------------------------------------------------------------------
