> > RFC 2461 says > > > Before a host sends an initial solicitation, it SHOULD delay the > > transmission for a random amount of time between 0 and > > MAX_RTR_SOLICITATION_DELAY. > > > RFC 2462 says > > > 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]. > > > MAX_RTR_SOLICITATION_DELAY is 1 second. taking the worst > > case scenario, it could be 1 second before a sending > > router solicitation, one second before sending neighbor > solicitation > > for DAD and then 1 second before DAD completes. the Binding Update > > cannot be sent until then.
Please re-read the above RFC-2462 requirement closely: "If the Neighbor Solicitation is the first message to be sent from an interface after interface (re)initialization..." The DAD NS in this case is *NOT* the first message to be sent, the RS is. Therefore, you do not need the random delay prior to sending the DAD NS in this case. The same random delay before sending the RS can apply to the DAD NS (because it is sent after the RS). That's the way we implement it currently, and it causes us to fail a couple of TAHI tests :-( but we believe we are 100% compliant with the RFCs w/ regards to implementing it this way. Thanks. - Ed Remmell Elmic Systems, USA --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.522 / Virus Database: 320 - Release Date: 9/29/2003 -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
