[avahi] IPv6 link local addresses

Fri Jan 28 14:32:09 PST 2011

Hello,

On Tue, Mar 09, 2010 at 09:07:21PM -0800, Phil Karn wrote:
> I can see from the archives that this topic comes up occasionally, but I
> couldn't find out if there was a consensus on how IPv6 link local
> addresses (fe80::/16) should be handled when a routable IPv6 address is
> picked up.

I'm picking this quite old mail to make another plea that avahi-daemon
should announce link-local IPv6 addresses whether or not a routable IPv6
address is also available.

My argument for it is a little different from Phil's:

Since those link-local addresses exist and are used, they are also
likely to be resolved, and they *are* tried to - continuously. Here is a
small condensed 2s tcpdump snippet from one of my LANs:

| IP6 x6.5353 > ff02::fb.5353: 0 PTR (QM)? a-ll6.0.8.e.f.ip6.arpa. (90)
| IP x4.5353 > 224.0.0.251.5353: 0 PTR (QM)? a-ll6.0.8.e.f.ip6.arpa. (90)
| IP6 x6.5353 > ff02::fb.5353: 0 PTR (QM)? a-ll6.0.8.e.f.ip6.arpa. (90)
| IP x4.5353 > 224.0.0.251.5353: 0 PTR (QM)? a-ll6.0.8.e.f.ip6.arpa. (90)
| IP6 x6.5353 > ff02::fb.5353: 0 PTR (QM)? a-ll6.0.8.e.f.ip6.arpa. (90)
| IP x4.5353 > 224.0.0.251.5353: 0 PTR (QM)? a-ll6.0.8.e.f.ip6.arpa. (90)
| IP6 x6.5353 > ff02::fb.5353: 0 PTR (QM)? b-ll6.0.8.e.f.ip6.arpa. (90)
| IP x4.5353 > 224.0.0.251.5353: 0 PTR (QM)? b-ll6.0.8.e.f.ip6.arpa. (90)
| IP6 x6.5353 > ff02::fb.5353: 0 PTR (QM)? b-ll6.0.8.e.f.ip6.arpa. (90)
| IP x4.5353 > 224.0.0.251.5353: 0 PTR (QM)? b-ll6.0.8.e.f.ip6.arpa. (90)
| IP6 x6.5353 > ff02::fb.5353: 0 PTR (QM)? b-ll6.0.8.e.f.ip6.arpa. (90)
| IP x4.5353 > 224.0.0.251.5353: 0 PTR (QM)? b-ll6.0.8.e.f.ip6.arpa. (90)
| IP6 x6.5353 > ff02::fb.5353: 0 PTR (QM)? c-ll6.0.8.e.f.ip6.arpa. (90)
| IP x4.5353 > 224.0.0.251.5353: 0 PTR (QM)? c-ll6.0.8.e.f.ip6.arpa. (90)
| IP6 x6.5353 > ff02::fb.5353: 0 PTR (QM)? c-ll6.0.8.e.f.ip6.arpa. (90)
| IP x4.5353 > 224.0.0.251.5353: 0 PTR (QM)? c-ll6.0.8.e.f.ip6.arpa. (90)
| IP6 x6.5353 > ff02::fb.5353: 0 PTR (QM)? c-ll6.0.8.e.f.ip6.arpa. (90)

nss-mdns would be the perfect candidate to resolve them, but it can't
because avahi doesn't announce them if it has routable addresses.
Instead, nss-mdns is forced into timeouts because of that. Unlike
unicast DNS, unresolvable addresses put a huge burden on nss-mdns and,
in turn, on the resolving applications.

Avahi not registering, hence nss-mdns not being able to resolve
link-local addresses leads to sluggish systems, in turn.

| holbe at ideapad ~ % ip addr show | awk '/inet/ { print $2 }'
| 127.0.0.1/8
| ::1/128
| 192.168...if-a/24
| 2001:6f8:...if-a/64
| fe80::...if-a/64
| fe80::...if-b/64
| holbe at ideapad ~ % avahi-resolve -a 192.168...if-a 2001:6f8:...if-a fe80::...if-a fe80::...if-b
| fe80::...if-b        ideapad.local
| 2001:6f8:...if-a      ideapad.local
| 192.168...if-a   ideapad.local
| Failed to resolve address 'fe80::...if-a': Timeout reached
| holbe at ideapad ~ % for i in 192.168...if-a 2001:6f8:...if-a fe80::...if-a fe80::...if-b; do time getent hosts $i; done
| 192.168...if-a   ideapad.kls.lan
| getent hosts $i  0,00s user 0,00s system 0% cpu 0,046 total
| 2001:6f8:...if-a ideapad.local
| getent hosts $i  0,00s user 0,00s system 0% cpu 0,119 total
| getent hosts $i  0,00s user 0,00s system 0% cpu 5,012 total
| fe80::...if-b ideapad.local
| getent hosts $i  0,00s user 0,00s system 3% cpu 0,111 total
| holbe at ideapad ~ % 

Port 5353 generates a lot of traffic here on a really not that big LAN
| # time tcpdump -c 100 -pn port 5353
| ...
| tcpdump -c 100 -pn port 5353  0,00s user 0,03s system 0% cpu 2:26,97 total
... and the vast amount of it is failing link-local address lookups.

Of course, Phil's argument about OSX doing it different is also a good
reason to overthink avahi's behaviour regarding this. Moreover, it
proves that resolving clients must be aware to stumble upon link-local
adresses anyways.

> Right now it appears that avahi-daemon advertises the link-local address
> only when no public address is configured on the interface. This is
> counter at least to how OSX behaves. OSX continues to advertise every
> IPv6 address on the interface while avahi-daemon ceases to advertise the
> link-local IPv6 address once one or more public IPv6 addresses is
> configured.
>
> I would like to make a plea that avahi-daemon, by default at least,
> always announce link-local IPv6 addresses whether or not a publicly
> routable IPv6 address is (or addresses are) also available.
>
> It would be up to the mDNS client resolving IPv6 addresses for some
> target to choose between a public or link-local address.

Thanks for your work & regards
   Mario
-- 
The problem in the world today is communication. Too much communication.
                                                     -- Homer J. Simpson