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

Owen DeLong <owen@delong.com> Fri, 24 July 2015 05:10 UTC

Return-Path: <owen@delong.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 0FBB71A1A30 for <v6ops@ietfa.amsl.com>; Thu, 23 Jul 2015 22:10:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.111
X-Spam-Level:
X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 vMC6MS58gxrj for <v6ops@ietfa.amsl.com>; Thu, 23 Jul 2015 22:10:16 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 118281AC3A7 for <v6ops@ietf.org>; Thu, 23 Jul 2015 22:10:16 -0700 (PDT)
Received: from [IPv6:2620::930:0:ae87:a3ff:fe29:7192] ([IPv6:2620:0:930:0:ae87:a3ff:fe29:7192]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.2) with ESMTP id t6O5ACTd015133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Jul 2015 22:10:12 -0700
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <55B1C770.5080301@gmail.com>
Date: Thu, 23 Jul 2015 22:10:11 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <16051608-C9FF-4BF1-A6AE-0E3AB50DEE68@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> <55B1C770.5080301@gmail.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/AEMJ9dHIQIQoKlopI3LW5deR9D0>
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:10:18 -0000

> On Jul 23, 2015, at 22:04 , Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
> 
> 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).

I do not believe that is allowed under the standards. A router _IS_ a host and is supposed to be a member of the all-hosts group.

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

No. This is not true.

A host is not required to RS. But a router should not unsubscribe from all-hosts. It is not required to (and usually shouldn’t) act on RAs received on an interface for which it is an active router, but that does not mean that it can unsubscribe from the all-hosts multicast group.

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

Um… The fact of the matter is that all hosts with link scope is morally equivalent to broadcast and is also very rarely used.

Owen

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