From owner-freebsd-net@FreeBSD.ORG Fri Aug 25 20:19:07 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 A65F016A4DE for ; Fri, 25 Aug 2006 20:19:07 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3386F43D49 for ; Fri, 25 Aug 2006 20:19:07 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/8.12.11/smtpout15/MantshX 4.0) with ESMTP id k7PKJ6ss014125; Fri, 25 Aug 2006 13:19:07 -0700 (PDT) Received: from [17.214.14.142] (a17-214-14-142.apple.com [17.214.14.142]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id k7PKJ3Pq029923; Fri, 25 Aug 2006 13:19:05 -0700 (PDT) In-Reply-To: <17A034A7E9A76AA9FD37FC11@garrett.local> 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> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <71ABACA2-25E0-4B4F-89EA-3A70A98330E9@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Fri, 25 Aug 2006 13:19:02 -0700 To: Pat Lashley X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAQAAA+k= X-Language-Identified: TRUE 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 20:19:07 -0000 On Aug 25, 2006, at 12:24 PM, Pat Lashley wrote: >> I would be entirely happy if FreeBSD could do better than MacOS >> with regard to >> this matter, but my observation suggests that the dudes working >> on this at >> Apple have a working implementation which is becoming widely used >> in userland >> applications for things like printer discovery on unconfigured >> LANs, chat, >> music sharing on the LAN (via iTunes), and for which the >> potential problems >> involved with things like multihomed machines are somewhat well >> understood. > > 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. > 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. 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. > I don't know any of the people working on Zeroconf at Apple; and > have no idea how well they have investigated the issues surrounding > multi-homed machines. Read the first few lines of http://www.faqs.org/rfcs/rfc3927.html, or look at the end: Authors' Addresses Stuart Cheshire Apple Computer, Inc. 1 Infinite Loop Cupertino California 95014, USA Phone: +1 408 974 3207 EMail: rfc@stuartcheshire.org [ ... ] >> That section covers the merging of two previously disjoint >> networks, agreed; >> for the case of connecting a multihomed host which is bridging >> them, this >> section is entirely relevant. Otherwise, LLA only deals with one >> collision >> domain (or link, etc) by definition, and one requirement which is >> relevant to >> a multihomed host is that it must ensure that the system assigns >> a different >> LLA to each interface. >> > 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. > 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. >> The probability that you will have the same LLA appear on two >> distinct subnets >> is a variant of the "birthday paradox"; there's a 10% chance of a >> collision >> with ~120 hosts, and a 50% chance of a collision with 300, >> assuming the code >> copied below is right. > > 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. 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. -- -Chuck