Subject: Joining of multicast groups for DAD and ND

From: "Gerrit van Niekerk" <[email-masked]>
Date: Sat, 26 Jun 2004 19:01:20 +0200

Why MUST an interface join any multicast group for DAD and ND?

As I understand it, joining a multicast group is intended to inform routers 
that multicast packets must be routed, but both DAD and ND ignore routed 
packets by requiring the hop limit field to be 255.

Perhaps the problem is in my understanding of "join a multicast group", a term 
which I do not find a definition for in RFC's 2460-2462. If it only refers to 
informing the interface to receive packets on the specified multicast address, 
my question is answered. If, however, it also refers to sending MLD report 
messages as implied in RFC2462bis Section 5.4.2, my question stands.
===============================================
Gerrit van Niekerk
GP van Niekerk Ondernemings BK
Roosstraat 211, Meyerspark, 0184, South Africa
Tel: +27(12)8036501 Fax: +27(12)8034131
Email: [email-masked], [email-masked]
Web: http://www.gpvno.co.za
===============================================

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sun, 27 Jun 2004 14:29:03 +0900

>>>>> On Sat, 26 Jun 2004 19:01:20 +0200, 
>>>>> "Gerrit van Niekerk" <[email-masked]> said:

> messages as implied in RFC2462bis Section 5.4.2, my question stands.

Please be more specific.  Which multicast group(s) are you talking
about here?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: "Gerrit van Niekerk" <[email-masked]>
Date: Sun, 27 Jun 2004 10:52:26 +0200

Any at all i.e. the all-nodes multicast address, the solicited-node multicast 
address of the tentative address (DAD), the all-routers multicast address on an
advertising interface and the solicited-node multicast address corresponding to 
each of the IP addresses assigned to the interface (ND). The question is 
specifically about the need to join multicast groups in the context of DAD and 
ND.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sun, 27 Jun 2004 18:46:37 +0900

>>>>> On Sun, 27 Jun 2004 10:52:26 +0200, 

> specifically about the need to join multicast groups in the context of DAD and 

So your question is essentially whether a node needs to send an MLD
report message for link-local scope multicast groups.  It is not
directly related to ND (in general) or DAD.

The answer to the "essential" question is yes, except for the
all-nodes multicast address (ff02::1).  The simplest reason is because
RFC2710 requires that.  Interaction with an MLD snooping switch might
provide some background behind this requirement.

You may also want to read RFC2710 and draft-ietf-magma-snoop-11.txt.

					JINMEI, Tatuya

---

From: "Gerrit van Niekerk" <[email-masked]>
Date: Mon, 28 Jun 2004 16:59:10 +0200

The question is directly related to ND and DAD because the "joining of the link-
local scope multicast groups" is specified in RFC2461 and RFC2462. It is now 
clear to me that the reason is to inform MLD snooping switches rather than 
routers about the multicast listening node. 

I would suggest adding a definition of "join a multicast group" in the 
TERMINOLOGY section and a single sentence reason where the "join" is used e.g. 
in RFC2461bis:

7.2.1.  Interface Initialization

   When a multicast-capable interface becomes enabled the node MUST join
   the all-nodes multicast address on that interface, as well as the
   solicited-node multicast address corresponding to each of the IP
   addresses assigned to the interface in order to inform bridging devices like 
   MLD snooping switches of the multicast listener.

> > address of the tentative address (DAD), the all-routers multicast address on
> > an advertising interface and the solicited-node multicast address
> > corresponding to each of the IP addresses assigned to the interface (ND). The
> > question is specifically about the need to join multicast groups in the
> > context of DAD and ND.
On 27 Jun 2004 at 14:29, B wrote:
> > Perhaps the problem is in my understanding of "join a multicast group", 
> > a term which I do not find a definition for in RFC's 2460-2462. If it only 
> > refers to informing the interface to receive packets on the specified 
> > multicast address,my question is answered. If, however, it also refers to 
> > sending MLD report messages as implied in RFC2462bis Section 5.4.2, my 
> > question stands.===============================================
Gerrit van Niekerk

---

From: Greg Daley <[email-masked]>
Date: Tue, 29 Jun 2004 10:45:35 +1000

Hi Gerrit,

>    MLD snooping switches of the multicast listener.

While this make the issue clearer, it will be hard to avoid
a new (informative?) reference to the IGMP/MLD snooping draft.
Since this is not yet an RFC there may be some problem (possibly
not if the reference is informative).

I'm not sure if this needs to be avoided.

Additionally, the only multicast group which doesn't need
MLD signalling is all-hosts.  So we may need to make a
distinction here.

In any case, it may be more generic to have a statement such as:
(modifying your paragraph):

    When a multicast-capable interface becomes enabled the node MUST join
    the all-nodes multicast address on that interface, as well as the
    solicited-node multicast address corresponding to each of the IP
    addresses assigned to the interface.  Joining a solicited-node's
    group requires sending of MLD reports to inform devices within the
    local link of the multicast listener's presence[MLDv2(?1?)].

I'm not sure if this is any better.

Greg

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 29 Jun 2004 16:47:32 +0900

>>>>> On Mon, 28 Jun 2004 16:59:10 +0200, 

> routers about the multicast listening node. 

But shouldn't this apply to all other protocol specifications that use
link-local multicast groups?  Those include:

- RIPng(RFC2080) uses FF02::9
- OSPFv3(RFC2740) uses FF02::5 and FF02::6
- PIM (draft-ietf-pim-sm-v2-xx) uses FF02::D
- DHCPv6(RFC3315) uses FF02::1:2

And I believe there are still others, and more will come.  These
specifications may not use the exact word "join", but it's obvious a
node that implements these protocols need to "join" these groups
(including interface configuration and sending MLD messages) for
the protocol operation.  I don't see any fundamental differences
between the ND/DAD cases and those other protocols on this point.

And then,

> TERMINOLOGY section and a single sentence reason where the "join" is used e.g. 

If we take it, we'll also need to "clarify" the same thing on the
other protocol specifications, and we'll also need to do the same
thing for all future specifications that use link-local multicast
groups.  I don't think it makes sense.

					JINMEI, Tatuya

---

From: "Gerrit van Niekerk" <[email-masked]>
Date: Tue, 29 Jun 2004 13:01:17 +0200

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

It does make sense if you know about "rogue" devices like snooping MLD switches 
which will not decrement the HopLimit when forwarding a multicast packet.

So now the question becomes: How can new implentors be made aware of the 
necessity to cater for undefined "rule-bending devices" on a network without 
having to waist IPv6 discussion group e-mail bandwidth?

I would venture to say: By defining those devices and their characteristics in 
broad terms in a base document e.g RFC2460. RFC2460 is not currently under 
review, but RFC2461 and RFC 2462 are and this may be an opportunity which will 
not present itself for another  5 years.

On 29 Jun 2004 at 16:47, B wrote:

> > The question is directly related to ND and DAD because the "joining of the
> > link- local scope multicast groups" is specified in RFC2461 and RFC2462. It is
> > now clear to me that the reason is to inform MLD snooping switches rather than

---

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

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

> which will not decrement the HopLimit when forwarding a multicast packet.

Which is what draft-ietf-magma-snoop-11.txt is trying to clarify.  If
snooping devices follow that spec, then other implementors will have
an idea of what to expect out of them.

> having to waist IPv6 discussion group e-mail bandwidth?

Have you read and understood draft-ietf-ipv6-node-requirements-09.txt?

> not present itself for another  5 years.

Defining how snooping devices behave is outside the scope of this
working group.

Regards,
Brian