Re: Working on howl port

• Previous message: Andrea Campi: "Re: Working on howl port"
• In reply to: Andrea Campi: "Re: Working on howl port"
• Next in thread: Andrea Campi: "Re: Working on howl port"
• Reply: Andrea Campi: "Re: Working on howl port"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Sat, 11 Dec 2004 15:56:33 -0500
To: Andrea Campi <andrea@webcom.it>

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:

       Reboot/startup
       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
Machines

    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?

-- 
-Chuck
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"

• Previous message: Andrea Campi: "Re: Working on howl port"
• In reply to: Andrea Campi: "Re: Working on howl port"
• Next in thread: Andrea Campi: "Re: Working on howl port"
• Reply: Andrea Campi: "Re: Working on howl port"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]