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

From: Hermin Anggawijaya <[email-masked]>
Date: Thu, 3 Mar 2016 15:29:29 +1300

On Linux, the IPv6 stack will generate MLD report (both unsolicited report
and as reply to queries) if a socket is set with IPV6_ADD_MEMBERSHIP or
IPV6_JOIN_GROUP for the given IPv6 multicast address. And looks like the
Python script should do the job.

Having seen an MLD report from a host running the Python script, I would
have thought that the
LAN switch would make the host (or the switch port the host is connected
to) to become a member of the multicast group, and the switch should
forward all multicast packets for ff02::114.

*If the corresponding multicast packets (ff02::114) are indeed filtered by
MLD snooping switch* - despite seeing the membership report sent by the
host running the script, then on some switches you could try either
(depends on availability of features):

1. disable snooping - but this could make the LAN 'chatty'
2. set the default behaviour for unknown multicast address to flood, then
apply a filter on the MLDSnooping module so that it never 'learns'
ff02::114, thus keeping ff02::114 as unknown multicast
3. add static MLD snooping entry for ff02::114 and make all the ports in
the vlan as a member.
4. add ff02::114 as a 'protocol' address to MLD Snooping so that it is
flooded properly to 'router ports' like ff02::6, ff02:6, ff02::9 etc.

Kind regards

Angga

On Thu, Mar 3, 2016 at 10:13 AM, Mark Smith <[email-masked]> wrote:

>
> On 3 Mar 2016 07:00, "Brian E Carpenter" <[email-masked]>
> wrote:
> >
> > 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.
> >
>
> 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.
>
> > A Python fragment is below to show what I am actually doing. This works
> > 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.
>
> > 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)
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: Stig Venaas <[email-masked]>
Date: Wed, 2 Mar 2016 18:44:46 -0800

Yes, the stack should take care of sending the report. In many cases
applications don't have the privileges. Also the stack knows the aggregate
state of all the sockets. Multiple applications could listen to the same
group, and in response to general  queries you also need the aggregate
state.

Stig
On Mar 2, 2016 6:29 PM, "Hermin Anggawijaya" <[email-masked]>
wrote:

>> > 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
>> > >>> However, it is the case that some switches are not transparent to
>> LL multicasts

---

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

Thanks to everyone who replied on and off list.

I've confirmed with Wireshark that Windows 7 does send appropriate
MLD2 listener reports and I am assured that Linux does so too (but
I'd need to go back in the lab to confirm that personally). So I
guess the switch involved is not processing MLD correctly. Oughta
be a law against it.

Regards
   Brian

---

From: Sonum Mathur <[email-masked]>
Date: Fri, 11 Mar 2016 16:40:35 -0800

Hi folks,
Have some questions from MLD Snooping switch point of view.

If there are no Routers involved, it is Snooping switch responsibility 
to send MLD Query to keep the groups alive on the switch.
What is the correct correct Source IP to use for General Queries ? Is it 
Src IP all 0 or some link-local Address ? Which host stack would 
like/accept what Source IP ? Have observed different observations with 
different host stacks.

Also, per discussion below - what is the right behavior for snooping 
switch when it comes to link-local multicast groups - flood or snoop ? 
It would be good to have a standard practice for this.

Thanks
--
Sonum

---

From: [email-masked]
Date: Sat, 12 Mar 2016 18:23:50 +0100

Sonum,

> If there are no Routers involved, it is Snooping switch responsibility to send MLD Query to keep the groups alive on the switch.
> What is the correct correct Source IP to use for General Queries ? Is it Src IP all 0 or some link-local Address ? Which host stack would like/accept what Source IP ? Have observed different observations with different host stacks.

see rfc4541.

> Also, per discussion below - what is the right behavior for snooping switch when it comes to link-local multicast groups - flood or snoop ? It would be good to have a standard practice for this.

it depends on the platform and how big forwarding table your switch can handle.
as far as I many switches flood,( and if you want my personal opinion, we should change hosts so that they no longer send MLD joins for link-local groups.)

Best regards,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 13 Mar 2016 07:30:18 +1300

...
> as far as I many switches flood,( and if you want my personal opinion, we should change hosts so that they no longer send MLD joins for link-local groups.)

But we can't do that unless all switches flood.

   Brian

---

From: Mark Smith <[email-masked]>
Date: Sun, 13 Mar 2016 09:47:42 +1100

> > What is the correct correct Source IP to use for General Queries ? Is
it Src IP all 0 or some link-local Address ? Which host stack would
like/accept what Source IP ? Have observed different observations with
different host stacks.
> > Also, per discussion below - what is the right behavior for snooping
switch when it comes to link-local multicast groups - flood or snoop ? It
would be good to have a standard practice for this.
> as far as I many switches flood,( and if you want my personal opinion, we
should change hosts so that they no longer send MLD joins for link-local
groups.)

And I think the people complaining about MLD for LL groups may then
complain when their hosts start receiving too many multicasts because
they're flooded.

I'd like to know more about these sorts of issues. What specific resource
is being exhausted in the switch? TCAM? How many hosts are attached to the
link - I'm wondering if, as a /64 effectively provides no limits at layer
3, people are now expecting to attach many more hosts to a link than they
would and have with IPv4.

Regards,
Mark.

---

From: [email-masked]
Date: Sun, 13 Mar 2016 21:34:30 +0100

Mark,

> And I think the people complaining about MLD for LL groups may then complain when their hosts start receiving too many multicasts because they're flooded.
> 
> I'd like to know more about these sorts of issues. What specific resource is being exhausted in the switch? TCAM? How many hosts are attached to the link - I'm wondering if, as a /64 effectively provides no limits at layer 3, people are now expecting to attach many more hosts to a link than they would and have with IPv4.

with IPv6 it isn't the number of hosts connected, it is the number of addresses used.
(and it is sometimes quite hard in IPv6 to know which addresses are still active).

it is all about carving of TCAM space.
see e.g. http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-3750-x-series-switches/data_sheet_c78-584733.html?cachemode=refresh
look for "scalability numbers"

I would assume this is a quite typical switch.

cheers,
Ole

---

From: Mark Smith <[email-masked]>
Date: Mon, 14 Mar 2016 09:32:30 +1100

Hi Ole,

> (and it is sometimes quite hard in IPv6 to know which addresses are still active).

I realise that.

In IPv4, addresses to hosts on a link has been 1:1 in nearly all
cases, and in my experience, most IPv4 subnets have been /24s (usually
facilitated by the big address space of RFC1918, and most likely for
the convenience of having an easy to work with subnet/host boundary).
So the size of most IPv4 networks has been commonly limited to no more
than ~250 hosts, which I think would have made it very unlikely that
those networks would encounter any layer 2 constraints other than
unicast bandwidth.

As IPv6 /64s lifts that ~250 host self imposed limitation, I think
we'll now experience a time and maybe are already experiencing a time
where people who don't have any other experience than
IPv4/RFC1918s/switched networks will now discover what the actual
practical limits of the number of hosts they can attach to their links
are when they deploy IPv6, and these practical limits won't always be
unicast capacity.

> look for "scalability numbers"

So I think the scalability section shows that these layer 3 inspection
functions in a layer 2 device have been optimised for IPv4, as the
number of IGMP groups and multicast routes doesn't change for any of
the modes, despite the number of unicast related capacities changing
across all the modes, and the Unicast MAC addresses capacity tripling
between the Access and VLAN modes.

IPv4 and IPv6 are obviously different enough that IPv4 focussed
optimisations aren't necessarily going to work or work as well with
IPv6. I think over time we'll see IPv6 focussed optimisations in
switches as the protocol becomes more widely deployed (perhaps a
software update to the above switch could make the IGMP groups and
multicast routes capacity change too for the different modes?)

Regards,
Mark.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 14 Mar 2016 17:30:48 +0100

Hi,

Let me take advantage of this discussion to discuss the necessity of 
this join.

Le 03/03/2016 03:29, Hermin Anggawijaya a écrit :
>
> On Linux, the IPv6 stack will generate MLD report (both unsolicited
> report and as reply to queries) if a socket is set with
> IPV6_ADD_MEMBERSHIP or IPV6_JOIN_GROUP for the given IPv6 multicast
> address.

I think linux does REPORT even though the user does not specifically
open a socket with these parameters.  Wireshark on a vanilla linux will
expose those MLD messages on LL scope.

A question that could be raised is on the necessity of this message.

On one hand, it is good for a desktop PC to inform the office switch
that it needs to be part of that group.  It helps channelling messages.

But when there are only Hosts on that link, the message is still issued
even though all Hosts must be subscribed to the LL group anyways, by
definition of the LL scope.

This may have some significance in particular mobility settings where
the medium must be free as much as possible of what could be considered
noise.  In vehicular networks the 802.11-OCB (aka 802.11p) is stripped
off of all link-layer messages like 802.11 beacons/assn/auth in order to
keep the medium as silent as possible, yet the IP MLD LL messages are
there.  These could be considered to be superfluous.  But of course the
MLD REPORTS for wider than LL scope are still needed in vehicular networks.

Alex

> And looks like the Python script should do the job.
>
> Having seen an MLD report from a host running the Python script, I
> would have thought that the LAN switch would make the host (or the
> switch port the host is connected to) to become a member of the
> multicast group, and the switch should forward all multicast packets
> for ff02::114.
>
> *If the corresponding multicast packets (ff02::114) are indeed
> filtered by MLD snooping switch* - despite seeing the membership
> report sent by the host running the script, then on some switches
> you could try either (depends on availability of features):
>
> 1. disable snooping - but this could make the LAN 'chatty' 2. set
> the default behaviour for unknown multicast address to flood, then
> ff02::114, thus keeping ff02::114 as unknown multicast 3. add static
> MLD snooping entry for ff02::114 and make all the ports in the vlan
> as a member. 4. add ff02::114 as a 'protocol' address to MLD
> Snooping so that it is flooded properly to 'router ports' like
> ff02::6, ff02:6, ff02::9 etc.
>
>
> Kind regards
>
> Angga
>
>
>
> On Thu, Mar 3, 2016 at 10:13 AM, Mark Smith <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
> On 3 Mar 2016 07:00, "Brian E Carpenter"
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>>
>> I'm sorry to distract the group with a practical question, but I'm
>> a bit stumped. My question is below.
>>
>>> On 24/02/2016 07:53,[email-masked]
>>> <mailto:[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.
>>>>
>>> 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.
>>>
>>> Anyway, if this is common behaviour by switches it has to be
>>> allowed for.
>>
>> 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.
>>
>
> 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.
>
> 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.
>
>> A Python fragment is below to show what I am actually doing. This
>> works perfectly, but not when the LAN switch is filtering
>> multicasts.
>>
>
> 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.
>
>> Thanks Brian
>>
>> GRASP_LISTEN_PORT =  1021 ALL_GRASP_NEIGHBOR_6 =
>> ipaddress.IPv6Address('ff02::114')
>>
>> 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)
>
>
> _______________________________________________ v6ops mailing list
> [email-masked] <mailto:[email-masked]>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Sonum Mathur <[email-masked]>
Date: Tue, 15 Mar 2016 00:03:30 -0700

Ole,
Thanks for the response.
RFC 4541 says SrcIP should be 'all-zeros'. But it is observed that Linux 
just drops the Query if SrcIP is not a Link-local Address. Solaris seems 
to accept anything - not sure about Windows or other stacks.

Not just for hosts, for snooping switches to inter operate, they need to 
identify each other. Otherwise we create a dis-connect between the 
snooping switches. This is when there is no Router on the subnet. If 
there is no standard IP Address, then this becomes a problem. Can't use 
'all-zeros' for MLD as Linux accepts non-zero link-local address.

Regards
--
Sonum

---

From: [email-masked]
Date: Tue, 15 Mar 2016 09:12:57 +0100

Sonum,

if it is a bug in Linux, then get that fixed.

Ole

> On 15 Mar 2016, at 08:03, Sonum Mathur <[email-masked]> wrote:
> 
> Ole,
> Thanks for the response.
> RFC 4541 says SrcIP should be 'all-zeros'. But it is observed that Linux just drops the Query if SrcIP is not a Link-local Address. Solaris seems to accept anything - not sure about Windows or other stacks.
> 
> Not just for hosts, for snooping switches to inter operate, they need to identify each other. Otherwise we create a dis-connect between the snooping switches. This is when there is no Router on the subnet. If there is no standard IP Address, then this becomes a problem. Can't use 'all-zeros' for MLD as Linux accepts non-zero link-local address.
> 
> Regards
> --
> Sonum
>

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Sat, 19 Mar 2016 13:46:19 +0100

Mark Smith wrote:
> Hi Ole,
>
>
> On 14 Mar 2016 07:34,<[email-masked]>  wrote:
>> Mark,
>>
Actually some older readers will recognise another more onerous limit to 
(IPv4) subnet size from the time before switches were invented: the 
(in)ability of end nodes to cope with incessant broadcast traffic such 
as ARP interrupting the main processor, which is why we ended up with 
ND, LL multicast group membership, and MLD in the first place.

>> it is all about carving of TCAM space.
Indeed: We've just moved the limit on L3 addresses/link somewhere else.

You still need to be able to map L3 address on this prefix -> port + MAC 
in hardware.

So it's always going to be a balance.

More TCAM and/or more multicast groups in the switch = more complexity 
and $$ in switching and simpler end nodes.

Less TCAM and/or less multicast groups in the switch = less complexity 
and $$ in switching, but end nodes that have to deal with more multicast 
or broadcast traffic when the switch moves into "all-port flooding" mode.

Note: The number of multicast filters supported in hardware on (end 
host) NIC cards is also strictly limited.

Once this limit is exceeded the card would also typically go into 
promiscuous mode, and thus interrupt the main CPU for packet processing.

See for example this (randomly chosen) NIC data sheet from an Internet 
search:
http://www.intel.nl/content/dam/www/public/us/en/documents/datasheets/ethernet-x540-datasheet.pdf

One example quoted there has as few as 16 filters for both unicast and 
multicast. Others 128. So if you're using excessive numbers of unicast 
privacy addresses concurrently (e.g. due to many long-lived sessions), 
the NIC on the end host may run out of hardware filters.

However, many NICs (including above) use input hashes in front of the 
hardware filters to attempt to reduce the impact of too many (multicast) 
filters. 
http://www.intel.com/content/dam/doc/datasheet/82574l-gbe-controller-datasheet.pdf

So it might be thought to be advantageous when implementing privacy 
addressing to minimise the number of multicast groups concurrently in 
use for each end node/NIC, to preserve switch TCAM or NIC multicast 
filters performance in hardware, whilst still maintaining a wide "enough 
spread" to confuse listeners.

But then again, 3rd party / off-link listeners could also infer a 
relationship between 2 apparently unrelated privacy addresses, based on 
computing the relevant IPv6 multicast group or NIC filter hashes 
remotely if they can guess the hardware ......

It's a utopia to think that any currently affordable hardware can cope 
with a full 64 bits of address space when filtering/forwarding.
>> see e.g. http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-3750-x-series-switches/data_sheet_c78-584733.html?cachemode=fresh

-- 
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>