From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 14:00:20 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 C9B3616A4DE; Thu, 24 Aug 2006 14:00:19 +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 16DBB43D45; Thu, 24 Aug 2006 14:00:18 +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 1GGFno-000LPl-6h; Thu, 24 Aug 2006 07:03:37 -0700 Date: Thu, 24 Aug 2006 06:59:11 -0400 From: Pat Lashley To: Ian Smith Message-ID: <4361C9398E9A195D2FB0B011@garrett.local> In-Reply-To: References: X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: f3aa23ad20e1cc3932a917aa9dad209a1876c77b X-Spam-User: nobody X-Spam-Score: -4.1 (----) X-Spam-Score-Int: -40 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.1 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.2 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, Doug Barton , Fredrik Lindberg 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: Thu, 24 Aug 2006 14:00:20 -0000 > I've been watching this thread with great interest, having recently been > introduced to the possibilities of OLSR (net/olsrd) for local (and > beyond) P2P wi-mesh networks, and wondering if/how zeroconf fits in. > > Some refs: My discovery point, a great (online) book found from a review > by Geoff Huston in the Internet Protocol Journal Vol 9 No 2, p44: > > Wireless Networking in the Developing World: http://wndw.net/ > OLSR.ORG: http://www.olsr.org/ > RFC: http://ietf.org/rfc/rfc3626.txt (basis, though olsrd extends this) > > Host addresses in such a MANET appear to require manual allocation so > far, usually in RFC1918 ranges, but the notion of zeroconfig-joining > such a network seems perhaps worthy of exploration? > > Am I way off base here, thinking some matchmaking might be useful? This is all off the top of my head... For a small enough mesh, with low enough latencies, I believe that you could just define the entire mesh as one link, sharing a single instance if the Link Local IP range. Everything acting as a router/bridge would have to propagate the various LLA packets throughout the mesh but avoid sending them off-mesh. OLSP or other ad-hoc routing protocols should handle that setup as well as if every host had a static IP. (I don't remember the details of LLA, but I know that mDNS needs multicast support. So you would need an ad-hoc routing mechanism that supports multicast to get a full zeroconf mesh with DNS and service discovery.) But the design would start to break down as the mesh grows large enough to either use a significant percentage of the LL address range or to make end-to-end latency significant. I can think of a couple of potential approaches to designing a federation of smaller meshes; but they all have some pretty tricky issues to resolve. I strongly suspect that it would be simpler to just build your mesh using IPv6 only; and to provide 6-to-4 (NAT?) conversion at the interfaces between the mesh and the WAN. (The IPv6 address range is large enough that every interface already has a globally unique link-local address; so no need to negotiate, defend, or change the IP addresses as things move around.) Also, I'm not familiar with OLSP; but I note that it apparently actively discovers nodes one and two hops away. It isn't clear to me how it handles routing to anything further than two hops. I also note that there are a mind-boggling number of ad-hoc routing protocols to choose from... -Pat