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

[Owen DeLong <[e-mail]>]

> On Jul 23, 2015, at 07:34 , Alexandru Petrescu <[e-mail]> wrote:
> 
> 
> 
> 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.

No… It sends them to the ALL_HOSTS multicast group which it assumes
will reach every host on the link, since that’s the whole point of the ALL_HOSTS
multicast group when paired with LINK scope.


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

WiFi != Ethernet.

802.11 != 802.1, 802.3, etc.

Management Frames
802.11 management frames enable stations to establish and maintain communications. The following are common 802.11 management frame subtypes:



Management frames are unique to WiFi.


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

Nope… It either listens or it doesn’t. According to IPv6, a host must listen
to all hosts and a router must listen to all routers and all hosts, but that’s
merely by convention.

Nothing in the hardware.

No packets sent to say “I’m now listening for this.” It just starts listening.

It’s like changing channels on your TV…. You don’t tell the old TV station
that you’re tuning out and the new station that you’re tuning in. You just
change which frequency your local tuner is listening to.

Owen

> 
> 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
>> 
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops