Subject: Re: Joining of multicast groups for DAD and ND

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 01 Jul 2004 17:08:52 +0900

>>>>> On Tue, 29 Jun 2004 07:31:16 -0400, 
>>>>> Brian Haberman <[email-masked]> said:

>> Yes, I quess it should apply to all IPv6 protocol specifications using link-
>> local multicast groups and requiring a HopLimit of 255 for validity as is the 
>> case for ND and DAD.
>> 
>> Look at it from the point of view of an implementor: Here you have a 
>> specification that does not make sense in a "pure" IPv6 environment of hosts 
>> and routers: "Join a multicast group and send an MLD report in order to get 
>> multicast packets which should be ignored".

> I don't think the IETF can specify what a pure IPv6 environment looks
> like.  Each implementor and deployer will have their own view of what
> that definition should be.

I basically agree with Brian.

Also, even if we decided to fill in the gap between the "pure"
environment and the "real" one with snooping devices, I strongly
believe it would have to be clarified in the MLD/MLDv2 document, not
in each and every spec document using some multicast groups.

So the right question here is, IMO, whether such a spec document
should explicitly refer to the MLD RFC(s).  Opinions on this point
might vary, but I strongly believe we don't need to do that (or even
we shouldn't do that).

Particularly from an implementor's point of view, what I would do with
the following description of RFC2461...

   A router MUST join the all-routers multicast address on an
   advertising interface.
(Section 6.2.2)

...is as follows:

	setsockopt(sock, IPPROTO_IPV6, IPV6_JOIN_GROUP, "ff02::2");
(this is a pseudo-code for readability)

And, this is in fact what I did in our implementation of router
advertisement daemon.  The kernel that implements RFC2710 correctly
will then send an MLD report just according to the RFC, and I don't
care about such a thing.

In this sense, simply saying "join" provides enough information for
implementors to implement this part of the specification, and
mentioning MLD in this context is just redundant to me.

(I intentionally avoided using the example of solicited-node multicast
groups because in our implementation the kernel joins these groups and
it may make the point unnecessarily vague.  But the main point still
applies to our kernel implementation; the routine handles interface
initialization simply calls a function like "in6_joingroup()" in which
an MLD report will be sent correctly.  The former routine doesn't
(have to) care about MLD things.)

One last remark: when I edited recent versions of rfc2462bis-02, I
explicitly referred to the MLD document for joining solicited-node
multicast groups for DAD.  That's because there was a direct issue
regarding MLD to be solved within rfc2462bis.  I think that's a very
special case and won't apply to any other documents using link-local
multicast groups.

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