From owner-freebsd-net@FreeBSD.ORG Fri Aug 25 04:30:48 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 1B6E516A4DA for ; Fri, 25 Aug 2006 04:30:48 +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 80FD443D45 for ; Fri, 25 Aug 2006 04:30:47 +0000 (GMT) (envelope-from patl+freebsd@volant.org) Received: from ip70-171-56-90.ga.at.cox.net ([70.171.56.90] helo=[192.168.1.121]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GGTOG-0003pc-E3; Thu, 24 Aug 2006 21:34:03 -0700 Date: Thu, 24 Aug 2006 21:29:43 -0400 From: Pat Lashley To: Chuck Swiger Message-ID: <961EF4A5A611779A598DE704@garrett.local> In-Reply-To: <22D92E8D-DE18-4883-8E77-5567AF63DFE0@mac.com> 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> <22D92E8D-DE18-4883-8E77-5567AF63DFE0@mac.com> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: c3a39018b38c417fb5ac3615a033779d7854f3fc X-Spam-User: nobody X-Spam-Score: -4.3 (----) X-Spam-Score-Int: -42 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.3 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 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 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: Fri, 25 Aug 2006 04:30:48 -0000 > > 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. > > MacOS X has the notion of interface priorities; from RFC-3927: > > Mac OS X ensures that the connected interface with the highest > priority is associated with the Link-Local subnet. Packets addressed > to a Link-Local address are never sent to the default gateway, if one > is present. Link-local addresses are always resolved on the local > segment. > > Mac OS X implements media sense where the hardware and driver support > it. When the network media indicates that it has been connected, the > autoconfiguration process begins again, and attempts to re-use the > previously assigned Link-Local address. When the network media > indicates that it has been disconnected, the system waits four > seconds before de-configuring the Link-Local address and subnet. If > the connection is restored before that time, the autoconfiguration > process begins again. If the connection is not restored before that > time, the system chooses another interface to autoconfigure. But OS X also only supports Zeroconf on one interface at a time. We Can Do Better. > > 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.) > > See section 4 of RFC-3927. No, that covers merging two previously disjoint networks; I don't think that it is intended to handle the case of a multi-homed host that is connected to both of them while keeping them separate. -Pat