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

[Owen DeLong <[e-mail]>]

> On Jul 23, 2015, at 05:49 , Alexandru Petrescu <[e-mail]> wrote:
> 
> 
> 
> Le 23/07/2015 14:27, Enno Rey a écrit :
>> Hi,
>> 
>> On Thu, Jul 23, 2015 at 02:16:43PM +0200, Alexandru Petrescu wrote:
>>> 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.
>> 
>> define "join a multicast group"...
> 
> 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.

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.

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

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.

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

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.

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

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

> 
> Yours,
> 
> Alex
> 
>> 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
>>>> 
>>>>>> 
>>>>>> I do wonder if we should expand that exception to all
>>>>>> link-scope multicast addresses.
>>>>>> 
>>>>> 
>>>>> 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
>>>> 
>>> 
>>> _______________________________________________ v6ops mailing list
>>> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>> 
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops