Re: [PATCH net] net: bridge: Trigger host query on v6 addr valid

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

quoted

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

quoted

quoted

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