Error: Failed to load processor TracNav
No macro or processor named 'TracNav' found

Packaging avahi-autoipd

Before reading this article make sure you know what IPv4LL and DHCP are and how they work.

A few notes on packaging and installing avahi-autoipd:

Plugin for dhclient

avahi-autoipd is best used as a plugin for ISC's dhclient. To work like this you need to hook it into dhclient's action script which is called (at least on Debian) /sbin/dhclient-script. On Debian this is easily done by putting two script files into /etc/dhcp3/dhclient-enter-hooks.d/ resp. /etc/dhcp3/dhclient-exit-hooks.d/. Sample implementations for these scripts are available in GIT:

  • source:/avahi-autoipd/
  • source:/avahi-autoipd/

Those scripts make sure that avahi-autoipd is automatically started when dhclient fails to acquire an IP address via DHCP.

Similar scripts can be written for other DHCP client implementations.

Because avahi-autoipd makes a good plugin for dhclient, we encourage you to "recommend" it from the dhclient package and vice versa. (If your packaging format supports that, like Debian's does.)

Installation by default

avahi-autoipd implements an official IETF RFC (RFC3927) and has been available in MacOSX and Windows since Win98, hence we see not much reason for not enabling it by default, except of course security considerations. avahi-autoipd drops privs and chroot()s (at least on Linux), which is much more than most alternative implementations do. Hence we believe it is safe enough to enable it by default in all installations.

avahi-autoipd doesn't depend on any other Avahi library, hence it makes sense to install it even if Avahi itself is not installed.

Stand alone usage

In some sitautions it makes sense to enable only IPv4LL and not DHCP (ad-hoc networks like Bluetooth PANs, WLAN Ad-Hoc networks, eth1394 connections, USB-to-USB ethernet cables, Ethernet cross cables). For these situations make sure to allow avahi-autoipd to be used as primary IP address configuration method in your network configuration tool. "Primary" means that it is the only tool in charge for configuring the IP addreses.


To allow communication between machines which only have an IPv4LL address assigned and those which only have a routable address assigned you might want to add the following two routes to the network configuration by default:

route add -net netmask dev eth0 metric 99
route add default dev eth0 metric 99

This is recommended by Apple, however might be a security problem and might cause unnecessary ARP timeouts. The entire implications are not clear to us. Nonetheless we recommend to add these rules, since they affect communication only if no other default route is specified.

If available we encourage you to use the ip tool from the iproute package instead of the legacy route tool for these routes:

ip route add dev realtek0 metric 1000 scope link
ip route add default dev realtek0 metric 1000 scope link

These routes have to be added for every valid Ethernet interface. And need to be added on all hosts: those which have IPv4LL configured and those which do not. If they're only configured on hosts with an IPv4LL address they are worthless.

Please let me stress once more: these routes should be added to *all* Linux installations, regardless which IPv4LL implementation is used, or if one is used at all!

And please note that these routes are not necessary to allow communication between hosts where all have IPv4LL addresses assigned.

For an explanation of these routes, see  this thread.

The second route (default) needs to be set for interfaces with an IPv4LL address only. Nonetheless I recommend putting it in globally.

Multihomed hosts

Linux doesn't allow setting more than one route with the same metric that point to the same network. To work around this issue and still have kind of deterministic setup we recommend setting up the routes like this:

ip route add dev realtek0 metric $((1000 + `cat /sys/class/net/realtek0/ifindex`)) scope link
ip route add default dev realtek0 metric $((1000 + `cat /sys/class/net/realtek0/ifindex`)) scope link

This will make sure that each route will get its own unique metric and the routes don't conflict anymore. Of course, you may reach ipv4ll adresses only on one of those interface at a time, the one one with the lowest ifindex.

Modes of Operation

By default avahi-autoipd configures an IPv4LL address only if no routable address is configured. It uses the Netlink interface to listen for network configuration changes and disables/enables itself depending on those events. This has the advantage of being easy to understand for the user and causing no routing problems. However it has the disadvantage of breaking existing TCP connections to IPv4LL hosts if suddenly a routable address is configured. Nonetheless we decided to make this behaviour the default.

Alternatively the parameter --force-bind may be passed to avahi-autoipd. If this is done an IPv4LL address is assigned regardless if another routable IP address is configured. However this address is always assigned on an alias interface (if only ifconfig is available) or as a labeled IP address (if iproute is available). Most programs work fine with configurations like this, but some naive programs do not. In addition it causes some routing problems for multicasting to link local-multicast groups. And finally it seems to be difficult to understand for users. (Just see the  accumulated bug reports of the zeroconf package in Debian.) That's why we chose to not make it the default.

BTW, this page is a Wiki, you're welcome to edit it. (Requires a simple registration - no email address, nothing - just click on Register on the top right)