Hi Esko, Thank you for your extensive reply. Please find my comments below.
On Tuesday, 7 October 2025 10:56:01 Central European Summer Time Esko Dijk wrote: > > because the clients don't have an address in the same range as the > > other addresses > > If it's IPv4: do you mean a different IPv4 subnet? In such case I would > assume the server's mDNS multicasts would be ignored by the clients > because the IPv4 source address is from another subnet. Maybe I'm wrong > here. Yes, It's unfortunaltely IPv4. Let me give you some specifics. I'm trying to support a broken protocol with some products not willing to communicate on any subnet other than 2.0.0.0/8 or 10.0.0.0/8. These products are not the clients to my services, but something like a backend for it. Unfortunately it's a widespread industry standard protocol so there's no way to fix it. My host also needs to integrate with a DHCP environment. To allow this, I assigned a generated address from each of those two ranges -- address generation is specified by the standard -- to the interface on my host as well as a DHCP-acquired address. Now when I ping myserver.local from a client (that, let's say, also acquired its address from DHCP), it resolves to an address from those two ranges and ping doesn't work. The mDNS reply when resolving the name includes all 3 addresses, but the client tends to pick the wrong one to send the pings to. > Or is there another failure case possible here? I'm thinking maybe if > the service process, on the mDNS server host, only binds to one specific > IP address and not to "all IP addresses". > This is at least something that RFC 6762 did not really consider. It > requires/assumes that an advertised service is available on all the > valid addresses of the interface. This is not the case here, but the next section applies. > Yet another failure case is when an IPv6/IPv4 address is assigned to an > interface, possibly manually or by a script, where there's no proper > router configuration to support that address. So effectively it's > assigning an invalid address to an interface. RFC 6762 says "MUST NOT > include addresses that are not valid on that interface". But when an > invalid address is explicitly configured in the OS, Avahi doesn't really > know of course that it's invalid, so having a function to filter out / > block such invalid addresses would make sense and also complies to the > standard. But it's easier to just not configure such addresses! > For me not fully clear yet if any of these cases apply to the issue you > have. Yes, exactly, this is my problem. > > Setting aside the fact that the behaviour specified by the > > standard is asking for trouble, do you have an actual solution to this? > > I think the standard was specified this way precisely to avoid the same > trouble. If only one address is included, it could be just the wrong one > that the client can't reach. If all addresses are included, the client > can either pick the matching one or try all the addresses until one works. > But I see the issue: if a client has the logic of "pick first one" it > just won't work. I was recently involved in work where > specification-wise the client would need to iterate all discovered host > addresses in preferred order (e.g. trying the 'most likely to remain > stable' addresses first) until one "worked". > However in the practical client implementation that was just skipped and > only the IPv6 link-local address was picked. It's some more work to get > the 'try all addresses' right. I could ask in the IETF dnssd WG for some > clarification. You're right. It would be the client's responsibility to pick an address that's actually reachable from all addresses included on the mDNS reply. But how to determine that is a tricky question. Maybe there should be a preference towards addresses that are in the same range as any address of the client, although nothing prevents mDNS from validly advertising global addresses which are outside of all clients' address ranges by definition. Anyway client-side behaviour is also beyond my control so the solution has to come from somewhere else. I think it would make sense for an administrator of a server to decide not to advertise certain addresses in mDNS in cases like this, once it's clear that clients will never be able to access services on those addresses due to network configuration. If this is in line with the standard, I can start working on this feature after discussing the details. Thanks for your time! -- Szabi
