Working on howl port
cswiger at mac.com
Sat Dec 11 12:56:37 PST 2004
Andrea Campi wrote:
> On Sat, Dec 11, 2004 at 01:47:19PM -0500, Chuck Swiger wrote:
[ ... ]
>> autoipd and DHCP/dhclient should never get into a fight, nor should autoipd
>> conflict with a manually-assigned network config: autoipd should only try
>> to configure a link-local address during the interval when nothing else has
>> done so, or if autoipd has reason to believe that the existing
>> configuration is invalid (ie, after the carrier drops). Any time dhclient
>> gets a lease and assigns an IP address to an interface, autoipd needs to
>> back out of the way.
> Uhm. Yes, link state changes and possibly other events can
> reasonably be used for this. I guess I can use route change
> notifications from dhclient to notice something's up.
The program ought to register for those, yes, and for interface link up/down
messages (RTM_ADD, RTM_IFINFO, etc from "man 4 route").
> Actually, all this is nifd's business, not autoipd proper; the
> two work in concert.
OK. I am more familiar with zeroconf in terms of what it expects
ARPOP_REQUEST and _REPLY to look like, and stuff like that, than I am with the
two programs you have mentioned. :-)
> Just to check my assumptions: is it reasonable to assume autoipd
> has total control over the 169.254 block? I don't want to have to
> bother about preserving any existing address in that range etc.
No, it is not reasonable. Although if you make that assumption for the first
implementation, it's probably mostly harmless again. However, zeroconf
software needs to work as if it has no control over network allocation, and it
needs to test the network to see whether a candidate IP address is already
being used by something else...ARP-probing safely before it can claim a
link-local IP address:
"2.2. Claiming a Link-Local Address
After it has selected an IPv4 Link-Local address, a host MUST test to
see if the IPv4 Link-Local address is already in use before beginning
to use it. When a network interface transitions from an inactive to
an active state, the host does not have knowledge of what IPv4 Link-
Local addresses may currently be in use on that link, since the point
of attachment may have changed or the network interface may have been
inactive when a conflicting address was claimed.
Were the host to immediately begin using an IPv4 Link-Local address
which is already in use by another host, this would be disruptive to
that other host. Since it is possible that the host has changed its
point of attachment, a routable address may be obtainable on the new
network, and therefore it cannot be assumed that an IPv4 Link-Local
address is to be preferred.
Before using the IPv4 Link-Local address (e.g. using it as the source
address in an IPv4 packet, or as the Sender IPv4 address in an ARP
packet) a host MUST perform the probing test described below to
achieve better confidence that using the IPv4 Link-Local address will
not cause disruption.
Examples of events that involve an interface becoming active include:
Wake from sleep (if network interface was inactive during sleep)
Bringing up previously inactive network interface
IEEE 802 hardware link-state change (appropriate for the
media type and security mechanisms which apply) indicates
that an interface has become active.
Association with a wireless base station or adhoc network.
A host MUST NOT perform this check periodically as a matter of
course. This would be a waste of network bandwidth, and is
unnecessary due to the ability of hosts to passively discover
conflicts, as described in Section 2.5."
...and then it details the specific way to perform an ARPOP_REQUEST probe that
all hosts on the local subnet will see without polluting their arp cache with
wrong IP info. You might also want to consider this section:
"2.11. Interaction between DHCPv4 client and IPv4 Link-Local State
As documented in Appendix A, early implementations of IPv4 Link-Local
have modified the DHCP state machine. Field experience shows that
these modifications reduce the reliability of the DHCP service.
A device that implements both IPv4 Link-Local and a DHCPv4 client
should not alter the behavior of the DHCPv4 client to accommodate
IPv4 Link-Local configuration. In particular configuration of an
IPv4 Link-Local address, whether or not a DHCP server is currently
responding, is not sufficient reason to unconfigure a valid DHCP
lease, to stop the DHCP client from attempting to acquire a new IP
address, to change DHCP timeouts or to change the behavior of the
DHCP state machine in any other way."
Consider the positive side, however: things a developer is restricted from
implementing are tasks which don't have to be done, so to some extent the job
becomes easier. Also, my memory suggests that the way FreeBSD generates and
responds to ARP traffic is basicly what zeroconf would like to see, although
the timeout algorithms and such are not identical.
Anyway, perhaps my responses would be more helpful if you explained the use
case you are trying to get going, first?
More information about the freebsd-net