Subject: [v6ops] Practical question about MLD join for LL multicast

From: Brian E Carpenter <[email-masked]>
Date: Thu, 3 Mar 2016 09:00:00 +1300

I'm sorry to distract the group with a practical question, but I'm a bit stumped.
My question is below.

In the thread "Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node Group Membership (-01)", on
24/02/2016 08:07, Brian E Carpenter wrote:
> On 24/02/2016 07:53, [email-masked] wrote:
>>>> MLD joins for the solicited node multicast address has turned out to have little practical purpose. I am thinking of going the other way and stop sending joins for link-local multicast groups.
>>>
>>> Yes. What is the possible use of a link-local "join"?  The packets are just there
>>> on the link anyway, so "joining" is entirely an internal matter for each node.
>>>
>>> However, it is the case that some switches are not transparent to LL multicasts
>>> to arbitrary addresses. For example in some tests I did recently, the lab switch
>>> was transparent to ff02::1 but opaque to ff02::114.
>>
>> it was presumably snooping on MLD and did forward when it had received a join for ff02::114?
> 
> Possibly. I fixed the problem by inserting a dumb bridge that does what bridges
> are supposed to do.
> 
>> the switch designers I've spoken to state that they cannot scale for the number of multicast groups, in particular solicited node multicast. I think they often do an exception for ff02::1 and treat that as broadcast.
> 
> But why not pass all LL multicasts?
> 
> Anyway, if this is common behaviour by switches it has to be allowed for.

Now my practical question. When a host starts listening to a LL multicast address,
who or what sends the MLD Listener Report? Is the stack supposed to do so
automatically, or does the socket programmer have to do something? RFC 3810
really doesn't answer this question, and Google has been unable to help me.

A Python fragment is below to show what I am actually doing. This works
perfectly, but not when the LAN switch is filtering multicasts.

Thanks
    Brian

GRASP_LISTEN_PORT =  1021
ALL_GRASP_NEIGHBOR_6 = ipaddress.IPv6Address('ff02::114')

mcrsock = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)
mcrsock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
mcrsock.bind(('',GRASP_LISTEN_PORT))
mreq = ALL_GRASP_NEIGHBOR_6.packed + struct.pack('@I', _ll_zone_id)
mcrsock.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_JOIN_GROUP, mreq)
mcrsock.settimeout(300)
rawmsg, send_addr = mcrsock.recvfrom(2048)

---

From: Mark Smith <[email-masked]>
Date: Thu, 3 Mar 2016 08:13:02 +1100

On 3 Mar 2016 07:00, "Brian E Carpenter" <[email-masked]>
wrote:
> In the thread "Further Mitigating Router ND Cache Exhaustion DoS Attacks
Using Solicited-Node Group Membership (-01)", on
> >>>> MLD joins for the solicited node multicast address has turned out to
have little practical purpose. I am thinking of going the other way and
stop sending joins for link-local multicast groups.
> >> the switch designers I've spoken to state that they cannot scale for
the number of multicast groups, in particular solicited node multicast. I
think they often do an exception for ff02::1 and treat that as broadcast.
> really doesn't answer this question, and Google has been unable to help
me.

My expectation is the stack, and when I wrote the following a number of
years a go, I'm pretty sure I saw the (Linux) stack doing it for LL
multicasts.

https://github.com/markzzzsmith/replicast

I think the stack would have to do it unless the application had a MLD
client implementation in it to send periodic reports and to respond to MLD
router queries.

> perfectly, but not when the LAN switch is filtering multicasts.

Is any sort of active multicast filtering enabled e.g., MLD snooping?

If not, it reminds me of some ADSL DSLAMs that will pass IPv4 multicasts
but not IPv6 ones thorough "transparent LAN service" configurations.

Regards,
Mark.