From owner-freebsd-net@FreeBSD.ORG Sun Dec 12 23:25:30 2004 Return-Path: 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 DE09216A4CE for ; Sun, 12 Dec 2004 23:25:30 +0000 (GMT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id A96E743D4C for ; Sun, 12 Dec 2004 23:25:30 +0000 (GMT) (envelope-from pheerboth@apple.com) Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id iBCNXVIJ020609 for ; Sun, 12 Dec 2004 15:33:31 -0800 (PST) Received: from relay1.apple.com (relay1.apple.com) by mailgate1.apple.com ; Sun, 12 Dec 2004 15:26:44 -0800 Received: from [17.219.205.121] ([17.219.205.121]) by relay1.apple.com (8.12.11/8.12.11) with ESMTP id iBCNPCcj004992; Sun, 12 Dec 2004 15:25:13 -0800 (PST) In-Reply-To: <41BB40B7.5000907@mac.com> References: <20041211090235.GD11190@webcom.it> <41BAC0BD.7000706@mac.com> <20041211102825.GB12803@webcom.it> <41BB40B7.5000907@mac.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1B251E0B-4C95-11D9-A057-000393CFACB0@apple.com> Content-Transfer-Encoding: 7bit From: Peter Heerboth Date: Sun, 12 Dec 2004 15:25:27 -0800 To: Chuck Swiger X-Mailer: Apple Mail (2.619) cc: Andrea Campi cc: net@freebsd.org Subject: Re: Working on howl port X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2004 23:25:31 -0000 I'm not a zeroconf expert per se, but I would love to see FreeBSD have a great zeroconf implementation. Here are some things to think about. > > If your first implementation happens to leave the interface with a > 169.254 IP address, it's doing something it shouldn't, however that is > likely to be mostly harmless until you or someone has a chance to > improve the implementation. If a device does keep its link local address once it obtains a lease from a DHCP server or the user manually enters an address, it is important that it stops responding to A record queries with its 169.254/16 address. Depending upon the IP implementations of the other devices on the network, the freebsd box may appear unreachable. Imagine this situation: My freebsd box initially has a link local address, it later obtains a DHCP address on 10.0.1/24. Now other devices with 10.0.1/24 addresses on the network need to use services advertised on my freebsd box. If the multicast DNS daemon on the Freebsd box responds to A record queries for its host name with the 169.254/16 address, subsequent TCP connection attempts from a device without a link local address may quite possibly fail. I believe most mDNS implementations have interfaces to the multicast DNS daemon that allow the programmer to build a list of IP addresses resolved for a hostname by interface, but I'm not sure how many people are this thorough. Also, how is Freebsd going to handle IPv4 link local addresses on multi-homed hosts? Does FreeBSD have a notion of a "primary" interface like Mac OS X? If FreeBSD assigns v4 link-local address to all its interfaces, then the link-local address for each device on each network to which my FreeBSD device is attached must be unique across all networks, or the routing implications are obvious.