On Mon, Oct 06, 2025 at 11:43:02AM -0400, Huang, Joseph wrote: > Some systems could not afford to flood multicast traffic. Think of some > resource-constrained low power sensors connected to a network with high > volume multicast video traffic for example. The multicast traffic could > easily choke the sensors and is essentially a DDoS attack.
Just to avoid a misunderstanding, I'm not against the idea of this patch, to make sure that an MLD query is send as soon as an IPv6 link-local address becomes available. I also agree that high multicast traffic, as it typically has no congestion control, can easily saturate low bandwidth links. Annoyingly, WLAN has a linear backoff time for multicast/broadcast packets while unicast packets haven an exponential backoff (if I recall correctly). > > > Which indeed could be optimized and is confusing, this delay could > > be avoided. Is that that the issue you mean, Joseph? > > (I'd consider it more an optimization, so for net-next, not > > net though.) > > > > I'm not sure this should be categorized as an optimization. If we never > intend to send Startup Queries, that's a different story. But if we intend > to send it but failed, I think that should be a bug. For net: https://docs.kernel.org/process/stable-kernel-rules.html#stable-kernel-rules -> "It must either fix a real bug that bothers people or just add a device ID." (But I'm also not 100% sure if this rule is applicable here.) > > > > In current implementation, :: always wins the election > > > > That would be news to me. > > > > RFC2710, section 5: > > > > To be valid, the Query message MUST come from a link- > > local IPv6 Source Address > > > > RFC3810, section 5.1.14, is even more explicit: > > > > 5.1.14. Source Addresses for Queries > > > > All MLDv2 Queries MUST be sent with a valid IPv6 link-local source > > address. If a node (router or host) receives a Query message with > > the IPv6 Source Address set to the unspecified address (::), or any > > other address that is not a valid IPv6 link-local address, it MUST > > silently discard the message and SHOULD log a warning. > > > > So :: can't be used as a source address for an MLD query. > > And since 2014 with "bridge: multicast: add sanity check for query source > > addresses" > > (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6565b9eeef194afbb3beec80d6dd2447f4091f8c) > > we should be adhering to that requirement? Let me know if I'm missing > > something. > > > > This is what I meant by ":: always wins": > > In br_multicast_select_querier(), > > if (ipv6_addr_cmp(&saddr->src.ip6, &querier->addr.src.ip6) <= 0) > goto update; Did you take into account that a :: query source should not get until here because such a query should be dropped as invalid in br_multicast_ipv6_rcv() -> ipv6_mc_check_mld()? If you've seen a :: MLD query win in the bridge in the wild though, I'd be very interested in some debug output, that shouldn't be as intended / would be a serious bug then, as it would violate the RFC mentioned above. An MLD query with :: source addres simply would not work. The Linux IPv6 host stack for instance just drops/ignores it here: https://elixir.bootlin.com/linux/v6.18.6/source/net/ipv6/mcast.c#L1450 Just as the RFC requires. (And yes, the informational RFC4541, section 3 is also broken in that regard, where it says "... should use the null IP source address (::) when sending said [non-querier general query spoofing switch] querier". That conflicts with RFC3810, section 5.1.14 or RFC2710, section 5. You won't get the MLD reports you're asking for with ::. Feel free to try :-). ) > 1. querier->addr.src.ip6 is (un)initialized(?) to 0 (I couldn't find the > place where ip6_querier.addr is initialized) br_multicast_update_querier() -> memcpy(&querier->addr, saddr, sizeof(*saddr))" ? Regards, Linus
