Subject: [v6ops] ref Hosts dont MLD to join LL groups

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 21 Jul 2015 15:01:24 +0200

Hi,

Regarding the mic discussion about unicast RAs a SHOULD.

I have been directed that the reference saying that Hosts dont MLD to 
join multicast groups is RFC3810:

"  The link-scope all-nodes multicast address, (FF02::1), is handled as
    a special case.  On all nodes -- that is all hosts and routers,
    including multicast routers -- listening to packets destined to the
    all-nodes multicast address, from all sources, is permanently enabled
    on all interfaces on which multicast listening is supported.  No MLD
    messages are ever sent regarding neither the link-scope all-nodes
    multicast address, nor any multicast address of scope 0 (reserved) or
    1 (node-local)."

Alex

---

From: Ole Troan <[email-masked]>
Date: Wed, 22 Jul 2015 14:27:42 +0200

> I have been directed that the reference saying that Hosts dont MLD to join multicast groups is RFC3810:
> 
>   1 (node-local).”

I do wonder if we should expand that exception to all link-scope multicast addresses.

the bridge implementors I speak to tell me that they don’t have enough state to do MLD snooping for link-local scoped multicast addresses anyway...

cheers,
Ole

---

From: Enno Rey <[email-masked]>
Date: Wed, 22 Jul 2015 14:50:46 +0200

On Wed, Jul 22, 2015 at 02:27:42PM +0200, Ole Troan wrote:
> >   1 (node-local).???
> the bridge implementors I speak to tell me that they don???t have enough state to do MLD snooping for link-local scoped multicast addresses anyway...

I can confirm that many switches do not apply MLD snooping/the subsequent "limited forwarding" to link-local MC groups, namely solicited-node. Read: they send those out an all ports, even with MLD snooping enabled.
[see also https://www.troopers.de/media/filer_public/7c/35/7c35967a-d0d4-46fb-8a3b-4c16df37ce59/troopers15_ipv6secsummit_atlasis_rey_salazar_mld_considered_harmful_final.pdf]
There's also https://tools.ietf.org/html/draft-pashby-magma-simplify-mld-snooping-01.

best

Enno

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Wed, 22 Jul 2015 15:38:04 +0200

> the bridge implementors I speak to tell me that they don’t have enough state to do MLD snooping for link-local scoped multicast addresses anyway...

I hear similar, but in my interpretation they say this in the context of solicited node multicast groups, not in general about link-local groups.

OTOH it is easy to just flood link-local groups, right ? If so - getting rid of MLD seems like extra work to get something already possible ? (Also, adding complexity of dealing with the "pre" and "post" hosts)

--a

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 23 Jul 2015 13:43:18 +0200

Le 22/07/2015 14:27, Ole Troan a écrit :
>> "  The link-scope all-nodes multicast address, (FF02::1), is
>> handled as a special case.  On all nodes -- that is all hosts and
>> routers, including multicast routers -- listening to packets
>> destined to the all-nodes multicast address, from all sources, is
>> permanently enabled on all interfaces on which multicast listening
>> is supported.  No MLD messages are ever sent regarding neither the
>> link-scope all-nodes multicast address, nor any multicast address
>> of scope 0 (reserved) or 1 (node-local).”
>

I would beg to disagree.

If we expand that to all link-scoped groups, may lead to dismantling 
IPv6 dependence on 33::1 - ff:ff:ff:ff:ff would be sufficient.

My oppinion would rather be to modify the MLD RFC to mandate MLD joins 
for all scopes.

Ethernet has primitives for joining the corresponding link-layer groups, 
and in some cases they are used. Maybe all should use them.

> the bridge implementors I speak to tell me that they don’t have
> enough state to do MLD snooping for link-local scoped multicast
> addresses anyway...

This may be dumb from my side, but why dont bridge implementers use 
link-layer multicast?  They shouldnt implement MLD, and not snoop it. 
The Hosts should send the necessary link-layer multicast joins 
(triggered by themselves sending MLD REPORT for these groups) to the 
bridge addresses.

Alex

> cheers, Ole

---

From: Ole Troan <[email-masked]>
Date: Thu, 23 Jul 2015 04:51:33 -0700

Alexandru,

I’m afraid I couldn’t interpret your message. would someone else be able to translate?

cheers,
Ole

> If we expand that to all link-scoped groups, may lead to dismantling IPv6 dependence on 33::1 - ff:ff:ff:ff:ff would be sufficient.
> 
> My oppinion would rather be to modify the MLD RFC to mandate MLD joins for all scopes.
> 
> Ethernet has primitives for joining the corresponding link-layer groups, and in some cases they are used. Maybe all should use them.
> 
> This may be dumb from my side, but why dont bridge implementers use link-layer multicast?  They shouldnt implement MLD, and not snoop it. The Hosts should send the necessary link-layer multicast joins (triggered by themselves sending MLD REPORT for these groups) to the bridge addresses.
> 
> Alex
> 
>> cheers, Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 23 Jul 2015 14:16:43 +0200

If one disallows all MLD joins for all link-scoped IP multicast 
addresses - why does one need IP multicast addresses with link scope?

Why does one need the lino-layer  33::1 address?

If one doesnt need 33::1 then why Ethernet provides it?

I guess what I am trying to say is that it's useless to have multicast 
groups if one can't join them.

Alex

---

From: Enno Rey <[email-masked]>
Date: Thu, 23 Jul 2015 14:27:10 +0200

Hi,

> groups if one can't join them.

define "join a multicast group"...

strictly speaking MLD as a whole is only needed for interdomain multicast anyway. on the local link you join a MC group by kind-of self declaration ("hey I consider myself part of that group so I'm interested in certain traffic and hence instruct my stack to listen to/process packets with certain addresses").
no need of MLD for that action. but "joining" on the local-link doesn't need MLD. 

best

Enno

> 
> Alex
> 
> Le 23/07/2015 13:51, Ole Troan a ??crit :
> > Alexandru,
> >
> > I???m afraid I couldn???t interpret your message. would someone else be able to translate?
> >
> > cheers,
> > Ole
> >
> >>>
> >>> the bridge implementors I speak to tell me that they don???t have

-- 
Enno Rey

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 23 Jul 2015 14:49:09 +0200

Le 23/07/2015 14:27, Enno Rey a écrit :
>> I guess what I am trying to say is that it's useless to have
>> multicast groups if one can't join them.
>

Inform the sender willingnes to be part of the group.  If not part of
group, then sender will not send it.  Same concept at L2 and at L3.

> strictly speaking MLD as a whole is only needed for interdomain
> multicast anyway.

Disagree - beyond just interdomain multicast, Ethernet has link-layer
multicast builtin.  There is no 'broadcast' address anymore in Ethernet
since some time, replaced by 'multicast': supposedly better at saving
battery and other advantages.

> on the local link you join a MC group by kind-of self declaration
> ("hey I consider myself part of that group

That is an Ethernet message.

Some cards send that message, others don't.  All should.

> so I'm interested in
> certain traffic and hence instruct my stack to listen to/process
> packets with certain addresses"). no need of MLD for that action.

How does the Ethernet layer know this is a Router, and not a Host?  Only 
by knowing that it can join the all-hosts or all-routers link-layer 
address.  And only the IP stack knows whether it's a Host or a Router. 
So the IP stack should tell the Ethernet layer to make that link-layer join.

Yours,

Alex

> but
> "joining" on the local-link doesn't need MLD.
>
> best
>
> Enno
>
>
>
>
>
>>
>> Alex
>>
>>>> If we expand that to all link-scoped groups, may lead to
>>>> dismantling IPv6 dependence on 33::1 - ff:ff:ff:ff:ff would be
>>>> sufficient.
>>>>
>>>> Ethernet has primitives for joining the corresponding
>>>> link-layer groups, and in some cases they are used. Maybe all
>>>> should use them.
>>>>
>>>>> the bridge implementors I speak to tell me that they don???t
>>>>> have enough state to do MLD snooping for link-local scoped
>>>>> multicast addresses anyway...
>>>>
>>>> This may be dumb from my side, but why dont bridge
>>>> implementers use link-layer multicast?  They shouldnt implement
>>>> MLD, and not snoop it. The Hosts should send the necessary
>>>> link-layer multicast joins (triggered by themselves sending MLD
>>>> REPORT for these groups) to the bridge addresses.
>>>>
>>>> Alex
>>>>
>>>>> cheers, Ole
>>>
>>
>> _______________________________________________ v6ops mailing list
>>  [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Enno Rey <[email-masked]>
Date: Thu, 23 Jul 2015 15:01:52 +0200

Hi,

> group, then sender will not send it.  Same concept at L2 and at L3.

wrong.
the sender of a MC message just sends it out, regardless if somebody listens or not.
the router(s) helping to distribute this message (in case of interdomain MC) only have to know (= are interested) if there's at least one interested listener on an adjacent link.
neither the sender nor the router(s) have any interest (or need to have that) in individual listeners.

> That is an Ethernet message.

no. that's a decision taken somewhere in the software/stack. no need for any packet here.

> So the IP stack should tell the Ethernet layer to make that link-layer join.

which it does, as a stack-internal decision.
"once I'm a router get me everything sent to ff02::1/33:33:00:00:00:01. in addition - given I'm a node anyway - get me everything for ff02::2". no need to send any packet for all this.

best

Enno

-- 
Enno Rey

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 23 Jul 2015 16:34:42 +0200

Le 23/07/2015 15:01, Enno Rey a écrit :
> Hi,
>
>>
>> Inform the sender willingnes to be part of the group.  If not part
>> of group, then sender will not send it.  Same concept at L2 and at
>> L3.
>
> wrong. the sender of a MC message just sends it out, regardless if
> somebody listens or not.

I agree.

> the router(s) helping to distribute this message (in case of
> interdomain MC) only have to know (= are interested) if there's at
> least one interested listener on an adjacent link. neither the
> sender nor the router(s) have any interest (or need to have that) in
> individual listeners.

YEs, that's so for multicast across multiple subnets.

But on the same link (same subnet) the Router sends these RAs, so it
must be able to know which Host would like to receive its multicasted RAs.

>> Disagree - beyond just interdomain multicast, Ethernet has
>> link-layer multicast builtin.  There is no 'broadcast' address
>> anymore in Ethernet since some time, replaced by 'multicast':
>> supposedly better at saving battery and other advantages.
>>

Well.  I cant put my wireshark in monitor mode right now but if I could
I would tell the name of the Ethernet message on WiFi (a management
frame) which joins link-layer multicast.

>>> so I'm interested in certain traffic and hence instruct my stack
>>> to listen to/process packets with certain addresses"). no need
>>> of MLD for that action.
>>
>> How does the Ethernet layer know this is a Router, and not a Host?
>> Only by knowing that it can join the all-hosts or all-routers
>> link-layer address.  And only the IP stack knows whether it's a
>> Host or a Router. So the IP stack should tell the Ethernet layer
>> to make that link-layer join.
>
> which it does, as a stack-internal decision. "once I'm a router get
> me everything sent to ff02::1/33:33:00:00:00:01. in addition - given
> I'm a node anyway - get me everything for ff02::2". no need to send
> any packet for all this.

In that same way, the Host must be able to tell everybody else whether
or that Host is interested in receiving the multicasted RAs.

Alex

>
> best
>
> Enno
>
>
>
>
>
>>
>> Yours,
>>
>> Alex
>>
>>> but "joining" on the local-link doesn't need MLD.
>>>
>>> best
>>>
>>> Enno
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> Alex
>>>>
>>>>>> dismantling IPv6 dependence on 33::1 - ff:ff:ff:ff:ff
>>>>>> would be sufficient.
>>>>>>
>>>>>> link-layer groups, and in some cases they are used. Maybe
>>>>>> all should use them.
>>>>>>
>>>>>>> the bridge implementors I speak to tell me that they
>>>>>>> don???t have enough state to do MLD snooping for
>>>>>>> link-local scoped multicast addresses anyway...
>>>>>>
>>>>>> implementers use link-layer multicast?  They shouldnt
>>>>>> implement MLD, and not snoop it. The Hosts should send the
>>>>>> necessary link-layer multicast joins (triggered by
>>>>>> themselves sending MLD REPORT for these groups) to the
>>>>>> bridge addresses.
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>>> cheers, Ole
>>>>>
>>>>
>>>> _______________________________________________ v6ops mailing
>>>> list [email-masked]

---

From: Owen DeLong <[email-masked]>
Date: Thu, 23 Jul 2015 18:15:11 -0700

> On Jul 23, 2015, at 05:49 , Alexandru Petrescu <[email-masked]> wrote:
> 
> 
> 

That’s simply not true…

Even if I turn off every SSDP listener on my network, I still have many devices sending many SSDP
packets in IPv4 _AND_ IPv6.

And those packets are visible to _EVERY_ host on the link, not just the ones that subscribed.

MLD is used to tell routers that you want to join a group so that it knows someone on link A
wants to see the multicast packets for that group from Link B.

> battery and other advantages.

Yes, but Ethernet Link Layer Multicast doesn’t use MLD for delivery decisions.

From Cisco’s documentation on MLD snooping:

MLD Snooping Overview 

 <>MLD snooping allows the switch to examine MLD packets and make forwarding decisions based on their content. 

 <>You can configure the switch to use MLD snooping in subnets that receive MLD queries from either MLD or the MLD snooping querier. MLD snooping constrains IPv6 multicast traffic at Layer 2 by configuring Layer 2 LAN ports dynamically to forward IPv6 multicast traffic only to those ports that want to receive it. 

 <>MLD, which runs at Layer 3 on a multicast router, generates Layer 3 MLD queries in subnets where the multicast traffic needs to be routed. For information about MLD, see this publication: 

 <>http://www.cisco.com/en/US/docs/ios-xml/ios/ipv6/configuration/12-2sx/ipv6-12-2sx-book.html <http://www.cisco.com/en/US/docs/ios-xml/ios/ipv6/configuration/12-2sx/ipv6-12-2sx-book.html> <>You can configure the MLD snooping querier on the switch to support MLD snooping in subnets that do not have any multicast router interfaces. For more information about the MLD snooping querier, see the "Enabling the MLD Snooping Querier" section <http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SX/configuration/guide/book/snoopmld.html#wp1050624>. 

 <>MLD (on a multicast router) or, locally, the MLD snooping querier, sends out periodic general MLD queries that the switch forwards through all ports in the VLAN, and to which hosts respond. MLD snooping monitors the Layer 3 MLD traffic. 

In other words, MLD is strictly a layer 3 function. Some Layer 2 devices do interesting things with it (MLD Snooping), but counting on MLD to discover a listener that is not trying to listen or subscribe beyond the local link scope is not guaranteed to work.

Unfortunately, there probably are many other misguided implementers like Alexandru out there, so it is likely that turning off MLD for Link Local would break things in a number of existing implementations even though it shouldn’t.

Tough call whether that’s overall a good thing (let’s break it to make the world better and fix the implementations that identify themselves when it breaks) or a bad idea (generally breaking stuff is bad unless you have a really good reason to do so.).

I will say that ideally, we should pick a consistent decision… Either require MLD for all multicast joins, including link local or prohibit MLD for link-scoped multicast. The current “You can MLD if you want to and what happens when you don’t is undefined for all but a select few pre-defined groups is anybody’s guess” probably isn’t ideal no matter what.

> That is an Ethernet message.

Nope… It’s a matter of adding the applicable Mac address and IP address to the “interesting addresses” list on the interface.

To the best of my knowledge, there’s no Ethernet L2 message for expressing interest or lack thereof in a multicast group.

MAC addressing is handled by a reserved Mac range (01:00:5E:00:00:00/25)  for IPv4 multicast, where the low-order 23-bits of the multicast group IP address are placed in the low order 23 bits of the MAC address.

IPv6 multicast uses MAC addresses in the range 33:33:0:0:0:0/16 and maps the low order 32 bits of the multicast group onto the low order 32 bits of the MAC address.

Nowhere in the ethernet L2 world is there anything special about 33:33::/16. It’s strictly a conventional reservation from an Ethernet perspective. A bridge does not (necessarily)  see it as different from any other MAC address.

The exception would be bridges that implement MLD snooping where you are then counting on receiving L3 MLD messages to tell the bridge how to behave, but said MLD messages may or may not exist. An MLD querier can be configured on some bridges in order to solicit additional MLD joins, but hosts are not required or necessarily expected to send said joins for link local scoped groups unless solicited. Even then, it is a Layer 3 function which the switch is using kind of a hack to take advantage of to inform L2 forwarding.

> Some cards send that message, others don't.  All should.

Source? Nothing in the standards I could find requires or even says “Should” in any of the IEEE documents I could find.

> How does the Ethernet layer know this is a Router, and not a Host?  Only by knowing that it can join the all-hosts or all-routers link-layer address.  And only the IP stack knows whether it's a Host or a Router. So the IP stack should tell the Ethernet layer to make that link-layer join.

It cannot be a router and not a host. It can be a host and not a router. All routers are by definition hosts. Not all hosts are routers.

The IP stack tells the ethernet layer which addresses are interesting. 

On Linux, you can find it here:

owen.delong.com:owen /proc/16742/net (167) % cat /proc/net/dev_mcast
2    em1             1     0     333300000001
2    em1             1     0     01005e000001
2    em1             1     0     3333ff5abc51
2    em1             1     0     01005e0000fb
2    em1             1     0     3333ff000001
2    em1             1     0     3333ff000002
2    em1             1     0     3333ff000004
2    em1             1     0     3333ff000005
2    em1             1     0     3333ff000006
2    em1             1     0     3333ff000007
2    em1             1     0     3333ff000009
2    em1             1     0     3333ff00000a
2    em1             1     0     3333ff00000b
2    em1             1     0     3333ff00000c
2    em1             1     0     3333ff00000d
2    em1             1     0     3333ff00000e
2    em1             1     0     3333ff00000f
2    em1             1     0     3333ff000012
2    em1             1     0     3333ff000013
2    em1             1     0     3333ff000014
2    em1             1     0     3333ff000015
2    em1             1     0     3333ff000016
2    em1             1     0     3333ff000017
2    em1             1     0     3333ff000018
2    em1             1     0     3333ff000019
2    em1             1     0     3333ff00001a
2    em1             1     0     3333ffefcafe
2    em1             1     0     01005e7ffffa

Again, to the ethernet card, it’s just another MAC address it listens for. It doesn’t care multicast, unicast, broadcast. If the DST MAC Address of an arriving packet is in the list of addresses to listen to (which is the concatenation of the unicast MAC address(es), the broadcast MAC address(es), and the multicast MAC address(es) configured by the IP stack), it hands the packet up to the kernel. If not, it discards the packet.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 23 Jul 2015 18:28:07 -0700

> On Jul 23, 2015, at 07:34 , Alexandru Petrescu <[email-masked]> wrote:
> 
> 
> 

No… It sends them to the ALL_HOSTS multicast group which it assumes
will reach every host on the link, since that’s the whole point of the ALL_HOSTS
multicast group when paired with LINK scope.

> frame) which joins link-layer multicast.

WiFi != Ethernet.

802.11 != 802.1, 802.3, etc.

Management Frames
802.11 management frames enable stations to establish and maintain communications. The following are common 802.11 management frame subtypes:

Management frames are unique to WiFi.

> or that Host is interested in receiving the multicasted RAs.

Nope… It either listens or it doesn’t. According to IPv6, a host must listen
to all hosts and a router must listen to all routers and all hosts, but that’s
merely by convention.

Nothing in the hardware.

No packets sent to say “I’m now listening for this.” It just starts listening.

It’s like changing channels on your TV…. You don’t tell the old TV station
that you’re tuning out and the new station that you’re tuning in. You just
change which frequency your local tuner is listening to.

Owen

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 24 Jul 2015 07:04:48 +0200

I agree unicast RA in response to RS makes sense.  Ideally unicast RAs
in responses to unicast RSs.

Le 24/07/2015 03:28, Owen DeLong a écrit :
>
>> On Jul 23, 2015, at 07:34 , Alexandru Petrescu
>> <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>
>>
>>>> Inform the sender willingnes to be part of the group.  If not
>>>> part of group, then sender will not send it.  Same concept at
>>>> L2 and at L3.
>>>
>>> wrong. the sender of a MC message just sends it out, regardless
>>> if somebody listens or not.
>>
>> I agree.
>>
>>> interdomain MC) only have to know (= are interested) if there's
>>> at least one interested listener on an adjacent link. neither
>>> the sender nor the router(s) have any interest (or need to have
>>> that) in individual listeners.
>>
>> But on the same link (same subnet) the Router sends these RAs, so
>> it must be able to know which Host would like to receive its
>> multicasted RAs.
>
> will reach every host on the link, since that’s the whole point of
> the ALL_HOSTS multicast group when paired with LINK scope.

YEs.  But it's a matter of semantics.  A Host may want to act as a Host 
sometimes (join all-hosts) and as a router other times (join the 
all-routers group only).

For example, a smartphone would need to act as a Host when RS/RA but 
would need to be a router when doing 64share (stop its RSs, unsubscribe 
all-hosts, etc).

To paraphrase, that's the whole point of that being a group a multicast 
and not using broadcast - not just a fancy word.

Alex

>
>
>>
>>>>> strictly speaking MLD as a whole is only needed for
>>>>> interdomain multicast anyway.
>>>>
>>>>> on the local link you join a MC group by kind-of self
>>>>> declaration ("hey I consider myself part of that group
>>>>
>> Well.  I cant put my wireshark in monitor mode right now but if I
>> could I would tell the name of the Ethernet message on WiFi (a
>> management frame) which joins link-layer multicast.
>
> WiFi != Ethernet.
>
> 802.11 management frames enable stations to establish and maintain
> communications. The following are common 802.11 management frame
> subtypes:
>
>
>
>>>>> so I'm interested in certain traffic and hence instruct my
>>>>> stack to listen to/process packets with certain addresses").
>>>>> no need of MLD for that action.
>>>>
>>>> How does the Ethernet layer know this is a Router, and not a
>>>> Host? Only by knowing that it can join the all-hosts or
>>>> all-routers link-layer address.  And only the IP stack knows
>>>> whether it's a Host or a Router. So the IP stack should tell
>>>> the Ethernet layer to make that link-layer join.
>>>
>>> which it does, as a stack-internal decision. "once I'm a router
>>> get me everything sent to ff02::1/33:33:00:00:00:01. in addition
>>> - given I'm a node anyway - get me everything for ff02::2". no
>>> need to send any packet for all this.
>>
>> In that same way, the Host must be able to tell everybody else
>> whether or that Host is interested in receiving the multicasted
>> RAs.
>
> Nope… It either listens or it doesn’t. According to IPv6, a host must
> listen to all hosts and a router must listen to all routers and all
> hosts, but that’s merely by convention.
>
> Nothing in the hardware.
>
> It’s like changing channels on your TV…. You don’t tell the old TV
> station that you’re tuning out and the new station that you’re tuning
> in. You just change which frequency your local tuner is listening
> to.
>
> Owen
>
>>
>> Alex
>>
>>>
>>> best
>>>
>>> Enno
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> Yours,
>>>>
>>>> Alex
>>>>
>>>>>>>> If we expand that to all link-scoped groups, may lead
>>>>>>>> to dismantling IPv6 dependence on 33::1 -
>>>>>>>> ff:ff:ff:ff:ff would be sufficient.
>>>>>>>>
>>>>>>>> link-layer groups, and in some cases they are used.
>>>>>>>> Maybe all should use them.
>>>>>>>>
>>>>>>>> implement MLD, and not snoop it. The Hosts should send
>>>>>>>> the necessary link-layer multicast joins (triggered by
>>>>>> _______________________________________________ v6ops
>>>>>> mailing list [email-masked] <mailto:[email-masked]>
>>>> list [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: Owen DeLong <[email-masked]>
Date: Thu, 23 Jul 2015 22:10:11 -0700

> On Jul 23, 2015, at 22:04 , Alexandru Petrescu <[email-masked]> wrote:
> 
> YEs.  But it's a matter of semantics.  A Host may want to act as a Host sometimes (join all-hosts) and as a router other times (join the all-routers group only).

I do not believe that is allowed under the standards. A router _IS_ a host and is supposed to be a member of the all-hosts group.

> For example, a smartphone would need to act as a Host when RS/RA but would need to be a router when doing 64share (stop its RSs, unsubscribe all-hosts, etc).

No. This is not true.

A host is not required to RS. But a router should not unsubscribe from all-hosts. It is not required to (and usually shouldn’t) act on RAs received on an interface for which it is an active router, but that does not mean that it can unsubscribe from the all-hosts multicast group.

> To paraphrase, that's the whole point of that being a group a multicast and not using broadcast - not just a fancy word.

Um… The fact of the matter is that all hosts with link scope is morally equivalent to broadcast and is also very rarely used.

Owen