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

[Alexandru Petrescu <[e-mail]>]

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.

>>> 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.
>
> no. that's a decision taken somewhere in the software/stack. no need
> for any packet here.

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.

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