what an interface *is*: e.g.,  the first ne2k on a system,
     or a specific ne2k card and MAC address?

There are signficant reasons to want to support a "reattach" model
which allows the MAC address to change.  For instance, consider the
"hot swap" case on a high-availability system, where an interface
fails, is unplugged, and a new card (with a different MAC address) is
hot-plugged in its place.

I don't have any objection to a model which allows this to work, but I
don't think it should be the default behavior, as (a) it's
significantly more complex to support, and (b) is *NOT* wanted in many
cases.  Also, the work I'm proposing takes us well along the way to
getting there.

     ... we can move to a dynamic scheme, with configuration
     controlled by a userlevel dameon which can, for example, supply a
     user-configured IP address, or run dclient when a given card,
     identified by MAC address, is inserted.  I know a *lot* of people
     who roam this way: move to a new subnet?  Pop your card and
     reinsert it, and dhclient will automagically get an address on
     the new local subnet. We dont have userlevel pccard-event
     notification yet, though, sigh.)

IMHO, the relevant event here is *not* reappearance of the hardware,
but rather reappearance of "carrier" on the LAN medium, indicating
that the net's been plugged back in (with the 802.11 cards i'm playing
with, it seems to take multiple seconds to reacquire an access point).
You can simply key off of "loss of carrier"/"reappearance of carrier"
events -- Just plug your network jack in/have your 802.11 card lock in
to the local new AP, and *poof* you reconfigure for the new network.
This works *TODAY* for IPv6 with rtsold; I suspect that backporting
this functionality into dhclient should be straightforward.

					- Bill