[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
- [pim] Multicast routes to end user devices? Linus Lüssing
- [pim] Re: Multicast routes to end user devices? Stig Venaas
- [pim] Re: Multicast routes to end user devices? Toerless Eckert
- [pim] Re: Multicast routes to end user devices? Brian Haberman
- [pim] Re: Multicast routes to end user devices? Linus Lüssing