From owner-freebsd-net@FreeBSD.ORG Fri Aug 25 21:18:58 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 36FD916A4E5 for ; Fri, 25 Aug 2006 21:18:58 +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 1EF3E43D53 for ; Fri, 25 Aug 2006 21:18:56 +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.167]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GGj7j-000DxU-T3; Fri, 25 Aug 2006 14:22:13 -0700 Date: Fri, 25 Aug 2006 17:17:34 -0400 From: Pat Lashley To: Chuck Swiger Message-ID: <2100BBD52C4028EB4DADA0CB@garrett.local> In-Reply-To: <71ABACA2-25E0-4B4F-89EA-3A70A98330E9@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> <961EF4A5A611779A598DE704@garrett.local> <5D1A78C8-674C-428D-83B6-3CD2F654A69B@mac.com> <17A034A7E9A76AA9FD37FC11@garrett.local> <71ABACA2-25E0-4B4F-89EA-3A70A98330E9@mac.com> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: aa36966b5c9d467b38378fdbacafff97597c3bc6 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 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 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 21:18:58 -0000 > > Apple's primary consumer base for Zeroconf systems doesn't normally > > have to deal with multi-homed systems; so it probably isn't much of > > a priority for them. > > Um, Pat...? > > All of the laptops Apple sells have ethernet & 802.11 wireless built in and > thus are multihomed from day one; all of the desktop & Mac mini systems being > sold are ethernet & wireless ready, and I gather that many systems are > purchased with the wireless option. Also note that Apple is also shipping > pretty much everything they sell with Firewire, which only Sony seems to do on > the PC side. Yes, I know, there are 4 Macs in my household. (And an equal number of FreeBSD machines.) I've been using the MBP to send these emails. And, for the record, neither our MacMini nor the PowerMac G4 came with WiFi installed. Apple may have made WiFi standard for new systems; but a lot of their old ones are still Ethernet-only. They may all come with both 10/100(/1000)base-T and WiFi now; but few of them actually -use- both interfaces at once; and even fewer on a single local link. So I stand by my claim that their primary customer base doesn't normally deal with multi-homing; especially not in a Zeroconf context. And yes, I do like the standard FireWire; but I don't see how it relates to the discussion at hand unless you want to talk about using it as a network link. Something that is easy enough to do; but that I suspect happens rarely in situations where more than two hosts are involved. > > They also need to maintain a higher level of easy configurability > > by non-technical users. FreeBSD's target user base leans towards > > the more technical and the more server-oriented. > > Absolutely. LLA & mDNS are targetted for ad-hoc networks which are mostly or > entirely unconfigured; FreeBSD's target user base tends to do things like > setup servers with fixed IPs and configure networks via DHCP, setting up DNS > zones, and so forth. But that doesn't mean that we necessarily -want- to have to deal with all of that. > MacOS users have a much greater demand and use for LLA & mDNS than FreeBSD > users do; after all, Apple has userland apps which take advantage of this > functionality now. So do FreeBSD users who install KDE and/or GNOME. Admittedly, not as many, nor as compelling. Yet. > > Yes, as you say, it is relevant if the host is bridging, but not if > > it is treating them as separate subnets. Which requires separate > > LLA negotiations; but I don't see where section 4 requires them to > > have separate IP addresses. (It's probably a good idea; but it > > doesn't seem to be required by section 4.) > > It's not required in section 4; see section 3, particularly 3.4. That only applies if both interfaces are on the same link. > > Multi-homed hosts are covered in section 3. Which is basically a > > discussion of some of the problems that are likely to be > > encountered; without mandating (or forbidding) any particular > > solution. > > > > Section 3.4 does require separate LL Ip addresses IF the interfaces > > are on the same link. But, as they point out, the easiest method of > > avoiding auto-immune response is to run the algorithm separately > > for each interface. In which case no special action need be taken > > to determine whether they are on the same link, or to avoid > > requesting the same address; the normal LLA negotiation will ensure > > that one of them wins and the other picks another address. > > This draft RFC doesn't actually specify that a system which has multiple > interfaces participating in LLA to each be assigned unique IPs -- presumably > because it recommends that hosts only use one interface for LLA, for example > see section 2.6.1: > > A multi-homed host needs to select an outgoing interface whether or > not the destination is an IPv4 Link-Local address. Details of that > process are beyond the scope of this specification. After selecting > an interface, the multi-homed host should send packets involving IPv4 > Link-Local addresses as specified in this document, as if the > selected interface were the host's only interface. See Section 3 for > further discussion of multi-homed hosts. But that same discussion in Section 3 appears to contradict that 'pick one' requirement. I also note that Section 2.6.1 says '...should send packets...', not '...SHOULD send packets...'; which implies that it isn't even a strong recommendation. I believe the intent of section 2.6.1 is to indicate that all of the LLA communications relevant to a given interface needs to go through that interface rather than applying the normal routing rules that were designed for more static and unique IP addresses. > > Not exactly. I think that that computes the probability that a > > newly attached host will pick an initial IP address that is already > > in use. To apply it to a pair of networks, you need to deal with > > how many hosts are on each network and the fact that within each > > network, the IPs are already guaranteed to be unique. > > > > So, given two networks, one with N hosts, the other with M; for the > > first host in N, the chance of collision is M / 65024; for the > > second it is M / 65023; etc. (Each host in N reduces the available > > address space from which the other N-hosts may be chosen; it does > > not increase the number of hosts that they must be compared > > against.) The total probability is the sum of the probabilities > > for each of the N hosts. > > Hmm, I think you've got a point-- certainly, having two networks starting with > hosts guaranteed unique IPs reduces the chances of collisions when they merge, > but you might very well be coalescing many disjoint networks rather than just > two-- consider bringing up a new wireless basestation which links multiple > smaller clouds of wireless clients, for example. But in that case you are more likely to be merging those local links into a single larger one. I'm not saying that situation will never occur; just that I believe it will be much less common. > Regardless of the actual probability, dealing with IP collisions when using > LLAs is a requirement, not something which can be passed off to be solved > later. Actually, I just thought of a simple (but not necessarily pretty) way to do it. The multi-homed host could perform NAT on the incoming packets in the 169.254/16 network, using separate NAT pools on each interface. The applications, and the bulk of the system code would only see the translated addresses, which would be routed to the right interfaces and then translated back to the correct LLA address. You could translate 169.254.x.y into 127.i.x.y, where 'i' identifies the interface; then you wouldn't even need to keep NAT tables. (To maintain RFC compliance with respect to the 127/8 network, you'd need to implement it using (additional) loopback interfaces; but that's a quibble.) And you'd need to ensure that 'i' didn't put you into a range that's already in use by some other RFC or de-facto standard. (So it shouldn't be 0, or 127.) Of course, that only handles the basic address collision issue. Service discovery in that case is still a mess. (The whole concept of handling service discovery across a NAT boundary is making me queasy.) -Pat P.S. No, that proposal is not entirely serious...