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.
Multicast-capable routers will also periodically (typically every 60 seconds) send IGMP query messages, essentially: "To all systems on this segment: report now if you're still interested in any multicast traffic." This is also a multicast IP message, sent to 220.127.116.11 = all-systems.mcast.net. This is probably what your router is sending. As the DNS name given to that address implies, all multicast-capable hosts must always listen for multicast traffic addressed to 18.104.22.168.
A multicast-capable host is supposed to send an IGMP report in two situations:
- when it wants to start or stop listening for traffic addressed to a particular multicast IP, or
- when it receives an IGMP query message.
Typically the host's kernel will handle this automatically. In Linux, you can use
cat /proc/net/igmp to see which multicast IPs your system is currently listening for on each network interface. Unfortunately the multicast IPs are reported in hexadecimal, and the byte order is reversed from the usual IP address format: for example, 22.214.171.124 is presented as "010000E0"; 126.96.36.199 is "FB0000E0".
A multicast-capable router will send IGMP queries to each network segment it's part of and keeps track of the IGMP reports it gets as a response. This is how it knows whether or not multicast traffic to some multicast IP address needs to be routed from one network segment to another.
Exception: if there is already another source if IGMP queries in a segment and it has a lower source IP address than this router, then this router will not send queries and instead will just listen. It may attempt to communicate with the other IGMP query source using some multicast routing protocol in order to coordinate multicast traffic between routers, though.
If a multicast-capable host does not answer to three consecutive IGMP queries (i.e. 180 seconds), the router assumes the host is no longer interested in any multicast traffic. This cleans up any unnecessary multicast streams if a host reboots, loses power or loses network connectivity.
In a simple home Wi-Fi network, multicasting is of limited utility: any group of hosts in a Wi-Fi network will still consume the shared radio bandwidth for everyone, whether they use multicasting or simply broadcast. But in a wired network, or in a mesh Wi-Fi network, multicasting allows switches and/or APs to monitor the IGMP messages and thus know whether a particular multicast packet needs to be sent to a particular switch port or Wi-Fi cell or not. This saves bandwidth for those that are not interested in a particular multicast, at the expense of more work for switches/APs. This feature is known as "IGMP snooping".
ps aux? My guess is that you are running
avahi-daemonor some mDNS client, but it could be another service.