From owner-freebsd-net@FreeBSD.ORG Fri Aug 25 17:40:21 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 B0DA616A4E9 for ; Fri, 25 Aug 2006 17:40:21 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id E320943D58 for ; Fri, 25 Aug 2006 17:40:00 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin03-en2 [10.13.10.148]) by smtpout.mac.com (Xserve/8.12.11/smtpout02/MantshX 4.0) with ESMTP id k7PHdvpY009134; Fri, 25 Aug 2006 10:39:58 -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/smtpin03/MantshX 4.0) with ESMTP id k7PHdrrm012085; Fri, 25 Aug 2006 10:39:56 -0700 (PDT) In-Reply-To: <961EF4A5A611779A598DE704@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> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5D1A78C8-674C-428D-83B6-3CD2F654A69B@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Fri, 25 Aug 2006 10:39:53 -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 17:40:21 -0000 On Aug 24, 2006, at 6:29 PM, Pat Lashley wrote: >> 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. I believe Apple creates /32 host-specific routes for Zeroconf traffic on the other interfaces, if seen. That may actually just be the normal ARP-handling code in operation rather than Zeroconf, per se, although Apple's implementation of ARP is Zeroconf-compliant in terms of timing, setting "sender IP address" (aka arphdr->ar_spa) field to all zeroes to avoid polluting other systems' ARP caches, announcing & defending LLA IP reservations, etc. 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. >>> 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. 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. 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. -- -Chuck #!/usr/bin/env python """This program computes the probability that two (or more) hosts will have an address collision. Set ip_range to 365 and this computes the 'birthday paradox'.""" ip_range = 65024 #ip_range = 365 prob = 0.0 number_of_hosts = 1 def unique(n): """Given n distinct hosts with randomly distributed addresses within the ip_range, return the probability that all will be assigned a unique address.""" if n == 1: return 1.0 else: return unique(n - 1) * (ip_range - (n - 1)) / ip_range while (prob < .5): prob = 1.0 - unique(number_of_hosts) print "Number of hosts: %d" % number_of_hosts print "Probability of IP collision: %0.4f" % prob number_of_hosts += 1