From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 19:22:14 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 659C616A4E0; Thu, 24 Aug 2006 19:22:14 +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 82C5B43D69; Thu, 24 Aug 2006 19:21:30 +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 1GGKot-000ObU-4l; Thu, 24 Aug 2006 12:24:54 -0700 Date: Thu, 24 Aug 2006 12:20:39 -0400 From: Pat Lashley To: Brooks Davis Message-ID: In-Reply-To: <20060824182640.GA37561@lor.one-eyed-alien.net> References: <20060823221835.GA28978@lor.one-eyed-alien.net> <23D2619F6BACE4E728178EE5@garrett.local> <44ED3BD1.3030206@shapeshifter.se> <44EDA9A5.2050108@shapeshifter.se> <44EDBDD0.4050000@shapeshifter.se> <7CC9AC69410B69EBD31122E4@garrett.local> <44EDDB8C.9090504@shapeshifter.se> <0EC404BA0CA363942D250766@garrett.local> <20060824182640.GA37561@lor.one-eyed-alien.net> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: 5caa3080e9e177639d5e90d9ec1e125ab59782a9 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 19:22:14 -0000 > > > There is also an option to force it to assign > > >(as an alias) a LLA address even if the interface is already is > > >configured with another address. > > > > I think that I'd reverse the default on that. There should normally be no > > harm in having an LLA address, as long as we've got the non-LLA preference > > stuff working correctly. It is quite likely that the LLA address would > > never actually be used; but so what? > > Unless we modify the IPv4 routing code to actually know that different > interfaces with LLAs are on different subnets, we will need to insure > that there is only one interface with an LLA on it at once. The > modification probably makes sense, but I have no idea what it would > entail. Actually, it is quite possible for multiple interfaces to be on the same LLA link/subnet; so we can't make any assumptions either way. We -do- need to be able to handle the case where they are on different links. That really isn't an 'unless', it's a 'when'. We also need to be able to handle the case where they are on physically different links; but the host is acting as a bridge between them to make one logical link sharing a single LLA subnet. (We don't need to explicitly handle the case where the bridging is being handled externally because that should be virtually indistinguishable from a single physical link.) Our lla daemon should be tracking -all- LLA ARP requests/responses on the interfaces on which it is active. So, over time, the system will normally collect a fairly complete set of IP address <-> MAC mappings for each interface. There's no reason why the lla daemon shouldn't add those mappings to the routing table as it discovers them. (And remove them if they time out...) And that should make it easy to detect which interfaces are on the same link. So the issue mainly arises with the case where we want to open a connection to a host/service for which we have a mapping to an LLA IP address; but no mapping to a MAC address. In that case, I think we need to send an ARP request on each distinct local link for which we are using LLA. If there are multiple interfaces connected to that link, we can choose one arbitrarily. I think this all means that for a multi-homed host, we should not automatically add a route for the 169.254/16 network. Instead, we should just add specific /32s as discovered; and use ARP when we need to find a new 169.254.x.y -> MAC translation. There still remains the possibility of multiple distinct hosts having the same LLA IP address on separate local links; each attached to a separate interface. In practice that situation should be sufficiently rare that we can afford to ignore it until someone comes up with some clever way to handle it. (Or we all move to IPv6 and it becomes moot.) -Pat