From owner-freebsd-net@FreeBSD.ORG Wed Aug 23 22:56:08 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 7155016A4DD; Wed, 23 Aug 2006 22:56:08 +0000 (UTC) (envelope-from patl@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FCB043D49; Wed, 23 Aug 2006 22:55:49 +0000 (GMT) (envelope-from patl@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 1GG1gj-000CIT-R7; Wed, 23 Aug 2006 15:59:13 -0700 Date: Wed, 23 Aug 2006 15:54:59 -0400 From: Pat Lashley To: Brooks Davis Message-ID: <23D2619F6BACE4E728178EE5@garrett.local> In-Reply-To: <20060823221835.GA28978@lor.one-eyed-alien.net> 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> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: fabf82d965fcfa3dfd949ed30a634791b406de44 X-Spam-User: nobody X-Spam-Score: -2.4 (--) X-Spam-Score-Int: -23 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: (-2.4 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 1.8 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: Wed, 23 Aug 2006 22:56:08 -0000 > DHCP+static is rather weird, but common enough that we do support it. I > suspect LLA with other address types is also of use at least some > of the time so we should ideally support it. Actually if we don't mind > always configuring a LLA I think we might support be OK right now as > long as the LLA daemon leaves non-LLA addresses alone. The LLA daemon really needs to restrict itself to the LL IP range anyway to be compliant. > The one thing > I'd be worried about is how the socket code handles connect() requests. > My hope would be that it would pick the address that goes with the > router to be used and thus the LLA would never be the source of a packet > going to a non-LLA address in normal circumstances. The RFC is pretty explicit about the need to prefer non-LLA addresses. We may need to put some explicit checks in the connect() code to enforce that preference in the aliased case. The trick, of course, is to recognize those cases where the LLA address must be used anyway. Hmmm. Interesting routing problem. Basically, we need to prefer a route that doesn't use the LLA (unless the destination is in an LLA); but still handle the edge cases like having the default route be through an LLA-only-connected router. (Which MUST do NAT...) We also need to keep an eye towards dynamic roaming. One scenario is a campus composed of multiple Link Local zones and WiFi. As you move around the campus with your (running) laptop, it will have to re-negotiate/defend its LLA; and may need to obtain a different one. The address of the default router is also likely to change as it moves from one zone to another. Of course, in that scenario it doesn't matter whether you have any non-LLA IP addresses; since you won't be using them. BUT if you add in a mix of non-LLA addresses advertised as servers; the routing adjustments could become quite interesting... Some of the problems raised by roaming scenaria need not be addressed immediately; but we do need to keep them in mind during the design phase to ensure that our solution to the basic LLA/mDNS issues doesn't make the roaming issues even harder to handle. -Pat