Re: [16NG] Re: multicast and IPv6 over ETHCS

Alex,

The statement below is not true:

   I meant links with link-layer headers.

   Reading ND it says "node MUST join" before receiving an RA.  'Join' can
   happen only if that link is multicast-capable.

802.15.4 (a link with link-layer header) has no multicast capability 
(only broadcast) at the link layer. Yet IPv6 can work fine. Of course,
if one wants to optimize, one can do several things (e.g., controlled
flooding, sending along a spanning tree, etc), but neither is this
required nor does the link layer have any concept of multicast.

Wouldn't it be enough to simply say that multicast address mapping
is done per http://tools.ietf.org/html/rfc2464?

Should be obvious, but perhaps this is worth noting? 

Because this is so, regular IP-level join protocols work fine
(e.g., MLD), no need to say more. You also mention elsewhere that a link-level
"join" for multicast is necessary. This is not so.  Notice that if a
link layer simply floods all multicast packets (essentially  using 
broadcast), things work fine. The IP layer itself will do the filtering.
The link-layer can do filtering to avoid flooding mcast as if it were
bcast, but it's just an optimization.

Now, 802.1D does propose such a link-layer optimization (IGRP/GARP), 
but probably cuz this requires support at
the clients (or perhaps for other reasons as well), this is not actually
deployed, and yet things work fine over ethernet. Instead, the 
optimization to avoid flooding is possible because IPv4 and
IPv6 procedures are followed for joins (IGMP, MLD) independently of link-layer.
Typically, snooping of those sets state at the link-layer to achieve the
desired (not required) optimization.

-gabriel

----- Original Message ----
From: Alexandru Petrescu <alexandru.petrescu@motorola.com>