[pim] Re: Multicast routes to end user devices?

Toerless Eckert <tte@cs.fau.de> Fri, 17 May 2024 08:39 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A6AC1CAE0D for <pim@ietfa.amsl.com>; Fri, 17 May 2024 01:39:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.65
X-Spam-Level:
X-Spam-Status: No, score=-6.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTN0fi2GhN59 for <pim@ietfa.amsl.com>; Fri, 17 May 2024 01:39:15 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DF1FC1CAE07 for <pim@ietf.org>; Fri, 17 May 2024 01:39:13 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 4VggNr4kdlznkZW; Fri, 17 May 2024 10:39:08 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4VggNr3r6DzknhC; Fri, 17 May 2024 10:39:08 +0200 (CEST)
Date: Fri, 17 May 2024 10:39:08 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Stig Venaas <stig@venaas.com>
Message-ID: <ZkcXrCTkT7J5iTzK@faui48e.informatik.uni-erlangen.de>
References: <ZkAwrcyT1SaV6_qp@sellars> <CAHANBtLY2W=ELTjt83VGVXWpLd7wH1MF_nwCQXP3S-bFexiF_Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAHANBtLY2W=ELTjt83VGVXWpLd7wH1MF_nwCQXP3S-bFexiF_Q@mail.gmail.com>
Message-ID-Hash: GGOAFQJ7YPWPBN2B3MCU6PF2NC3DR3SD
X-Message-ID-Hash: GGOAFQJ7YPWPBN2B3MCU6PF2NC3DR3SD
X-MailFrom: eckert@i4.informatik.uni-erlangen.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-pim.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Linus Lüssing <linus.luessing@c0d3.blue>, "pim@ietf.org" <pim@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [pim] Re: Multicast routes to end user devices?
List-Id: Protocol Independent Multicast <pim.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/7e190kObx1YJ4W5joqf9g7HXVn4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Owner: <mailto:pim-owner@ietf.org>
List-Post: <mailto:pim@ietf.org>
List-Subscribe: <mailto:pim-join@ietf.org>
List-Unsubscribe: <mailto:pim-leave@ietf.org>

Wrt.: "Should a user's device then use/interpret received multicast routes"...

Threer is no obvious general purpose routing protocol that would give you that
information over the wire as in unicast. The closest we could get would be AutoRP/BSR,
but they are really only for enterprise PIM-SM and Bidir-PIM deployments, but not for
SSM/PIM-SSM. 

The most obvious policy to pick a default interface for IP multicast (send/join/receive)
would IMHO be to follow the unicast default route. i don't know why this was never
implemented. 

Indicating the presence of querier to applications, even if only across the route
socket in linux would also be helpfull, but not as much as one might think. For example,
at home, i have two Internet connections, and dual-home important hosts onto both of them
(via 2 VLANs). And the routers for them do not stop running IGMP querier just because
their uplink vanished. I am not even sure if IPv6 RA from both routers would allow
to dynamically track the better actually working Internet connection.

Given how the better Internet connection also happens to also have more outages, thats actually
a question i always wanted to look into ;-)

Cheers
    Toerless

On Mon, May 13, 2024 at 10:42:26AM -0700, Stig Venaas wrote:
> Hi Linus
> 
> Interesting questions.
> 
> I am pretty sure there is no protocol defined, ICMPv6 RA or otherwise,
> that can tell the host which interface to use for multicast.
> 
> Currently I believe most host stacks need explicit configuration, if
> this can be controlled at all. I haven't tested this in a long time,
> but I believe you can control this on Linux by modifying the routes
> you mentioned.
> 
> I have a couple of ideas on what host stacks potentially could do. One
> is to select an interface where there is an igmp querier. Also, I
> would say, prefer an interface with IGMPv3 querier if possible. Also,
> base on unicast routing, any SSM reports, IGMPv3 include mode with
> sources, could send the report on the interface that has the best
> route for the source.
> 
> Do you think it would be worthwhile allowing RAs to indicate that an
> interface should be used for multicast, or having some preference.
> What do others think?
> 
> Regards,
> Stig
> 
> On Sat, May 11, 2024 at 8:00 PM Linus Lüssing <linus.luessing@c0d3.blue> wrote:
> >
> > Hi,
> >
> > I feel a bit silly to ask, but... how is an end user's device supposed
> > to get/set its multicast routes from/to an interface?
> >
> > 1) Is an admin supposed to configure a multicast router to announce
> > multicast routes via ICMPv6 Router Advertisements?
> > 2) If yes, should/could they announce ff00::/8? Would that be the
> > multicast equivalent to ::/0?
> > 3) Should a ::/0 default route from ICMPv6 RA have any impact on a
> > user's device's multicast behaviour? (technically, this would
> > include both the unicast and multicast ranges?)
> > 4) Should a user's device then use/interpret received multicast routes
> > only for multicast transmissions (similar to unicast)? Or also for joins
> > / multicast reception? Is there an RFC that clarifies that?
> >
> >
> > I'm especially asking because on Linux there currently is the following
> > issue/inconvenience:
> >
> > For every interface it will create a multicast route in the
> > "local" table:
> >
> > ```
> > $ ip -6 route show table local
> > multicast ff00::/8 dev br0 proto kernel metric 256 pref medium
> > multicast ff00::/8 dev veth0 proto kernel metric 256 pref medium
> > multicast ff00::/8 dev veth1 proto kernel metric 256 pref medium
> > multicast ff00::/8 dev wlp1s0 proto kernel metric 256 pref medium
> > ...
> > ```
> >
> > This "local" table is separate from the default table, currently
> > ICMPv6 RA will only populate the default and not this "local"
> > table. However this local and not the default table is used both
> > for determining the interface to use for joining a routable
> > multicast address. And for multicast transmissions.
> >
> > And the second annoyance: The Linux kernel will use the first
> > multicast route / interface it can find in the "local" table,
> > if all matching routes have the same prefix length.
> > Which is typically the first interface that was created - and
> > typically that is not of any use for multicast routing for me.
> >
> > Regards, Linus
> >
> > _______________________________________________
> > pim mailing list -- pim@ietf.org
> > To unsubscribe send an email to pim-leave@ietf.org
> 

-- 
---
tte@cs.fau.de