[pim] Multicast routes to end user devices?

Linus Lüssing <linus.luessing@c0d3.blue> Sun, 12 May 2024 03:00 UTC

Return-Path: <linus.luessing@c0d3.blue>
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 6A1E1C14F5F5 for <pim@ietfa.amsl.com>; Sat, 11 May 2024 20:00:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 I2N2hGVxlKLl for <pim@ietfa.amsl.com>; Sat, 11 May 2024 20:00:03 -0700 (PDT)
Received: from mail.aperture-lab.de (mail.aperture-lab.de [IPv6:2a01:4f8:c2c:665b::1]) (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 E7DFFC14F5E3 for <pim@ietf.org>; Sat, 11 May 2024 20:00:02 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 7D52C3F35E for <pim@ietf.org>; Sun, 12 May 2024 04:59:58 +0200 (CEST)
Date: Sun, 12 May 2024 04:59:57 +0200
From: Linus Lüssing <linus.luessing@c0d3.blue>
To: "pim@ietf.org" <pim@ietf.org>
Message-ID: <ZkAwrcyT1SaV6_qp@sellars>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
X-Last-TLS-Session-Version: TLSv1.3
Message-ID-Hash: JPL57TIXHC4BXCXIQTJ26EW2BN2FEMVM
X-Message-ID-Hash: JPL57TIXHC4BXCXIQTJ26EW2BN2FEMVM
X-MailFrom: linus.luessing@c0d3.blue
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
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [pim] Multicast routes to end user devices?
List-Id: Protocol Independent Multicast <pim.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/ULFLgUK2tBTGkFu6lv9jjknaMsk>
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>

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