Zeroconfig and Multicast DNS

[Pat Lashley]

> If no one else steps forward, I will be glad to lead the charge to get an
> implementation of this committed. Before I do though, we'll need to get some
> basic questions answered (some of which have already been discussed here).
>
> 1. What are the other *BSDs doing in this area?
> 2. What are the linux flavors doing?
> 3. What is the minimal set of features we should support? (I think this list
> starts with LLA, but that's just a gut feeling atm.)

I would agree that LLA is part of the minimal set; and as I mentioned before, 
it is the only part for which there is currently no FreeBSD solution. It should 
be possible to enable LLA on a per-NIC basis in rc.conf; and it should be 
possible to have both LLA and non-LLA addresses on the same port so that a 
FreeBSD host can easily operate in a mixed environment. (This also makes it 
easier for portable machines to handle being moved between a zeroconf-based 
environment and a more traditional DHCP environment.)

Determining a minimal set of mDNS-based features is a little more difficult. 
Unless I've missed something, I'd say that the mDNSResponder feature set isn't 
quite sufficient; because it provides no mechanism to advertise services which 
are provided by daemons that aren't explicitly mDNS-aware. (But adding such a 
utility using libdns_sd should be trivial.)

I really think that we need to treat the LLA and mDNS portions of Zeroconf as 
separate projects. Defining the feature set and system interactions for LLA 
should be much easier than for mDNS; so hopefully we can get the code for that 
integrated while still working on the mDNS portion.

> 4. What are the nice to haves?

For the mDNS-based portsions, see the Avahi feature and to-do lists... :-)

(Some more FreeBSD-specific items are mentioned below.)

> 5. How does mDNS cooperate/integrate with IPv6?

It should be possible to separately enable/disable IPv4 and IPv6 support in our 
mdns daemon. Other than that, it is my understanding that there really isn't 
any significant difference between them as far as mDNS and mDNS-SD goes.

(As most of you are aware, there is no need for an IPv6 Link Local Address 
daemon because Link Local addresses are already built into IPv6.)

There is the question of whether to propigate mDNS records between IPv4 and 
IPv6. The current best advice seems to be to avoid that except in unusual 
circumstances. So if we allow it at all, it should be controlled by a knob that 
defaults to OFF.

> 6. How should the mDNS system integrate with the rest of the FreeBSD system?
> I think at minimum anything we import should support nss, but what else do
> we need here?

A utility to add/remove service advertisements via the command-line; and 
integration of it into the rc.d scripts of our service daemons. (At least until 
those daemons are made mDNS-aware.)

A command-line service browser would also be nice.

I'm not sure whether we want to try to do things like add advertised lpd 
services to the printer list; or if it would be better to leave that sort of 
thing to the ports. (Where it is already being handled by at least parts of 
GNOME, KDE, etc.)

> 7. How should the sysadmin interact with this, and what knobs should they be
> able to twiddle? (LLA address parameters, definitions of unique services,
> access limitations ala hosts.allow?)

There really aren't any LLA address parameters to twiddle. The address range is 
specified by the RFC.

You'll want to be able to enable/disable LLA on a per-interface basis. You may 
want to be able to specify whether to obtain/keep an LLA if an other IP address 
is obtained for the interface via some other mechanism.

It would be nice to be able to specify which interfaces the mDNS should operate 
on; but I'm not sure whether it would be cleaner to make it a list of those to 
include or those to exclude. In either case, wild cards should be allowed to 
handle dynamic interfaces. (E.g., You might want to run and propigate mDNS 
across a tun-based VPN, despite the potential latency issues that would dictate 
that the default should be no mDNS for any type of Point-to-Point link.)

For a multi-homed machine, you want to be able to specify whether or not to 
propagate the LLA and mDNS info across both links or treat them separately. 
(The default should be separate; propagation must be handled with extreme care 
to avoid problems.)

I would add a knob to each service to say whether or not it should advertise 
via mDNS. (E.g., sshd_mdns_advertise="YES") For services that use the mDNS 
library, that knob can be converted into a command-line parameter; for others, 
a small block in the rc.d script that uses the utility I mentioned above.

The existing access limitation mechanisms should be sufficient.

> 8. How should applications interact with this system? That includes stuff in
> the FreeBSD base, and what APIs to publish for third party stuff. Are there
> well established APIs that we should/must support?

The mDNSResponder API seems to be a sort of least-common-denominator. Avahi 
provides API compatibility shims for it. But KDE, GNOME, Apache, et. al. seem 
to have gone with Avahi. We should strive for API/ABI compatibility with one or 
both of those.

> 9. At some point we have to bring the ports guys in on this too, with a goal
> in mind of determining what features we'd need to support in the base to
> eliminate the need for an mDNS implementation in ports. (The fact that we
> currently have 2, slightly incompatible implementations in ports now is
> already giving me a headache.)

Make that three: mDNSResponder, gmdns, and avahi. As I mentioned above, Avahi 
has mDNSResponder API compatibility; and appears to be the one most widely used 
by major projects. If we want to eliminate mDNS ports; then I think we need to 
go for supporting both the mDNSResponder and Avahi APIs.

But note that Avahi includes some Gtk-based tools; so we'd probably still need 
an 'avahi-tools' port to provide the bits that we don't support in our 
implementation.

> 10. How do users interact with this? Should there be a utility that allows
> users to browse the network to see what services are available?

Yes, a fairly simple command-line browser would be nice; especially if the 
output is designed to be easily parsed and handled by scripts.



-Pat