From owner-freebsd-net@FreeBSD.ORG Wed Aug 23 21:13:29 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B0F616A4DD; Wed, 23 Aug 2006 21:13:29 +0000 (UTC) (envelope-from patl+freebsd@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4B6C43D45; Wed, 23 Aug 2006 21:13:28 +0000 (GMT) (envelope-from patl+freebsd@volant.org) Received: from adsl-065-081-071-131.sip.gnv.bellsouth.net ([65.81.71.131] helo=[192.168.1.121]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GG05Q-000BKd-A3; Wed, 23 Aug 2006 14:16:52 -0700 Date: Wed, 23 Aug 2006 14:12:20 -0400 From: Pat Lashley To: Doug Barton , Fredrik Lindberg Message-ID: In-Reply-To: <44ECB0F2.9040300@FreeBSD.org> References: <44E9F991.7020309@shapeshifter.se> <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: 2b3bb6b7b9800778ff3876abd230e8b8c1994aa6 X-Spam-User: nobody X-Spam-Score: -4.2 (----) X-Spam-Score-Int: -41 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-4.2 points total, 5.0 required) 0.1 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date 0.1 AWL AWL: Auto-whitelist adjustment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Zeroconfig and Multicast DNS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 21:13:29 -0000 > 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