From owner-freebsd-net@FreeBSD.ORG Wed Apr 18 18:50:24 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1339C16A417 for ; Wed, 18 Apr 2007 18:50:24 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id E039713C4D3 for ; Wed, 18 Apr 2007 18:50:21 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id BAD2B217F26; Wed, 18 Apr 2007 14:50:34 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Wed, 18 Apr 2007 14:50:22 -0400 X-Sasl-enc: B9ibPfFHSqHZgEMpwaq/msgiJoRF/GB0FKiF6+PaVTWX 1176922220 Received: from [212.50.171.200] (unknown [212.50.171.200]) by mail.messagingengine.com (Postfix) with ESMTP id D079910E1A; Wed, 18 Apr 2007 14:50:19 -0400 (EDT) Message-ID: <46266861.8040907@incunabulum.net> Date: Wed, 18 Apr 2007 19:50:09 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Alan Garfield References: <1176781003.6367.12.camel@hiro.auspc.com.au> In-Reply-To: <1176781003.6367.12.camel@hiro.auspc.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: fake MAC addresses and ARP 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: Wed, 18 Apr 2007 18:50:24 -0000 Some ideas: 1. Enable IFF_STATICARP on your interface to stop ARP sending out to resolve the IP/MAC address tuple. 2. Consider that you can deal with resolution in userland (RTF_RESOLVE) but this involves changing the net's entry (route) in the FTE. You'd then process RTM_RESOLVE messages and install routes yourself -- it's possible to do arp in userland with this. 3. Try to avoid using the 169.254.0.0/16 prefix as it has a specific meaning. We don't implement interface scoping for these addresses yet so the FTE can't deal with them appearing more than once for the same subnet; it may be easier to pick something else -- note that if ARP is enabled for an interface with one of these addresses, all ARP traffic is forced to be broadcast as per the zeroconf RFCs. BMS