If your first implementation happens to leave the interface with a 169.254 IP address, it's doing something it shouldn't, however that is likely to be mostly harmless until you or someone has a chance to improve the implementation.
If a device does keep its link local address once it obtains a lease from a DHCP server or the user manually enters an address, it is important that it stops responding to A record queries with its 169.254/16 address. Depending upon the IP implementations of the other devices on the network, the freebsd box may appear unreachable. Imagine this situation: My freebsd box initially has a link local address, it later obtains a DHCP address on 10.0.1/24. Now other devices with 10.0.1/24 addresses on the network need to use services advertised on my freebsd box. If the multicast DNS daemon on the Freebsd box responds to A record queries for its host name with the 169.254/16 address, subsequent TCP connection attempts from a device without a link local address may quite possibly fail. I believe most mDNS implementations have interfaces to the multicast DNS daemon that allow the programmer to build a list of IP addresses resolved for a hostname by interface, but I'm not sure how many people are this thorough.
Also, how is Freebsd going to handle IPv4 link local addresses on multi-homed hosts? Does FreeBSD have a notion of a "primary" interface like Mac OS X? If FreeBSD assigns v4 link-local address to all its interfaces, then the link-local address for each device on each network to which my FreeBSD device is attached must be unique across all networks, or the routing implications are obvious.
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
