Subject: Re: DHCP client, integration with ifconfig, etc.
To: Erik E. Fair <firstname.lastname@example.org>
From: Dennis Ferguson <email@example.com>
Date: 02/09/1997 17:00:15
> No matter what we do, kernel wise, a variety of user programs will have to
> change; in particular, no program will be able to keep a copy of the
> system's IP address, because it might change right underneath its
> proverbial nose. They'll have to check every time. Of course, the Windows &
> MacOS worlds have had to do this too, so there's no reason we can't also.
This is true, but there are also things that can be done in the kernel to
help make this easier. We have a kernel with the lowest layer of the
networking code much modified (in fact, entirely replaced) that, among
other things, tries to do what it can to help user programs overcome the
urge to store parts of the interface configuration. The biggest bits
(1) Return enough information in the recvmsg() control message buffer
that a local address appropriate for a response to the message may
be chosen by the kernel when the same control message buffer is handed
back to a sendmsg() call. This means that UDP servers (with named
and xntpd being common examples) no longer need to bind explicitly
to each local address on the machine to function properly on
multihomed hosts, the wildcard socket will suffice.
(2) Make sending broadcasts to 255.255.255.255 work so that things
which want to broadcast don't have to dig through the interface
address configuration to do it in the normal case (support for the
non-interface-specific broadcast address comes for almost for free as
a side effect of proper wire multicast support in any case).
(3) Redo the routing socket so that it can be openned by a normal
process, which can then request that notifications be sent whenever
the interface address configuration and/or the local address set
changes without receiving a bunch of other cruft as well. Asynchronous
notification means that processes can find out about changes without
having to periodically poll for an event which is unlikely to happen
anyway. Some effort must also be spent making the routing socket
reliable, or at least to provide a mechanism to cheaply detect when
messages are lost.
(4) Return errors to connected sockets when the address configuration
changes in a way which leaves the sockets orphaned.
There are other bits and pieces of work that are also useful to gain
full address independence. Being able to modify interface data structures
without leaving dangling pointers in the forwarding table is really neat
(and takes a lot of thought). Being able to configure IP up on an
interface without actually having interface addresses is also useful, at
least because it allows one to send and receive bootp/dhcp packets without
having to resort to, say, bpf. Really good IP mobility support can
also demand some odd address configurations, for example the ability to
configure a local address on an ethernet interface without specifying
a destination subnet.