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

[Hermin Anggawijaya <[e-mail]>]

Hi,

On Tue, Mar 15, 2016 at 5:30 AM, Alexandre Petrescu <
[e-mail]> wrote:

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


Linux only automatically generates MLD reports on multicast capable
interfaces for 'all-nodes'
and 'all-routers' groups (if it's forwarding), with interface, link-local,
site-local scopes.

For other groups, ADD_MEMBERSHIP or JOIN_GROUP needs to be set on the
socket before report is generated.


Kind regards

Angga



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