[avahi] avahi-autoipd

[Lennart Poettering]

Hi!

Avahi 0.6.14 will ship with its own implementation of IP4LL
(rfc3927).

Right now the code has been tested on Linux only. Dear
Solaris/FreeBSD/MacOSX porters, please start your compilers and port
this new tool to your respective platforms!

avahi-autopid currently uses the Linux specific Netlink interface for
subscribing to certain network configuration change events. This is
much more limited and different than what avahi-daemon does with
Netlink, therefore i chose to reeimplement the necessary calls and not
reuse avahi-core's netlink code. However this means that the specific
code needs to be ported to other systems in a similar way as the
original avahi-core was.

Why did we add avahi-autoipd to Avahi, although other implementations
were already available, such as Anand Kumria's "zeroconf", or "zcip"
or Arthur van Hoff's "AVH-IPv4LL.c", or GNOME's NetworkManager?

- First, it was the last component that was missing to make Avahi
a full-fledged Zeroconf stack.

- It is one of the few free implementations that actually implements
the spec in its entirety and passes the Bonjour compatibility suite.

- It's clearly the most powerful and secure implementation:

- It drops priviliges
- It chroot()s
- It saves and restores the last used IP address to /var/lib/ to
make sure that the IP addresses stay as stable as possible.
- It tries to stay out of the way of the user by only configuring an
IP address if no other routable address has been configured.
- It has a man page!
- It is intended to be run as plugin for the ISC dhcp client, only
if no DHCP server is available. (the support for this is only
enabled on Debian right now because others systems seem to lack
the necessary hook directories for dhclient.)
- And lots of other stuff

- It was fun to implement!

You can disable building of avahi-autoipd by passing --disable-autoipd
on the "configure" command line. In fact, it will probably fail to
build on non-Linux systems if this option is not passed to configure.

Please report back if you plan to port avahi-autoipd to a specific OS
in time for 0.6.14 (targeted for end of next week sometimes).

The code is in SVN, subdirectory "avahi-autoipd".

It is my goal to make avahi-autoipd the definitive implementation of
iPv4ll for Linux. To reach this the binary does not depend on any
avahi-specific libraries.

Have fun!

Lennart

[chris mcharg]

Post by Lennart Poettering
Hi!
Avahi 0.6.14 will ship with its own implementation of IP4LL
(rfc3927).

That's great news Lennart.
I think busybox has a reasonably new implementation, but it will be
great to have a solid/current daemon for desktop users.
It would be nice if the linux distributions pick this up so we can
have ip4ll as standard.

One thing I'd like to note (something I picked up from the busybox
mailing list), is that if you allow the dhcp client to kill autoipd
when it sets a routable ip address, it's possible that current tcp
transmission taking place with the ip4ll address will just be cut. A
possible resolution for this was to start the ip4ll daemon on an ip
alias for the same interface that the dhcp client is trying to obtain
an address for, and then just leave it running there after the
routable address is set (It seems that the routable address is
selected over the ip4ll address automatically?). Do you have any
thoughts on this?

Cheers,

Chris

[Lennart Poettering]

On Sun, 03.09.06 14:00, chris mcharg (***@outtrack.org) wrote:

Hi!

Post by chris mcharg
One thing I'd like to note (something I picked up from the busybox
mailing list), is that if you allow the dhcp client to kill autoipd
when it sets a routable ip address, it's possible that current tcp
transmission taking place with the ip4ll address will just be cut. A
possible resolution for this was to start the ip4ll daemon on an ip
alias for the same interface that the dhcp client is trying to obtain
an address for, and then just leave it running there after the
routable address is set (It seems that the routable address is
selected over the ip4ll address automatically?). Do you have any
thoughts on this?

avahi-autoipd supports two different modes: the default mode is to
assign an IPv4LL address only if no other routable address is
configured. That means that IPv4ll is deactivated as soon as a
routable address is added to the iface and activated again soon as a
it is removed again.

This mode is of course "vulnerable" to the problems you mentioned
above. However this mode is probably the mode that will confuse people
the least and causes the least routing problems. That's why I chose to
make it the default.

Alternatively you can pass "--force-bind" to avahi-autoipd. If you do
this IPv4LL will be activated even when a routable address is already
assigned to the interface. This will fix the problems you mentioned
above, however might be confusing to people (see Debian bug #302684)
and makes routing non-trivial. (multicast routing that is, such as
what is needed for mDNS)

The actual interface configuration is done by an action script which
is called whenever an IPv4LL address needs to be added or removed from
the network interface. This is similar to the way ISC's dhclient
works.

The default action script uses Linux' iproute tool for adding the
address to the the network interface. The address is added with link
local scope and is labeled "eth0:avahi". For the legacy IP
configuration tools such as "ifconfig" such an address will show up as
alias interface "eth0:avahi".

With minor changes on the action script you could create a mode where
zeroconf is only activated when no other address is configured, but
the zeroconf address is left on the interface, even after a routable
address is configured later in time. This however I would consider
"configuration" and is as such left to the user/administrator.

Lennart

[chris mcharg]

Hi again,

Just to make sure I've got all of this ok...

autoipd gets its chance to run and set an ipv4ll address when
dhclient fails for some reason to set a routable address, and with
the default script it can then get killed when dhclient obtains an ip
address lease. On top of this, by default autoipd can remove the
ipv4ll address when a routable address has somehow been set (by
monitoring Netlink events?). If a user/admin wants to ensure tcp
transmission doesn't get cut during a switch from ipv4ll to routable,
they can use --force-bind so the Netlink events have no effect, and
also alter the dhclient hook script so autoipd is not killed.

Does that sound right?

A couple of other things...

Apple has this page on mixed routable and ip4ll addresses:
http://developer.apple.com/qa/qa2004/qa1357.html
I have no idea of the default routing settings of most of the linux
distributions, but it seems debian at least doesn't have the settings
for responding to a host with an ipv4ll address when a routable
address is set. Do you have any plans for providing defaults/
guidance for these?

In the current avahi-autoipd.action script, a label is set when using
the ip tool, but no alias is defined when setting the address with
ifconfig. Was there a reason for that? (sorry... I don't know a lot
about interface labels/aliases)

Sorry for all the questions,

Chris

Post by Lennart Poettering
avahi-autoipd supports two different modes: the default mode is to
assign an IPv4LL address only if no other routable address is
configured. That means that IPv4ll is deactivated as soon as a
routable address is added to the iface and activated again soon as a
it is removed again.
This mode is of course "vulnerable" to the problems you mentioned
above. However this mode is probably the mode that will confuse people
the least and causes the least routing problems. That's why I chose to
make it the default.
Alternatively you can pass "--force-bind" to avahi-autoipd. If you do
this IPv4LL will be activated even when a routable address is already
assigned to the interface. This will fix the problems you mentioned
above, however might be confusing to people (see Debian bug #302684)
and makes routing non-trivial. (multicast routing that is, such as
what is needed for mDNS)
The actual interface configuration is done by an action script which
is called whenever an IPv4LL address needs to be added or removed from
the network interface. This is similar to the way ISC's dhclient
works.
The default action script uses Linux' iproute tool for adding the
address to the the network interface. The address is added with link
local scope and is labeled "eth0:avahi". For the legacy IP
configuration tools such as "ifconfig" such an address will show up as
alias interface "eth0:avahi".
With minor changes on the action script you could create a mode where
zeroconf is only activated when no other address is configured, but
the zeroconf address is left on the interface, even after a routable
address is configured later in time. This however I would consider
"configuration" and is as such left to the user/administrator.
Lennart

[Lennart Poettering]

On Mon, 04.09.06 22:07, chris mcharg (***@outtrack.org) wrote:

Hi!

Post by chris mcharg
autoipd gets its chance to run and set an ipv4ll address when
dhclient fails for some reason to set a routable address, and with
the default script it can then get killed when dhclient obtains an ip
address lease. On top of this, by default autoipd can remove the
ipv4ll address when a routable address has somehow been set (by
monitoring Netlink events?). If a user/admin wants to ensure tcp

Yes, by monitoring Netlink (at least on Linux).

Post by chris mcharg
transmission doesn't get cut during a switch from ipv4ll to routable,
they can use --force-bind so the Netlink events have no effect, and
also alter the dhclient hook script so autoipd is not killed.
Does that sound right?

Yes, it does.

One addition though:

When used as dhclient plugin avahi-autoipd is started from a dhclient
action script (On Debian it is known as
/sbin/dhclient-script). However, avahi-autoipd's network configuration
itself is done also with an action script
(/etc/avahi/avahi-autoipd.action).

To keep the IPv4LL adress on the interface even after a routable
adderss has been configured you have two options: first, do as you
said and don't kill avahi-autoipd in dhclient-script, or second,
modify avahi-autoipd.action and don't remove ip address from the
interface if the script is called requesting just that.

Post by chris mcharg
http://developer.apple.com/qa/qa2004/qa1357.html
I have no idea of the default routing settings of most of the linux
distributions, but it seems debian at least doesn't have the settings
for responding to a host with an ipv4ll address when a routable
address is set. Do you have any plans for providing defaults/
guidance for these?

I'll leave this up to the distributions.

Honestly I believe that their claim "Most modern Linux distributions
already include full IPv4 link-local support" is not true.

I see the point for adding these routing table entries,
though. Although I am sure they're not without problems. Adding these
rules will force the usage of ARP for all destinations that do not
have an explicit route defined. This will cause ARP timeouts and might
be a security hole. However the impact of this is not entirely clear
to me.

But yes, I would suggest following Apple's suggestion here and add this
routes to the default network configuration scripts.

To be effective these routes must be added to *all* network hosts, not
just those where IPv4LL is used. It might be problematic to convince
the distribution maintainers to add these routes by default.

Post by chris mcharg
In the current avahi-autoipd.action script, a label is set when using
the ip tool, but no alias is defined when setting the address with
ifconfig. Was there a reason for that? (sorry... I don't know a lot
about interface labels/aliases)

No specific reason. It's just that "labels" are not a 1:1 translation
of alias interfaces.

I will have a look into this. Stay tuned.

Post by chris mcharg
Sorry for all the questions,

You're welcome!

Lennart

[Marc Krochmal]

Post by Lennart Poettering

Post by chris mcharg
http://developer.apple.com/qa/qa2004/qa1357.html
I have no idea of the default routing settings of most of the linux
distributions, but it seems debian at least doesn't have the settings
for responding to a host with an ipv4ll address when a routable
address is set. Do you have any plans for providing defaults/
guidance for these?

I'll leave this up to the distributions.
Honestly I believe that their claim "Most modern Linux distributions
already include full IPv4 link-local support" is not true.

I'll take the blame for that. I was the one who wrote that article
and I thought it was true.

Post by Lennart Poettering
I see the point for adding these routing table entries,
though. Although I am sure they're not without problems. Adding these
rules will force the usage of ARP for all destinations that do not
have an explicit route defined. This will cause ARP timeouts and might
be a security hole. However the impact of this is not entirely clear
to me.

These routes only take affect when you have no other routes
configured, so as long as you have a router address configured, these
entries will not be used. Mac OS X ships with these routes by default
and I've never heard of any reported issues with them.

-Marc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/avahi/attachments/20060904/23e6eb71/attachment.html

[chris mcharg]

Hi Marc

Post by Marc Krochmal
These routes only take affect when you have no other routes
configured, so as long as you have a router address configured,
these entries will not be used. Mac OS X ships with these routes
by default and I've never heard of any reported issues with them.

Plus anyone who has itunes installed on windows has these routes
maintained as well, right??

Since it's such a good chance, would you mind checking if my
understanding of the two routes is on track? ...

-- route add default dev eth0 metric 99 --

This makes sure that data bound for routable addresses is dumped via
eth0 even when we only have a ipv4ll address, as the routable
addressed host should be able to respond to us. As such, it only
needs to be set when we have our ipv4ll address set.

-- route add -net 169.254.0.0 netmask 255.255.0.0 dev eth0 metric 99 --

This ensures that we respond to ipv4ll addressed hosts even when we
have a routable address set. Therefore, it should be set by default
at boot.

I'm still new to networking in general, so there's a good chance that
the above is not right, but I'm really enjoying getting to know my
way around just by playing with avahi/bonjour.

Cheers,

Chris

[Lennart Poettering]

Post by chris mcharg
-- route add default dev eth0 metric 99 --
This makes sure that data bound for routable addresses is dumped via
eth0 even when we only have a ipv4ll address, as the routable
addressed host should be able to respond to us. As such, it only
needs to be set when we have our ipv4ll address set.

Yes, that's how I understood it.

Post by chris mcharg
-- route add -net 169.254.0.0 netmask 255.255.0.0 dev eth0 metric 99 --
This ensures that we respond to ipv4ll addressed hosts even when we
have a routable address set. Therefore, it should be set by default
at boot.

That's mostly right. However this route is not explicitly necessary if
an IPv4LL address is assigned, because a route like this one is
implicitly added by the kernel in that case anyway.

In other words: the first route allows packet flow from a
IPv4LL-only hosts to a host with only a routable address. And the
second route allows the packet flow in the other direction.

The trick is to set the metric to 99 which makes sure that the routes
only take effect if no other routing is configured and allows them to
be set in all cases, with or without IPv4LL configured, without any
drawbacks.

As long as only IPv4LL-only hosts want to communicate, or as long as
only hosts with routable address want to communicate neither of the
routes is required.

Lennart

[chris mcharg]

Thanks for the confirmation Lennart, it's very much appreciated.

Chris

Post by Lennart Poettering

Post by chris mcharg
-- route add default dev eth0 metric 99 --
This makes sure that data bound for routable addresses is dumped via
eth0 even when we only have a ipv4ll address, as the routable
addressed host should be able to respond to us. As such, it only
needs to be set when we have our ipv4ll address set.

Yes, that's how I understood it.

Post by chris mcharg
-- route add -net 169.254.0.0 netmask 255.255.0.0 dev eth0 metric 99 --
This ensures that we respond to ipv4ll addressed hosts even when we
have a routable address set. Therefore, it should be set by default
at boot.

That's mostly right. However this route is not explicitly necessary if
an IPv4LL address is assigned, because a route like this one is
implicitly added by the kernel in that case anyway.
In other words: the first route allows packet flow from a
IPv4LL-only hosts to a host with only a routable address. And the
second route allows the packet flow in the other direction.
The trick is to set the metric to 99 which makes sure that the routes
only take effect if no other routing is configured and allows them to
be set in all cases, with or without IPv4LL configured, without any
drawbacks.
As long as only IPv4LL-only hosts want to communicate, or as long as
only hosts with routable address want to communicate neither of the
routes is required.
Lennart
--
Lennart Poettering; lennart [at] poettering [dot] net
ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/
_______________________________________________
avahi mailing list
http://lists.freedesktop.org/mailman/listinfo/avahi

[Lennart Poettering]

Post by chris mcharg
http://developer.apple.com/qa/qa2004/qa1357.html
I have no idea of the default routing settings of most of the linux
distributions, but it seems debian at least doesn't have the settings
for responding to a host with an ipv4ll address when a routable
address is set. Do you have any plans for providing defaults/
guidance for these?

I now added a reference to this article to avahi-autoipd's man page:

http://avahi.org/changeset/1318

Thank you for the tip!

Post by chris mcharg
In the current avahi-autoipd.action script, a label is set when using
the ip tool, but no alias is defined when setting the address with
ifconfig. Was there a reason for that? (sorry... I don't know a lot
about interface labels/aliases)

I modified the default action script to configure a classic alias
interface if only ifconfig is available:

http://avahi.org/changeset/1319

Thanks for your suggestions!

Lennart

[chris mcharg]

Hi

Post by Lennart Poettering
http://avahi.org/changeset/1318

[...]

Post by Lennart Poettering
I modified the default action script to configure a classic alias
http://avahi.org/changeset/1319

Thats great!

I have a feeling good clear documentation will go a long way to
getting avahi-autoipd into the distributions. I guess you were
planning on it anyway, but I'm sure it would be good to have a decent
page on the trac wiki for this too.

Chris

[Lennart Poettering]

Post by chris mcharg
I have a feeling good clear documentation will go a long way to
getting avahi-autoipd into the distributions. I guess you were
planning on it anyway, but I'm sure it would be good to have a decent
page on the trac wiki for this too.

No, actually I hadn't planned that. ;-)

However, I now added a new page to the wiki describing the optimal
integration of avahi-autoipd and IPv4LL into distributions.

This is partially based on some emails I sent the debian maintainers
of Debian earlier and on the discussions we had on this mailing list.

http://avahi.org/wiki/AvahiAutoipd

It's a wiki, so you're welcome to edit it.

Lennart

[chris mcharg]

Post by Lennart Poettering
However, I now added a new page to the wiki describing the optimal
integration of avahi-autoipd and IPv4LL into distributions.
This is partially based on some emails I sent the debian maintainers
of Debian earlier and on the discussions we had on this mailing list.
http://avahi.org/wiki/AvahiAutoipd
It's a wiki, so you're welcome to edit it.

That's a fairly decent rundown... so good in fact that I can't think
of anything I would like to add :)