To address the following issue for rfc2462bis:
There is conflict with the Multicast Listener Discovery
specification about random delay for the first packet. The address
autoconfiguration requires a random delay for a DAD packet if it
is the first packet from the node, but an MLD report packet should
usually be sent before the DAD packet.
I've added the following paragraph to Section 5.4.2:
=================================================================
It should be noted that the Neighbor Solicitation is usually not the
first message. As stated above, the sending node must join the
solicited-node multicast address prior to sending the Neighbor
Solicitation and an MLD report message [9] for the multicast address
should have been sent at that time. Unfortunately, RFC 2710 [9] does
not request a random delay to avoid race conditions. Thus, if the
sending node interpreted the "first message" literally, it would not
impose a delay for the MLD report or for the Neighbor Solicitation,
making the race conditions worse. This document therefore suggests
the following workaround: even if the Neighbor Solicitation is not
the first message, the same random delay should be imposed when the
sending node knows the Neighbor Solicitation can be synchronized with
other nodes. This includes the first Neighbor Solicitation after the
MLD report message in the above case.
[9] is RFC2710 (the MLD spec)
=================================================================
I myself think this is a reasonable compromise to avoid making the
possible race condition worse. However, the new paragraph would make
existing implementations that conform to RFC2462 in a "literal" sense
become "non-compliant", and in that sense, this may be too aggressive
for the purpose of this document.
Alternatively, we could simply note the issue and not impose any
change on the behavior. Some day when RFC2710 will be updated with a
random delay for the first report, the race condition issue will also
be resolved.
Which one is better? Or is there any other solution?
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
