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

I don't intuit quite how this is supposed to work on a multi-homed
host.  To which interface(s) should the all-ones broadcast be sent?



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

That's one way; a signal is another. Signals can be an `nicer' hook
than to add to existing applications than polling.  But there aren't
any more signals available, unless we grow expand sigmask.

But asynchronous I/O on a readonly routing socket (with a signal
indicating an interface change is available) could do almost as well.


>(4) Return errors to connected sockets when the address configuration
>    changes in a way which leaves the sockets orphaned.

Yup. Though for an app blocked on a read that isn't going to complete,
a signal would be more useful.  Or is that a case where you'd return
an error?  Just in passing, there are more cases than `address
expired' that want errors.  In a mobile world, having an interface
physically removed from the machine could, perhaps, be treated the
same way as an expired address.

I suspect that mobility is an area where it's possible to have
different models of what `proper' functionality, as seen by users, is;
and those different models can lead to different decisions about what
the correct technical (kernel-level) decisions are.  The functionality
I tend to assume is one where a mobile user often has a choice of
available media, with different latency, bandwidth, and price
trade-offs, with some attempt to use these `intelligently'.

(That said, more flexibility is usually good.)