From owner-freebsd-net@FreeBSD.ORG Wed Aug 23 20:32:41 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 0007B16A4E1; Wed, 23 Aug 2006 20:32:40 +0000 (UTC) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4962B43D53; Wed, 23 Aug 2006 20:32:39 +0000 (GMT) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id B32C91A78D; Wed, 23 Aug 2006 22:32:37 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14692-01; Wed, 23 Aug 2006 22:32:36 +0200 (CEST) Received: from [192.168.1.100] (217-208-33-252-o926.tbon.telia.com [217.208.33.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id C89301A751; Wed, 23 Aug 2006 22:32:35 +0200 (CEST) Message-ID: <44ECBB61.9020808@shapeshifter.se> Date: Wed, 23 Aug 2006 22:32:33 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.4 (X11/20060727) MIME-Version: 1.0 To: Doug Barton 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> In-Reply-To: <44ECB0F2.9040300@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at h3q.net 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 20:32:41 -0000 Doug Barton wrote: > > I find it very interesting. :) One of my side projects at the moment is to > come further up to speed on the subject of multicast DNS in general, so I'm > following this discussion with a great deal of interest. I'd really like to > see FreeBSD take a lead in this area, since the more research I do the more > I am convinced that this, or something very much like it is the future of > end-user network provisioning. > > 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? NetBSD had a SoC a year ago I think, don't think anything has been imported into their tree. I've used some parts of it in my lla implementation. Don't know about OpenBSD nor about Dragonfly. > 2. What are the linux flavors doing? It appears that the Avahi (http://avahi.org/) responder is the current leader, it's API compatible (client wise) with mDNSResponder. > 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.) At a minimum LLA and basic mDNS (apple has some exotic wide area extensions). LLA is probably easiest to begin with. > 4. What are the nice to haves? IMHO, mDNS. > 5. How does mDNS cooperate/integrate with IPv6? Just as well as with IPv4, at least to my knowledge. > 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 client API compatible with the one from Apples mDNSResponder as it seems to be the de facto standard. The client API header file is BSD-licensed. A nss module would probably be just another responder client, either using Apples API or any API of our choice (depends on how we implement the responder). > 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?) As for lla, it's really zeroconfig by nature and more or less dhcp without a server. A suitable configuration is something such as LLA in the ifconfig_if0="" line in rc.conf (similar to DHCP or WPA). As for mDNS/SD I think a generic responderd.conf/mdns.conf file should be available where you can configure "static" dns records. Programs will be able to register/announce records through the client API (it talks to the responder via a unix pipe socket). Various utilities should be available so that an administrator is able to add/remove records from the command line and via scripts. > 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? It's best to go with Apples API from mDNSResponder. > 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.) See previous answer. Supporting different APIs might be possible but not as a start. > 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? > This is where the Service Discovery protocol comes in, it runs on top of mDNS and are basically just dns records peers announce when they would like to tell the world about services they are providing. Having such utility would probably be nice. As for mDNS and hostname in generic, users would interact with them just as with any other dns records or name. > ... and that's just off the top of my head. :) > > In order to move this forward my idea would be to get the answers to these, > and any other crucial questions hashed out fairly thoroughly here first. > Then we could post a summary to -arch, preferably along with a link to some > running code, so that it would get wider (and better) review. > > So I'm not promising that it'll go in overnight, but I _do_ want something > along this line to go in, so as I said, if no one else steps forward, I'm on > the case. It's nice that others have seen the zeroconfig light :) > > Brooks, if you're reading this, can I count on you to broach the question > about the Apache license in core@? > I've already written quite a lot of BSD licensed code and some parts of Apples mDNSResponder is under a BSD license (client api part). If we mix these together we might be able to avoid the Apache license, but it's of course nice to get a definitive answer on the Apache license. (And maybe my code turns out to be useless... :)) Fredrik Lindberg