I am a bit new to this list and could not pick up the specific thread for issue 337, but it looks to me like the sending of the NS should be delayed and not the joining of the solicited-node multicast address.
On 28 May 2004 at 20:56, B wrote: > For issue 337, add the following paragraph between the third and > fourth paragraphs of Section 5.4.2: > > Even if the Neighbor Solicitation is not going to be the first > message to be sent from an interface after interface > (re)initialization, the node SHOULD delay joining the solicited-node > multicast address by a random delay between 0 and > MAX_RTR_SOLICITATION_DELAY if the address being checked is configured > by a router advertisement message sent to a multicast address. The > delay will avoid similar congestion when multiple nodes are going to > configure addresses by a same single multicast router advertisement. > > =============================================== Gerrit van Niekerk GP van Niekerk Ondernemings BK Roosstraat 211, Meyerspark, 0184, South Africa Tel: +27(12)8036501 Fax: +27(12)8034131 Email: [EMAIL PROTECTED], [EMAIL PROTECTED] Web: http://www.gpvno.co.za =============================================== -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
