From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 21:37:56 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 D6BE616A4E2; Thu, 24 Aug 2006 21:37:56 +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 DEDCE43D53; Thu, 24 Aug 2006 21:37:55 +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 1GGMwq-000Q0M-8O; Thu, 24 Aug 2006 14:41:18 -0700 Date: Thu, 24 Aug 2006 14:36:58 -0400 From: Pat Lashley To: Brooks Davis Message-ID: <806B67472BBA47707142E56E@garrett.local> In-Reply-To: <20060824193127.GA38855@lor.one-eyed-alien.net> References: <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> <20060824193127.GA38855@lor.one-eyed-alien.net> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: 102bbe161560b8bf980e2de6e610da09758f22fd X-Spam-User: nobody X-Spam-Score: -2.5 (--) X-Spam-Score-Int: -24 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.5 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: Thu, 24 Aug 2006 21:37:57 -0000 > > 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'. > > I can't see how it's worth worrying about the case they are on the same > network. I'm pretty sure that if you act as though they are on separate > networks things will work just as well weather they are or not. I'd have to go dig through the RFCs. I suspect that it wouldn't make any difference to the normal interface usage; but might be significant to the LLA and/or mDNS protocol handling. And we most certainly don't want to allow bridging to be enabled between the interfaces if they -are- on the same segment. > > 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.) > > If there's a bridge (only considering if_bridge here) then the bridge > interface should have the LLA. Configuring LLAs on the physical > interfaces would be wrong and isn't worth supporting. It's been a long time since I've set up a bridge; so I'm a bit rusty on all of the details. But from the if_bridge man page, it doesn't look like the bridge interface has an IP address of its own. (And I can't see why it would want one.) Also, I was using 'bridge' as a short-hand which would include any sort of proxying or routing that would make two physical segments operate as one local link for address negotiation. Overall, I don't really expect that to be a big issue; just one of those less common setups that we need to ensure does something reasonable by default. > The right way to deal with this is almost certainly to adopt the KAME > %interface decoration for link local addresses. LLAs are meaningless > outside the context of an interface. Unless you only have one interface > with an LLA, you must know which interface you are addressing to know > where to send the packet. While you can hack around this in some cases > by trying all of them and hoping there aren't any collisions, I think > that's the wrong way to go. Except in the case where multiple interfaces are on the same segment for redundancy. But in general, I suspect that you are right that using a %interface notation is the way to go. Now, how do we handle the problem in DNS-SD ? The service records just have a domain name. -Pat