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

Alexandru Petrescu <alexandru.petrescu@gmail.com> Fri, 24 July 2015 05:04 UTC

Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1501B2DE3 for <v6ops@ietfa.amsl.com>; Thu, 23 Jul 2015 22:04:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level:
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTSREX_D2DfP for <v6ops@ietfa.amsl.com>; Thu, 23 Jul 2015 22:04:56 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A86CB1B2DDC for <v6ops@ietf.org>; Thu, 23 Jul 2015 22:04:55 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6O54o6t000781; Fri, 24 Jul 2015 07:04:50 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0F283200F18; Fri, 24 Jul 2015 07:08:28 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 01709200E05; Fri, 24 Jul 2015 07:08:28 +0200 (CEST)
Received: from [127.0.0.1] ([132.166.84.8]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6O54mDa007019; Fri, 24 Jul 2015 07:04:50 +0200
To: Owen DeLong <owen@delong.com>
References: <55AE42A4.8020908@gmail.com> <5CD05758-D7B7-476D-9936-E5A1D0614AF8@employees.org> <55B0D356.7070505@gmail.com> <6666FED5-227B-496F-B5F5-2883A12F9B96@employees.org> <55B0DB2B.1030703@gmail.com> <20150723122710.GX57117@ernw.de> <55B0E2C5.2060309@gmail.com> <20150723130151.GA57117@ernw.de> <55B0FB82.9070809@gmail.com> <B5340F82-04AA-4BD1-A1CE-BD5D0E85214F@delong.com>
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Message-ID: <55B1C770.5080301@gmail.com>
Date: Fri, 24 Jul 2015 07:04:48 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <B5340F82-04AA-4BD1-A1CE-BD5D0E85214F@delong.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/O98cQc5qIVthx1FSfKME0SYda7w>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] ref Hosts dont MLD to join LL groups
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jul 2015 05:04:58 -0000

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
>> <alexandru.petrescu@gmail.com
>> <mailto:alexandru.petrescu@gmail.com>> 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 v6ops@ietf.org <mailto:v6ops@ietf.org>
>>>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>>
>>>>
>>>> _______________________________________________ v6ops mailing
>>>> list v6ops@ietf.org <mailto:v6ops@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>
>> _______________________________________________ v6ops mailing list
>> v6ops@ietf.org <mailto:v6ops@ietf.org>
>> https://www.ietf.org/mailman/listinfo/v6ops
>