lathiat
Can I broadcast IPv4 address only?
I have both IPv4 and IPv6 address:
- 172.*.*.*
- fe80:*
- 2001:*
How to prevent expose public address 2001:*? Or expose IPv4 address 172.*.*.* only?
use-ipv6=no does not match the question
use-ipv6=no does not match the question
Combined with publish-aaaa-on-ipv4=no it should prevent avahi from publishing IPv6 adressess.
publish-aaaa-on-ipv4= Takes a boolean value ("yes" or "no"). If set to "yes" avahi-daemon will publish an IPv6 AAAA record via IPv4, i.e. the local IPv6 addresses can be resolved using an IPv4 transport. Only useful when IPv4 is enabled with use-ipv4=true. Defaults to "yes".
If that doesn't work could you clarify what the use case is?
It works.
But I think it would be much better to provide a filter to decide which IPs to register
Got it but according to https://datatracker.ietf.org/doc/html/rfc6762#section-6.2
When a Multicast DNS responder sends a Multicast DNS response message containing its own address records, it MUST include all addresses that are valid on the interface on which it is sending the message
so the filter wouldn't be compatible with the RFC.
As far as I can remember there is a bug in avahi where it doesn't advertise link-local IPv6 addresses when global IPv6 addresses are available. Could it be that you run into that bug?
Yes, I confirm that link-local address is not registered. This may be a facet, but not what I mainly talked about.
As for the RFC, can we give this explanation that: in some cases, the administrator may use firewall to drop all incoming packets from public address; that address is as a result unreacheable, thus invalid ?
In my case, routing to the 2001:* address will pass a gateway, which blocks all packet in specific situation. That's why I want to disable that address.
This may be a facet, but not what I mainly talked about
Got it. My guess was based on the part of this issue where it was desirable to block the global IPv6 address or allow only the IPv4 address so I assumed there were issues with the global IPv6 address. I've just found https://github.com/avahi/avahi/issues/243 and it looks like if it was fixed it wouldn't be necessary to add any filters because the devices could try all the addresses and use whatever works (in this particular case the link-local address would work as far as I understand).
the administrator may use firewall to drop all incoming packets from public address; that address is as a result unreacheable, thus invalid ?
I think it's kind of hard to maintain the list of addresses because addresses can change dynamically and it would have to be changed every time devices join new networks for example.
I see. It may be the problem, but I'm not so sure.
For example, I want to ssh to target, assume there are already 4 addresses now: [1] 2001:* [2] 2001:* (dynamic) [3] fe80:* [4] 172.*.*.* will the computer try from [1] to [4]? or just try [1] to [3]?
As far as I tested, the computer will not try to use [4].
I think it's kind of hard to maintain the list of addresses because addresses can change dynamically and it would have to be changed every time devices join new networks for example.
It is not that hard. One can just set a whitelist including fe80:* and all IPv4 addresses
will the computer try from [1] to [4]? or just try [1] to [3]? As far as I tested, the computer will not try to use [4].
It depends. Generally it should pick whatever works. If it's dual-stack and [3] works and IPv6 is preferred it's unlikely to try [4] but if it isn't reachable via IPv6 it should use [4].
As I tested, my computer will not try to connect through IPv4 when target has an IPv6 record, whether that IPv6 address is reacheable or not. Maybe this is OS related? I don't know much.
And according to what you said, if there are only [1] [2] [4], in which [1] [2] are unreacheable, the computer should try [4]. But I can't connect to target when [1] [2] is advertised. But, still, I'm not that sure.
What is tried by ssh depends on what nss modules are used for mdns on the client. If mdns6_minimal plugin is used only, ssh would never try IPv4 just as is desired. if mdns_minimal plugin is used, both should be tried. If you use mdns4_minimal on clients, they would not attempt to resolve anything on IPv6. We have that state on Fedora now, because timeout handling for both IPv4 and IPv6 is not optimal now. Try getent ahosts <hostname>.local command and see what addresses it reveals.
I think good solution for this would be configuring firewall on ssh host to drop mdns and ssh queries from hosts not on local network IPv6 prefixes. Just allow 2001:*::/64 along with link-local and ipv4 addresses. I think gateway should be that device ensuring attempts from outside are not let inside, except for allowed hosts. But yes, that would require complex intergration, not just avahi configuration.
Isn't the problem that it tries first IPv6 public address, but drops incoming request with DROP firewall rule, so it takes quite a long time for it to timeout and try next address in the list? I guess it would help at least local network clients would get REJECT rule refusal for public addresses. Then it should quickly fall back to next address, eventually also IPv4 address in the end.
But as I have written already, client configuration limiting mdns host resolution to IPv4 only might help. Fedora has:
$ grep hosts /etc/nsswitch.conf
hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns
It can help to get the issue around but the underlying issue is https://github.com/avahi/avahi/issues/243 and it should be fixed to avoid blocking IPv6 or switching to mdns4_minimal. Link-local addresses work but they are never advertised by avahi.
I agree. Including link-local addresses but placing them after public addresses should help. It might be sorted only in nss-mdns, but I guess better ordering right from avahi is better variant.
@pemensik The "firewall" is actually an example given when I was attempting to explain it as RFC-compatible. As I mentioned, it is the "gateway" that blocks the packets, and I can't control the gateway
Having thought about this I don't think it should be configurable to get around https://github.com/avahi/avahi/issues/243.
There are various workarounds mentioned here that can be used to get it around in the meantime.