From owner-freebsd-net@FreeBSD.ORG Thu Feb 21 01:25:59 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B85D16A406 for ; Thu, 21 Feb 2008 01:25:59 +0000 (UTC) (envelope-from snow@teardrop.org) Received: from silver.teardrop.org (silver.teardrop.org [66.92.75.234]) by mx1.freebsd.org (Postfix) with ESMTP id 48E1C13C447 for ; Thu, 21 Feb 2008 01:25:59 +0000 (UTC) (envelope-from snow@teardrop.org) Received: by silver.teardrop.org (Postfix, from userid 100) id 24AEA9581C; Wed, 20 Feb 2008 20:06:56 -0500 (EST) Date: Wed, 20 Feb 2008 20:06:55 -0500 From: James Snow To: freebsd-net@freebsd.org Message-ID: <20080221010655.GA93480@teardrop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: 7.0 & Link-Local Addresses 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, 21 Feb 2008 01:25:59 -0000 In 6.2-Rp7: 6.2-Rp7# uname -srm FreeBSD 6.2-RELEASE-p7 i386 6.2-Rp7# ifconfig lo1 create 6.2-Rp7# ifconfig lo1 inet 169.254.1.1 netmask 255.255.0.0 6.2-Rp7# ping -c1 169.254.1.1 PING 169.254.1.1 (169.254.1.1): 56 data bytes 64 bytes from 169.254.1.1: icmp_seq=0 ttl=64 time=0.065 ms --- 169.254.1.1 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.065/0.065/0.065/0.000 ms 6.2-Rp7# But in 7.0-RC2: 7.0-RC2# uname -srm FreeBSD 7.0-RC2 amd64 7.0-RC2# ifconfig lo1 create 7.0-RC2# ifconfig lo1 169.254.1.1 netmask 255.255.0.0 7.0-RC2# ping -c1 169.254.1.1 PING 169.254.1.1 (169.254.1.1): 56 data bytes --- 169.254.1.1 ping statistics --- 1 packets transmitted, 0 packets received, 100.0% packet loss 7.0-RC2# I'm trying to use link-local for the cross-over interface between a pair of FreeBSD boxes running pf, pfsync, and CARP. These firewalls will need to be able to route for the whole of RFC1918, and carving off a piece of that address space isn't an option. This seemed to be a perfect scenario for link-local addresses until I ran into the above problem. RFC 3927 states, in section 1.6 (Alternate Use Prohibition): "Note that addresses in the 169.254/16 prefix SHOULD NOT be configured manually...." So I'm not sure if this is a bug or just RFC compliance. -Snow