[avahi] IPv6 link local addresses

[Phil Karn]

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.

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.

I can see some perfectly good reasons why a mDNS client may wish to
discover and use link-local IPv6 addresses even when public, routable
addresses are available.

First, some clients, particularly certain simple embedded devices, might
not need or want to communicate beyond the local network. This could be
for security reasons. Or it could be that global connectivity is just
unnecessary baggage given the specific task of the device.

Such clients would be unable to use mDNS to resolve and communicate with
local servers that suppress their IPv6 link local addresses from mDNS
responses. A host should not be forced to implement wide-area networking
mechanisms just to talk to a local device; that's the whole idea behind
link local addresses in the first place.

Second, many public IPv6 addresses have a nasty way of changing. This
was anticipated in the design of the router advertisement protocol, so
it does indicate the interval after which the advertised prefix(es) are
no longer valid. Subsequent router advertisements usually renew this
interval indefinitely - but not always.

The possibility that the public prefix *might* change, even on networks
where that rarely or never happens, still forces every application with
a long-lived IPv6/TCP connection (or UDP-based association) to monitor
the lifetime of the global IPv6 prefix. If it is about to expire, it
must tear down the TCP connection and establish a new one with the new
global IPv6 prefix -- if one is even available. That's a lot of obvious
complexity and potential unreliability that can be completely avoided
with link-local addressing.

Even worse, an IPv6 prefix may suddenly change without warning, before
the advertised validity interval has expired. This is especially likely
when the advertising IPv6 router is a 6to4 tunnel that constructs its
IPv6 address prefix from an IPv4 address dynamically assigned to it by
an upstream ISP - and always subject to change without notice.

So it would be far easier to simply use the IPv6 link local addresses
for all local traffic whether or not a public prefix is also available.
Nodes uninterested in off-net communications would not have to listen to
IPv6 router advertisements or even implement the code to do so, and no
special precautions need be taken to ensure that intra-subnet
connections and associations could last indefinitely regardless of any
changes in (or loss of) inter-subnet connectivity.

--Phil