Date: Wed, 20 Feb 2008 20:06:55 -0500 From: James Snow <snow@teardrop.org> To: freebsd-net@freebsd.org Subject: 7.0 & Link-Local Addresses Message-ID: <20080221010655.GA93480@teardrop.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080221010655.GA93480>