Hello Linus, Interesting idea; I have not see anything like this considered. In the IETF dns-sd WG the new approach is to move away from multicast by introducing a central registrar that takes service registrations, and service queries. This is DNS-SD SRP (Service Registration Protocol). So then there may not be a need to optimize the multicast approach, anymore.
You could post a message on the DNS-SD mailing list - it's quite open to discussions I think and has many of the relevant experts subscribed. https://www.ietf.org/mailman/listinfo/dnssd One caveat of the method seems to be: if one host is offering a multitude of services, it needs to subscribe to multiple IPv6 multicast addresses which brings overhead of its own - specifically MLD/MLDv2 subscriptions and desubscriptions, which cause extra multicast traffic to be sent. regards Esko -----Original Message----- From: avahi <avahi-boun...@lists.freedesktop.org> On Behalf Of Linus Lüssing Sent: Friday, January 13, 2023 21:46 To: avahi@lists.freedesktop.org Subject: [avahi] More mDNS efficiency by using multiple multicast addresses? (like ICMPv6 Neighbor Discovery) Hi, As far as I know mDNS only uses the following two multicast addresses so far: 224.0.0.251 for IPv4 and ff02::fb for IPv6. In larger broadcast domains this can create quite a bit of "noise" though. I was wondering, is anyone aware of any attempts to extend mDNS with mechanisms similar to ICMPv6 Neighbor Discovery to reduce the amount of mDNS multicast transmissions in a network? Could someone thing of any pitfalls if trying to adopt such an approach for mDNS? ICMPv6 Neighbor Discovery has this beautiful concept of solicited-node multicast addresses. Instead of broadcasting like it was done with ARP Requests in IPv4, a host's unicast address is mapped to a multicast address. When one IPv6 host wants to resolve another host's IPv6 unicast address it uses this mapped IPv6 solicited-node multicast address. Which typically only this one host listens to. That way a network with MLD snooping capabilities can efficently direct the ICMPv6 Neighbor Solicitation message with the mapped solicited-node multicast address to this one specific listener, with no burden for unrelated hosts. And for an ICMPv6 Neighbor Solicitation for Duplicate-Address-Detection (DAD) instead of address resolution there is typically even no listener at all. An MLD snooping switch can drop it immediately. So my naive thought/question would be if mDNS could use a multicast address more like ff02::fb:<hash32(service-id|dns-id)> instead (maybe even larger than just the last 32bit of the multicast address, IPv6 uses 24bits though for the solicited-node multicast address: FF02:0:0:0:0:1:FFXX:XXXX). Any thoughts? Cheers, Linus
