(Sorry, there seems to have been a problem with my previous post). Hi Jari,
----- Original Message ----- From: Jari Arkko <[EMAIL PROTECTED]> Date: Sunday, February 8, 2004 3:44 am Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay > Gregory Daley wrote: > > Hi Jari, > > > > ----- Original Message ----- > > From: Jari Arkko <[EMAIL PROTECTED]> > > Date: Friday, February 6, 2004 10:42 pm > > Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS > delay> > > > >>Greg Daley wrote: > >> > >> > >>>I do not think we should be modifying every node to suit > >>>MLD snooping, but it is possible to perhaps suggest > >>>a random delay for _both_ the MLD report _and_ the DAD > >>>NS (but no explicit delay between them). The DAD NS must > >>>come after the MLD report though. > >> > >>What is important here is to avoid the collisions. The collisions > >>are avoided if there is some random delay before you start sending > >>packets. Given that the protocols impose an ordering (MLD first and > >>DAD after that), a delay in MLD will impose an equivalent delay > >>in DAD. > > > > > > That's sufficient. > > Ok, so now we agree what needs to be done protocol wise, the > rest is just a documentation issue ;-) > > >>My conclusion is that the right thing is to update RFC 2710 > >>and require a delay. This removes collisions from both MLD > >>and DAD. > > > > > > I think that the problem there may be that RFC-2710 is > > being replaced by MLDv2. > > > > The IPv6 node reqs document had a MUST for MLDv1, and > > SHOULD for MLDv2 (last I saw). This could lead to many > > of the hosts exhibiting the colliding behaviour for MLDv1, > > even if the changes go into MLDv2. > > > > Will we effectively need MLDv1(the second)? > > I see the problem. I do not have a strong opinion on which > document should explain what the correct behaviour is, as > long as the document boundaries do not force us to specify > suboptimal behaviour. For instance, if RFC 2462bis can explain > that the delay should actually be before the MLD packet, that > would be also sufficient. [If you think it sounds strange that > 2462bis would be saying what to do for MLD, lets not forget > that MLD is invoked because 2462bis needs the multicast > listening service.] If people think it is appropriate to update 2462 with the address config related MLD procedures, that seems fine to me. Taking text from Jinmei san's proposal: "... 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. RFC 2710 [9] does not request a random delay when sending an initial group report for solicited nodes' addresses. Even if this is the case, a node SHOULD delay (as described above) before initial transmission of the MLD report when joining the solicited nodes' address, if this is the first transmission on a link. In this case, an NS for the purposes of DAD which is subsequently transmitted doesn't require additional delays, since it will not be synchronized with other nodes configuring on the link. In some cases it is possible for a node to start listening to the group during the delay period before MLD report transmission, although in some link-layer environments no multicast reception will be available until the report is sent. ..." Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
