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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
