Hello Szabi,
Apologies for my late reply; and thank you for detailing the use case.
It's indeed a complex case, involving various legacy components &
configurations.
I would certainly think that for this case an Avahi mDNS server can
filter out certain (IPv4/IPv6) addresses, if these addresses are
effectively invalid for the interface, from the viewpoint of the
targeted (legacy) mDNS clients.
The next question is whether Avahi would accept a PR that implements
this feature: I don't know, I'm not a part of the maintainers at this
moment, and don't know the codebase well enough to be one right now.
> 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.
That's right. On the highest level there's also the client's choice to
pick IPv4 or IPv6, in case both are queried/advertised.
In theory, when both client and server are on the same link, all of the
advertised (valid) addresses should work on that link, but in practice
it can be different.
(E.g. if the server is part of two IPv4 subnets while the client is in
only one IPv4 subnet. Or if some L2 filtering device is between
client/server.)
And when mDNS is proxied (which most implementations allow, and also
IETF is working on - Discovery Proxy RFC 8766 and Advertising Proxy
draft-ietf-dnssd-advertising-proxy-04 )
that assumption breaks.
Trying out the addresses in a certain order of the client's preference
is currently the best we've come up with.
One strategy is to prefer always the IPv6 link-local address, if
present. (In a proxied advertisement it won't be present.)
The reason is that these are expected to be most stable, not affected by
privacy techniques or temporary address schemes, that would change
global addresses from time to time.
> Maybe there should be a preference
> towards addresses that are in the same range as any address of the
client,
That makes sense: trying out the advertised server/host address first,
that has the longest-prefix-match to any of the client's configured IP
addresses.
> although nothing prevents mDNS from validly advertising global
addresses which
> are outside of all clients' address ranges by definition.
Right, in this case the client may not have a clear preference among
such addresses. If it tries to contact such IPv6 address, the source
address would be selected per regular source address selection rules
(RFC 6724).
regards
Esko
On 12-10-2025 23:13, Szabolcs Szekelyi wrote:
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!
--
*IoTconsultancy.nl* | Email/Teams: [email protected] | +31 6
2385 8339
