>If you really want to treat a removal as temporary (i.e., keep state
>around for the removed device), and you don't want to confuse people or
>DTWT, you really have to restrict re-use of that state to the original
>hardware only.  I think this is what Jonathan was getting at. 

Yep, that's pretty much what I was getting at. (one could spoof the
original MAC address, but thats a whole nuther discussion).

I suggested MAC addresses because they really are unique, and there're
too many devices which dont have unique USB or PCMCIA tuple-space IDs.

That said: I would really like to be able to unwedge a 3c589C on
yesterday's -current by just popping it and re-inserting it.  Provided
it really is the *same* card.  What if, say, I was on a 10base2 net, I
pop out a 3c589C, and I pop in a 3c589D that doesnt *have* 10base2?

Or take the walk-down-the-hall case: Bill's idea doesn't help a bit if
my card is type X, but my neighbour has type Y: how does keeping
interface state on ne0 help at all, if what I plug in is an ep1?
Worse, what if I have two ep devices, pull them out but leave the
cables connected, and then re-insert them in reverse order?  All of a
sudden, the inet addreses and routes swapped to the wrong interface!


In all the cases I find interesting, what I really want is to pass an
event (card insertion or removal) to a userlevel daemon which someone
smart has configured to DTRT with interface and routing state,
whatever the `right thing' happens to be for *you*. In some
environments, like WaveLan, taking your IP-addr with you down the hall
is `Right'.  I can see where Bill's coming from, there.  In yet
others, you need to use DHCP to get a new address each time you plug
in. On still others, you may need something really heavyweight, like
first getting a new address via DHCP, then using mobile-IP and IPsec
to tunnel any open connections through a firewall.


One nice thing about Bill's idea is, it means yanking cards out from
under active apps doesn't make routes thorugh that i'f go away.  That
usually causes ENETUNREACH errors, and ENETUNREACH generally makes TCP
apps give up and die: not nice.  Which, AFAICT, is precisely why Linux
has the `dummy' interface. If we want a solution to disappearing
routes, that (or a routing table flag, rather than a kludged-up
interface!)  is worth investigating.

But a default that can swap IP addresses and multicast lists from one
card to another, if I pop two cards and reinsert them in the wrong
order?  No, thanks. Not unless the cards are channel-bonded.
And that's yet another discussion.