I think such mechanism is not required on MDNS. It instead put more
logic into having common cache and reduces number of multicast queries
sent. Only few types are used commonly and I doubt it would save
significant CPU processing. MDNS allows multiple queries in single
packet, so computing destination on queried type would be hard.
I think MDNS instead relies on cache and ability to not send some
queries often, because that state is maintained in cache. Sure, battery
operated wireless devices may save more power if they do not have to
open packets not interesting for them.
I have seen somewhere, it might have been ADD IETF group, attempt to use
local network unicast cache instead. MDNS is used just to locate local
network responder, which can be then asked over unicast. It reduces
packets processed by multiple devices, which might be way to go. Not
sure what was the name exactly.
But I doubt anyone is working on extending MDNS to hash-like link
addresses. I doubt the protocol is ready for such extension. I would say
such approach were refused during the protocol design.
Regards,
Petr
On 1/13/23 21:46, Linus Lüssing wrote:
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
--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
