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

[Alexandru Petrescu <[e-mail]>]

I agree unicast RA in response to RS makes sense.  Ideally unicast RAs
in responses to unicast RSs.

Le 24/07/2015 03:28, Owen DeLong a écrit :
>
>> On Jul 23, 2015, at 07:34 , Alexandru Petrescu
>> <[e-mail]
>> <mailto:[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.

YEs.  But it's a matter of semantics.  A Host may want to act as a Host 
sometimes (join all-hosts) and as a router other times (join the 
all-routers group only).

For example, a smartphone would need to act as a Host when RS/RA but 
would need to be a router when doing 64share (stop its RSs, unsubscribe 
all-hosts, etc).

To paraphrase, that's the whole point of that being a group a multicast 
and not using broadcast - not just a fancy word.

Alex


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