Working on howl port

[Peter Heerboth]

I'm not a zeroconf expert per se, but I would love to see FreeBSD have 
a great zeroconf implementation.  Here are some things to think about.

>
> 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.