> 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
include:

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

Dennis Ferguson