From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 21:58:47 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 5142416A4DA for ; Thu, 24 Aug 2006 21:58:47 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E71F43D70 for ; Thu, 24 Aug 2006 21:58:31 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/8.12.11/smtpout06/MantshX 4.0) with ESMTP id k7OLwUsd017215; Thu, 24 Aug 2006 14:58:30 -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/smtpin07/MantshX 4.0) with ESMTP id k7OLwIJN020127; Thu, 24 Aug 2006 14:58:29 -0700 (PDT) In-Reply-To: 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> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <22D92E8D-DE18-4883-8E77-5567AF63DFE0@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Thu, 24 Aug 2006 14:58:17 -0700 To: Pat Lashley X-Mailer: Apple Mail (2.752.2) 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: Thu, 24 Aug 2006 21:58:47 -0000 On Aug 24, 2006, at 9:20 AM, Pat Lashley wrote: >> Unless we modify the IPv4 routing code to actually know that >> different >> interfaces with LLAs are on different subnets, we will need to insure >> that there is only one interface with an LLA on it at once. The >> modification probably makes sense, but I have no idea what it would >> entail. > > 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'. Yes, the common case would be a machine like a laptop which has both an ethernet and an 802.11 wireless connectivity. If the 802.11 basestation is configured as a bridge to the wired LAN, these two interfaces are really on the same link. This implies that any multihomed system must ensure that if it configures more than one interface for LLA's, the addresses it uses are unique. > 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.) Yes, it is reasonable for a device which can bridge two different physical networks to share a single LLA subnet, but the LLA should be assigned to the virtual bridged interface, not to the underlying physical interfaces. > I think this all means that for a multi-homed host, we should not > automatically add a route for the 169.254/16 network. Instead, we > should just add specific /32s as discovered; and use ARP when we > need to find a new 169.254.x.y -> MAC translation. MacOS X has the notion of interface priorities; from RFC-3927: Mac OS X ensures that the connected interface with the highest priority is associated with the Link-Local subnet. Packets addressed to a Link-Local address are never sent to the default gateway, if one is present. Link-local addresses are always resolved on the local segment. 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. > 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. -- -Chuck