From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 14:30:25 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 AF10316A4DF; Thu, 24 Aug 2006 14:30:25 +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 4CB4143D8C; Thu, 24 Aug 2006 14:30:16 +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 1GGGH0-000Lj0-9A; Thu, 24 Aug 2006 07:33:40 -0700 Date: Thu, 24 Aug 2006 07:29:23 -0400 From: Pat Lashley To: Fredrik Lindberg Message-ID: In-Reply-To: <44EDA9A5.2050108@shapeshifter.se> References: <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> <20060823212110.GD27961@lor.one-eyed-alien.net> <20060823221835.GA28978@lor.one-eyed-alien.net> <23D2619F6BACE4E728178EE5@garrett.local> <44ED3BD1.3030206@shapeshifter.se> <44EDA9A5.2050108@shapeshifter.se> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: 9dd6e96fed736b9892f077ba19b25bfcfe41deb2 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 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:30:25 -0000 > I treat LLA and mDNS as separate things. They can be used individually > or together. I see LLA as a way of configuring an IP-address while > mDNS is a way of resolving DNS-like hostnames. Don't forget service discovery. That's an important part of zeroconf, implemented via mDNS. > Howevery, your statement above brings up a question, do you assume > that a system configured with lla should be able to communicate > with a system configured via dhcp? Yes, of course. The question is basically the same as whether hosts on the same link but different IP (sub)net ranges should be able to communicate with each other. The answer is that either both hosts must implement ARP/RARP functionality, or that there be at least one additional host with addresses in both ranges that is willing to act as a router. > I would assume no, per standard IP/routing rules as they would be > in different subnets and would require a router to tell them > about each other which somehow violates the link local scope of > the 169.254/16 address space. No, it does not violate the link local scope as long as the router performs NAT to translate the 169.254/16 address into something else. And I don't think that the RFC forbids non-LLA hosts on the same link from knowing about link local addresses or communicating directly with hosts that only have LLAs. The important thing is that the link local addresses not be visible outside the link. (Which means that we may need some special purpose code in routed to prevent it from advertising 169.254/16 routes.) > Yes, discovering a NAT-router via SD is certainly possible, but I'm not > sure if this should be in the lla-daemon or in a separate program. I would expect it to be handled like any other service - it is a function of mDNS-SD, not LLA; and it is up to the service consumer to do the discovery. In this case, the consumer would be some script/utility/daemon to update the system's routing table. -Pat