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