[avahi] Resolve multiple IP4 Addresses
lennart at poettering.net
Fri May 8 14:15:00 PDT 2009
On Thu, 07.05.09 17:29, Mark Gollahon (mgollahon at exacq.com) wrote:
> On Thu, 2009-05-07 at 19:57:37 +0200, Lennart Poettering wrote:
> > On Thu, 07.05.09 13:09, Mark Gollahon (mgollahon at exacq.com) wrote:
> > > In my case, we are connecting to Axis cameras. Some models of Axis
> > > cameras report their configured IP address first; others report their
> > > link-local address first. Now, because of certain other design
> > > limitations and requirements that would take too much time to go into
> > > here, we have to store the camera's IP address when that camera is
> > > configured in our system. So, if during our camera detection phase,
> > > Avahi hands back the link-local address, then we're totally sunk when
> > > the link-local address changes (which does at the most inopportune time
> > > - when the camera reboots and we're trying to reconnect).
> > I am sorry, but if you use IP addresses like this it is not more than
> > an ugly hack.
> Avahi, as it is written, doesn't give me much choice in the matter! In
> my scenario, I can rely on a configured IP address much more than on a
> link-local address or even a name resolve. The link-local has a short
> lifespan (at most between reboots) and I cannot depend on "someone"
> entering name-to-ip maps into the hosts file. Therefore, it makes sense
> to store and connect to the cameras using an IP address and not the
> So, you call this an ugly hack. I do not think so, but if it is a hack,
> it is a realistic one.
I am not exactly sure I fully understand what you really want to
do. But I kind of get the idea that you should make your device
publish a service that includes some real identifcation cookie. Then,
use that cookie for id and nothing else.
Even if you do not use IPv4LL addreses, what else is there? DHCP? That
isn't much better, unless someone configured it to hand out static
My whole point is that IP addresses are not suitable for identifying
devices. If you want to identify devices use some other mechanism,
publish a service with some unique ID (MAC address?) or so.
> > IP addresses are not useful for identifying machines. IP adress can
> > change. IP addresses can be assigned to multiple machines. One
> > machine, even one network interface can have multiple IP addresses. IP
> > addresses are only unique and suitable for identification in a very
> > specific context, which is when you talk about network interfaces for
> > the use of routing on a specific network in a specific time frame.
> I agree that this is a good argument for *not* using IP addresses to
> refer to devices on a network. However, it is also a great argument
> *for* returning multiple addresses during an mDNS query. If my device
> has multiple addresses (i.e. link-local and a configured one), why not
> return all to the querying process and give it the ability to *choose*
> which way to contact the device? All of the name resolving mechanisms I
> know about have the ability to return multiple addresses to the program
> using it, all except Avahi.
Why would you want to know those addresses? Those addresses should be
used for creating connections to a device right after you resolved the
address. They cannot be assumed to be stable outside the current
network or the immediate time frame. On the local network all IP
addresses of a device can be equally used to communicate with it. If
you need a routable, stable IP address, then mDNS/DNS-SD is *not*
where you should be looking.
The way mDNS/DNS-SD is designed is that browsing, resolving,
connecting happens within the same location and timespan. If you
change location or time then you should browse and resolve again. You
seem to want to simply skip those steps then and go directly to
connecting which may work sometimes but not in the general case.
> > > Furthermore, trying to explain what that "169.x.x.x" address is or why a
> > > user doesn't see the address they configured into the camera to a user
> > > not versed in IP addressing is a complete non-starter.
> > Yes, IP addresses should generally not exposed to the user. That's why
> > host names have been invented.
> Yes, I very much agree with this statement. I would much rather deal
> with hostnames than IP addresses. However, hostnames can change, too,
> so its not the panacea you are making it out to be.
Sure, they can change. In many cases if someone changes the identity
of a device like that then he probably has a reason for that and you
shouldn't try to outsmart him. In other cases neither IP address nor
the hotname are suitable, but some other kind of ID. D-Bus' machine id
would be a good choice (/var/lib/dbus/machine-id).
> > > Therefore, saying that scenarios where an mDNS recipient needs all
> > > addresses for a given DNS name is a misuse of mDNS really is
> > > disingenuous. There really are times when we need all of the reported
> > > addresses we can get.
> > No. This is a hack. An ugly one. And a misuse of mDNS/DNS-SD.
> > This is precisely the reason why I chose not mimic the Bonjour API in
> > this aspect: people start to misuse the technology for things it
> > wasn't designed for.
> I still do not understand where the mDNS spec says anything to the
> effect of "only return one address per host even if that host reports
> multiple addresses". If it is there and I've missed it then it is my
> fault for not taking it into account. If it is not, then it was nothing
> more than an artificially limiting implementation decision and I am not
> "misusing" mDNS/DNS-SD in any way.
Hehe, it's not saying that one should only return address. But it also
isn't saying one should always return all addresses.
I already explained the technical reasons why we do things the way we
do. Also I tried to explain why this isn't a limitation (unless you
try to use mDNS/DNS-SD for something it wasn't designed for). And I
tried to point out that you are making assumptions about the stability
and uniqueness of IP addresses you shouldn't make in times of IPv4LL,
DHCP, NAT and mobile computers.
mDNS/DNS-SD is a tool for facilitate zero configuration and *ad-hoc*
networks. That's what it is good in.
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the avahi