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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
