Subject: [rfc2462bis issue 274] conflict between MLD and NS delay

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 06 Feb 2004 00:17:12 +0900

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-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Markku Savela <[email-masked]>
Date: Thu, 5 Feb 2004 17:55:08 +0200

> I've added the following paragraph to Section 5.4.2:

This is silly! I thought the reason for the random delay was to
prevent simultaneus packet sending of all hosts on the link, if they
boot up at same time (for example after power fail).

Now, this MLD report is going to be collided (mostly lost anyway),
because every node is sending on the link at same time.

If you are not delaying the MLD, there is really no point in delaying
the DAD either...

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 06 Feb 2004 01:07:05 +0900

>>>>> On Thu, 5 Feb 2004 17:55:08 +0200, 
>>>>> Markku Savela <[email-masked]> said:

> If you are not delaying the MLD, there is really no point in delaying

Sorry, I don't see the point.  With the current RFC2710 and RFC2462 in
the power failure (or something similar) case, MLD reports are
collided, and then NS for DAD are also collied.

With the proposed resolution, MLD reports are collided, but NS for DAD
are not (depending on the variance of random timers).

I proposed the resolution because I thought the former is worse than
the latter.  So, I'd see your point if you said the change is *not so
effective* because we still have collisions.  But I don't see why you
called it "silly".

					JINMEI, Tatuya

---

From: Greg Daley <[email-masked]>
Date: Fri, 06 Feb 2004 13:59:36 +1100

Hi Jinmei,

> effective* because we still have collisions.  But I don't see why you

The simultaneous transmission issue is principally a
reliability issue.  There is some chance on certain link-layers
that packets will be significantly delayed or lost when
simulataneous transmission occurs.

There are very few reasons why one would require MLD reports
on link local solicited nodes addresses.

The only existing reasons to do MLD on these addresses are
so that MLD proxies, and snooping switchescan request
multicast transport for those addresses.  Unless this
is performed correctly, the node performing DAD
will not receive DAD defence NA's, even if the DAD NS is
sent with random delay.

Since there is no random delay with MLD, the reliability issue
still exists in these environments.  I believe that this may
have been what what Markku was trying to communicate.

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.

In this case, the node could start listenting to the group
before sending an MLD report.  This is different to MLD/MLDv2,
but will not hurt, since the DAD NS is the principle
trigger for multicast traffic to that solicited nodes' address.

In snooping environments, the node wouldn't get any messages
to the group until the MLD report was sent.
In any case, it avoids the simultaneous transmission problem.

In some systems, the ordering of MLD-report and NS
cannot be guaranteed on the output queue.  Before transmitting
the DAD NS, the node should ensure that either there has been
sufficient time between MLD transmission and NS, in order
to guarantee packet ordering on the link.
Alternatively, explicit indication that transmission has occurred
would achieve the same purpose.

Greg Daley

---

From: Jari Arkko <[email-masked]>
Date: Fri, 06 Feb 2004 13:42:01 +0200

> 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.

My conclusion is that the right thing is to update RFC 2710
and require a delay. This removes collisions from both MLD
and DAD.

(We could still keep the requirement in 2462bis that if the DAD
message is the first message to be sent then you should add
a delay, but in that case we need to explain that if you
follow the MLD spec then it never is the first message.)

> In any case, it avoids the simultaneous transmission problem.

Listening before you send the MLD report is possible, but should
be optional since, as you say, it does not always work.

--Jari

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Sun, 08 Feb 2004 20:31:01 +0900

>>>>> On Fri, 06 Feb 2004 13:59:36 +1100, 
>>>>> Greg Daley <[email-masked]> said:

> have been what what Markku was trying to communicate.

Okay, this is a valid point.  I actually thought what Markku wanted
to say could be something related to MLD snooping, but it was not very
clear just from his message, at least to me (so I simply asked his
intention in my previous message).

For the spec/documentation wise discussion, I'll reply to later
messages.

					JINMEI, Tatuya

---

From: Brian Haberman <[email-masked]>
Date: Sun, 08 Feb 2004 09:02:54 -0500

Greg Daley wrote:

>>>>>>> On Thu, 5 Feb 2004 17:55:08 +0200, Markku Savela 
>>>>>>> <[email-masked]> said:
>>>>>>
>>>>>>
>>

This is the case.  MLD Report messages on link-local groups is
to ensure the proper behavior in snooping switches.

> have been what what Markku was trying to communicate.

Group management protocols can be considered a low-level member
of the routing protocols.  That means, random delays in sending
state changes affect the routing/forwarding infrastructure of the
network.  Introducing delays in the sending of those state changes
doesn't seem to be the approach to take here.  And reliability is
addressed by scheduling multiple Report messages to be transmitted.

Keep in mind that there is a delay invoked for sending a Report when
it is triggered by a valid Query message.  But that will not typically
apply to the NDP case.

> come after the MLD report though.

Given my point above, I would argue that we shouldn't add a
delay to MLD messages.

The MLD Report will get generated as soon as the ND performs the
ADD_MEMBERSHIP socket call on the solicited-node address.  If the
ND code then introduces a delay after that for the initial message
the ordering should be ensured and a random delay generated.

> trigger for multicast traffic to that solicited nodes' address.

True, nodes can listen to for a group without explicitly joining it.

> would achieve the same purpose.

Brian

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 09 Feb 2004 01:34:15 +0900

>>>>> On Sun, 08 Feb 2004 09:02:54 -0500, 
>>>>> Brian Haberman <[email-masked]> said:

> Given my point above, I would argue that we shouldn't add a delay to
> MLD messages.

So, do you have any opinion among the options I raised in this thread?

1. no change in rfc2462bis (expecting MLDv1 and/or MLDv2 will
   eventually be updated with a random delay)
2. the original proposal of mine (expecting MLDv1 and/or MLDv2 will
   eventually be updated with a random delay):
   impose a random delay even for the first NS after the corresponding
   MLD when the sending node knows there is no delay for the MLD.
3. Greg's suggestion:
   require a random delay before the first MLD (in rfc2462bis).

(including "4. none of above").

Apparently you'd reject option 3 from your point.  I also know that
you are NOT expecting MLDv1/v2 will be updated with a random delay,
even if you prefer option 1 or 2 itself.

					JINMEI, Tatuya

---

From: Fred Templin <[email-masked]>
Date: Sun, 8 Feb 2004 09:15:11 -0800 (PST)

Jinmei,
 
Do you have a timeframe for when you will be posting RFC2462(bis)
to the I-D repository?
 
Thanks - Fred
[email-masked]

JINMEI Tatuya / 神明達哉 <[email-masked]> wrote:
>>>>> Brian Haberman 

JINMEI, Tatuya

---

From: Jari Arkko <[email-masked]>
Date: Sun, 08 Feb 2004 19:38:08 +0200

> addressed by scheduling multiple Report messages to be transmitted.

I agree that group management protocols can be consider to be
routing protocols. But in the case that we are talking about
here, the multicast address is a link local mc address. As a result,
the routing/forwarding infrastructure of the network is not affected,
as far as I can see. It is possible that some L2 device is affected.
And the router will process the MLD message. But (perhaps I'm dense)
I don't see how a router would change its routing or forwarding
behaviour due to seeing a change in the link local multicast
behaviour.

Even if there would be a change, I do not see why it follows that
delays are prohibited. As I see it, we have a number of somewhat
conflicting factors:

- desire to provide service in a timely manner
- desire to avoid packet storms upon booting many nodes simultaneously
- desire to accommodate snooping switches

The second factor may dictate that some delay be used, even
if the first factor would lead to sending all messages immediately.

Also, Jinmei wrote:

> Regarding option 3:
>   pro: this is a complete solution of the problem, which works with
>        MLD snooping switches
>   con: this can be regarded as spec-violation, and we may have to
>        worry about conflict with MLD updates in the future

Why do you consider this as a spec violation? Because then 2462bis
would appear to say something that is different than what MLD specs
say, or because ND specs should not say anything about MLD?

I think the right engineering solutions should be adopted, without
too much regard into the documentation boundaries. Having said that,
if you worry about the document boundary, you can simply say "delay
joining to the multicast group by a random delay. Once you have joined,
send the ND packet."

--Jari

---

From: Brian Haberman <[email-masked]>
Date: Sun, 08 Feb 2004 14:29:58 -0500

> behaviour due to seeing a change in the link local multicast

In the case of link-local addresses, a router would not change its
behavior.  L2 switches that implement snooping will.

> - desire to provide service in a timely manner

2710 does this by mandating that nodes that join a multicast group
send N Report messages immediately.

> - desire to avoid packet storms upon booting many nodes simultaneously

2710 accomplishes this by using message suppression.  If a node hears a
Report for the same group, it cancels the transmission of any pending
Reports it has for the group.

> say, or because ND specs should not say anything about MLD?

It is not that it shouldn't say anything about MLD, I believe the
comment is directed at the fact that in this case, 2462bis would
contradict what is documented in the current MLD specs.

> joining to the multicast group by a random delay. Once you have joined,

So you want to impose this delay factor on all multicast groups?  Or do
you want the MLD spec to be more complicated and say do X for link-local
groups and Y for all other scopes?

I definitely want to avoid having that kind of logic in the MLD specs.

Overall, I think the biggest issue here is the differences in the way
MLD and ND were designed.  And we have additional complexity in the fact
that MLDv1 and MLDv2 have some fundamental differences in how they
behave.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Sun, 08 Feb 2004 14:33:01 -0500

I don't like the idea of a random delay in the MLD Reports.  As I
said in another note, it either adversely affects the logic in the
MLD specs or causes application delays for non-LL groups.

Is having a delay in the NS transmission alone sufficient?  So that
the Report is sent immediately and the NS is delayed.

Regards,
Brian

---

From: Markku Savela <[email-masked]>
Date: Sun, 8 Feb 2004 22:31:47 +0200

> From: Brian Haberman <[email-masked]>

> Reports it has for the group.

Above will totally fail with ND multicast groups. Their design goal is
that each host is only on one group. It is highly unlikely that
listening would hear a duplicate join for the solicited node multicast
address.

I've already said my differing opinion on this way back earlier, but
apparently I lost the vote. But, just to make clear:

  sending MLD messages for link local multicast groups is waste of
  time and specification effort. If you have layer 2 sniffers, they
  can (and most likely must) sniff the normal ND traffic too. A ND DAD
  contains exactly the same information content as MLD join for the
  solicited node group.

---

From: Brian Haberman <[email-masked]>
Date: Sun, 08 Feb 2004 18:06:58 -0500

Markku,

> listening would hear a duplicate join for the solicited node multicast

It is not a failure, it is just not useful for solicited-node multicast
addresses.  But, you also snipped a part of the note that pointed out
that ND and MLD were designed with differing techniques to deal with
reliability.

>   contains exactly the same information content as MLD join for the

And the MLD Report for the solicted-node multicast address will cause
the L2 sniffer to forward the ND DAD message to any other port that
has joined the same multicast group.  If two nodes are DAD'ing for the
same unicast address, the L2 sniffer will need to forward those NS
messages to all ports where the solicited-node address has been joined.

Regards,
Brian

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 09 Feb 2004 11:06:01 +0900

>>>>> On Sun, 8 Feb 2004 09:15:11 -0800 (PST), 
>>>>> Fred Templin <[email-masked]> said:

> Do you have a timeframe for when you will be posting RFC2462(bis)

I'll post it as a wg document (draft-ietf-ipv6-rfc2462bis-00.txt) by
the cutoff date for initial submissions (Feb. 9th).

That is, I'll post the draft very soon.

					JINMEI, Tatuya

---

From: Greg Daley <[email-masked]>
Date: Mon, 09 Feb 2004 11:38:18 +1100

Hi Brian,

> the Report is sent immediately and the NS is delayed.

I think what Jari asked was not a modification to the semantics
of reporting group joins.

I think that what Jari proposed was actually that we delay DAD
(which entails both the operation of beginning listening to
a group and the NS transmission).

To put it another way, we don't actually configure the address
until the random delay timer has expired.  The delay's expiration
is a precondition for address configuration, in this case.

In this way, joining the group occurs when the group is first
listened to (in accordance with MLDvX) and the NS transmission is
similarly delayed.

Delaying only the NS is insufficient, as the statement in RFC-2462
is for two purposes:

1. Increased reliability of DAD NS tranmission.

2. Protection of the link against packet storms.

Relying only on the MLD report replay mechanisms only achieves
the first of these goals, and not the second, since the MLD
transmissions may be synchronized for the first report.

Delaying both provides superior protection of the link, and
gains the same reliability mechanisms already available without
requiring change to the MLD specifications.

Greg

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 09 Feb 2004 11:44:28 +0900

>>>>> On Sun, 08 Feb 2004 14:33:01 -0500, 

> the Report is sent immediately and the NS is delayed.

I read this to mean you support option 2 (but without expecting any
future change in the MLD spec).  I can live with this, but as others
pointed out, this approach may cause a trouble when we are using MLD
snooping switches and the first MLD reports for DAD NSs collide: the
reports will be lost due to the collisions, then the MLD filter in the
snooping switches isn't configured correctly, then DAD NSs can be
dropped due to the filter even if there is an address duplication and
other nodes are listening to the solicited-multicast group.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 09 Feb 2004 12:14:35 +0900

>>>>> On Sun, 08 Feb 2004 19:38:08 +0200, 
>>>>> Jari Arkko <[email-masked]> said:

> say, or because ND specs should not say anything about MLD?

What I'm worrying about is to make a hidden requirement to MLD in the
address autoconfiguration spec (I admit "spec-violation" is not an
appropriate term - "spec boundary violation" is perhaps better?).

> too much regard into the documentation boundaries.

In general, I agree.

> Having said that,

Hmm, I tend to agree with this wording.  Yes, this can still be
considered as boundary violation with wording trick, but I think this
makes it clear that the delay is only for DAD NSs and this minimizes
effects to the MLD spec.  And, of course, this is a perfect solution
to the collision problem.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 09 Feb 2004 15:32:46 +0900

>>>>> On Mon, 09 Feb 2004 12:14:35 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> to the collision problem.

How about this one?  (this may still be controversial, and if so,
please continue the discussion.  But since the cutoff deadline is
looming, I'll submit the draft with the proposed text below anyway.)

   If the Neighbor Solicitation is 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 as specified in RFC
   2461 [5]. This serves to alleviate congestion when many nodes start
   up on the link at the same time, such as after a power failure, and
   may help to avoid race conditions when more than one node is trying
   to solicit for the same address at the same time.

   Note that the delay for joining the multicast address implicitly
   means delaying transmission of the corresponding MLD report message
   [9]. Since RFC 2710 [9] does not request a random delay to avoid race
   conditions, only delaying Neighbor Solicitation would cause
   congestion by the MLD report messages. The congestion would then
   prevent MLD-snooping switches from working correctly, and, as a
   result, prevent Duplicate Address Detection from working. The
   requirement to include the delay for the MLD report in this case
   avoids this scenario.

   In order to improve the robustness of the Duplicate Address Detection
   algorithm, an interface MUST receive and process datagrams sent to
   the all-nodes multicast address or solicited-node multicast address
   of the tentative address while the delaying period. This does not
   necessarily conflict with the requirement that joining the multicast
   group be delayed. In fact, in some cases it is possible for a node to
   start listening to the group during the delay period before MLD
   report transmission. It should be noted, however, that in some
   link-layer environments, particularly with MLD-snooping switches, no
   multicast reception will be available until the MLD report is sent.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 09 Feb 2004 09:51:56 +0200

>    multicast reception will be available until the MLD report is sent.

Looks very good. Thanks!

--Jari

---

From: Markku Savela <[email-masked]>
Date: Mon, 9 Feb 2004 13:05:56 +0200

> that ND and MLD were designed with differing techniques to deal with

Perhaps MLD has evolved since I last looked at the WG group. However,
I believe using MLD snooping switches makes your network unreliable.

Let me iterate my reasoning (maybe MLDv2 has been fixed since,
but..). All of the following relates only to solicited node multicast
groups:

- if MLD join on DAD is lost, it does not only break DAD, it also
  makes that node invisible to all other nodes behind the snooping
  swith (because no ND traffic related to that group is passed
  through).

- to recover, someone is supposed to request MLD report from all nodes
  on the link.

- who sends this request? As far as I understand, only multicast
  routers are requesting those reports? Is running a multicast router
  now obligatory MUST on every link?

- ok, you can say the snooping switch sends the report request
  occasionally. But, then the switch must have IPv6 link local
  address, it must implement at least part of the IPv6 ND. It might as
  well note the ND DAD messages.

- when report request is sent, EVERY node on the link going to reply,
  and without a delay. Isn't this going to raise the probability that
  some of the replies are lost? If so, then again we have some nodes,
  whose ND is not working over the switch. How do recover from this
  cycle?

- if your switch boots, it has to request reports from all links, and
  it can enable the filtering only after it is sure that it has a
  complete picture of joined groups. Again, a storm of replies,
  possibility of lost answers?

Are such switches used to bridge WLAN's?

Are existing MLD snooping switches currently really trying to work on
link local groups (and especieally solicited node)? Or, are they just
passing all and ingoring link local groups? Have they really though
over the issues above? Is this a "snake oil" product, as far as
solicited node groups are considered? :-)

---

From: Brian Haberman <[email-masked]>
Date: Mon, 09 Feb 2004 06:24:26 -0500

Hi Greg,

> a group and the NS transmission).

So, in logic-wise it would look like:

     1. Generate the solicited-node multicast address
     2. Wait for random timer expiry
     3. Perform ADD_MEMBERSHIP call on the socket
     4. Send DAD

I think I can live with that for the time being.

> listened to (in accordance with MLDvX) and the NS transmission is

OK.

> requiring change to the MLD specifications.

Given the above proposal, I can accept this approach.  It isolates
the delay to NDP rather than affecting all users of MLD.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Mon, 09 Feb 2004 06:36:01 -0500

Hi Markku,

>   swith (because no ND traffic related to that group is passed

Correct, to a degree.  The node sends N Reports in a particular window
in order to deal with random packet loss.  The node is invisible until
the switch processes the Report and adds forwarding state for the
requested multicast address.

>   now obligatory MUST on every link?

Not at all.  Snooping switches take on the role of Querier in all IGMP
snooping devices that I know of.  They send out Queries on all ports
setup for snooping.

Much of the detail is outlined in draft-ietf-magma-snoop-10.txt.  In
addition, draft-ietf-magma-igmp-proxy-04.txt may be useful in some
cases as well.

>   well note the ND DAD messages.

If it sends MLD messages, it will need to conform to the MLD spec.  And
for IPv6, it gets a little more complicated than it did for v4.  That is
due to the inclusion of MLD and ND messages inside of ICMPv6.  Now the
switch has to be able to parse ICMPv6 messages in order to find the
messages of interest.

>   whose ND is not working over the switch. How do recover from this

Message suppression helps in 2710 if the group address is the same.
Otherwise the randomized delay in sending the remaining N-1 messages
will offer recovery from packet loss.

>   possibility of lost answers?

Possibly.  That is why MLD sends N Reports.

> Are such switches used to bridge WLAN's?

I have no idea.

> solicited node groups are considered? :-)

The purpose of the above referenced snooping draft is supposed to help
switch vendors "do the right thing".  Most switches deployed today do
not recognize IPv6 multicast addresses at all.  In fact, IGMP snooping
switches adversely affect IPv6 multicast in odd ways.  So, I have heard
all sorts of instances where IGMP snooping had to be disabled in order
to allow IPv6 to work.

Regards,
Brian

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 10 Feb 2004 19:00:04 +0900

>>>>> On Mon, 09 Feb 2004 06:24:26 -0500, 

> I think I can live with that for the time being.

In my latest proposal, the behavior is a bit different:

      1. Generate the solicited-node multicast address
      2. Perform ADD_MEMBERSHIP call on the socket (or equivalent) but
         not send MLD, i.e., start listening to the multicast address
      3. Wait for random timer expiry
      4. send MLD
      5. Send DAD

The reason for doing 2 before the random delay is because we need to
listen to the multicast address to improve the reliability of DAD.

The reason for doing 3 (random delay) before sending MLD is for
avoiding collisions.

Would you still live with this?

					JINMEI, Tatuya

---

From: Brian Haberman <[email-masked]>
Date: Tue, 10 Feb 2004 06:19:16 -0500

> Would you still live with this?

In the stacks I am familiar with, once you perform ADD_MEMBERSHIP, the
sending of the Report message is out of your control.

     1. Would you standardize a mechanism for joining but not reporting?

     2. Does the implementation of NDP "control" the MLD state machine?

     3. What happens if someone builds a stack from multiple vendors
        (e.g. MLD from vendor X and NDP from vendor Y)?

Regards,
Brian

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 10 Feb 2004 20:31:19 +0900 (JST)

>         (e.g. MLD from vendor X and NDP from vendor Y)?

	this is "someone"'s responsibility to ensure the documented behavior,
	IMHO.  it is not a concern for standard document (no need to document).

itojun

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 10 Feb 2004 21:24:43 +0900

>>>>> On Tue, 10 Feb 2004 20:31:19 +0900 (JST), 
>>>>> [email-masked] (Jun-ichiro itojun Hagino) said:

> 	IMHO.  it is not a concern for standard document (no need to document).

I basically agree.  IMO, this kind of thing is implementation
dependent, and can be out of scope of a specification document.

Regarding our own implementation (KAME/BSD), it joins the
solicited-node multicast group corresponding to a link-local unicast
address within the kernel; it doesn't need a separate system call
(IPV6_JOIN_GROUP) to join the group in this particular case.  So, I
believe it's not so difficult to implement the procedure I showed in
my previous message at least on one OS that I know of.

We could add a note in rfc2462bis that in some OSes it may not be
effective to separate the join process and the listen process, though
I personally think it's overkilling in this document.

					JINMEI, Tatuya