It’s not really against the rules as you say, because it is not really normal traffic. I thought this explanation was pretty good:
Multicast IP traffic has different rules from the ordinary unicast or broadcast traffic. A multicast IP address is never used as a source address: it is always a destination address only. A system that is sending multicasts will use its regular IP address as the source address. Each multicast IP address will designate a multicast group: anything sent to that multicast address will be received by all hosts belonging to that group. (Or that’s the theory. In practice, unless you’ve made specific arrangements to route multicasts beyond your subnet or organization, multicast traffic tends to stop at those limits by default.)
When some software in a host wants to receive multicast traffic, it will tell the host’s kernel “I wish to receive multicasts addressed to this multicast IP address.” The kernel will then add that multicast IP address to the list of multicast addresses it will listen for, and send out an IGMP report message: "I wish to receive multicast traffic addressed to these multicast IPs: ". This IGMP report is itself a multicast IP message. In Linux, IGMP is handled at the kernel level: this is why you see no processes responsible for it.
The explanation goes on a bit actually; you can read the rest in this thread: https://unix.stackexchange.com/questions/425786/incoming-and-outgoing-traffic-when-nothing-is-running
One likely explanation for the fact that your device is sending out multicast traffic is:
Systemd-resolved has a built-in mDNS service. You can disable it if you wish by setting MulticastDNS=false in resolved.conf. More here: https://man.archlinux.org/man/resolved.conf.5