We have this curious assymetry in the networking code.

We handle forward ARP queries in the kernel, using `published'
entries.  We handle reverse ARP queries through a packet sniffing
program.  When the kernel needs to send a packet to an IP address on
the network, and it doesn't already have the ether address, it issues
an ARP query itself, gets the reply, and inserts a routing table
entry.

Contrast this with IP routing.

We handle RIP requests through a user-level program.  When the kernel
needs to send a packet to a random IP address, and it doesn't already
have an IP route for it, it sends a RTM_LOSS message to the routing
socket.  The routing daemon does its magic (RIP, router discovery,
whatever) to come up with a route and then delivers it to the kernel.


I propose that we change ARP handling to use the latter model.  This
has certain advantages, in that all of the policy is then offloaded to
a user-level program.  Especially once you add FDDI, ARCnet, and Token
Ring support, it could also remove a significant amount of code from
the kernel.  And at the same time, you can get rid of the lossage that
rarpd uses BPF.

Lastly, and perhaps my real motivation B-), this makes a very simple
form of bridging that I once discussed *really* trivial to implement.


The only objection I see to this is that you need to do ARP queries
during diskless booting.  But you also need to do BOOTP and even some
IP routing, too, and we have a limited and very simple piece of code
to do so.  There's no particular reason we couldn't do the same for
ARP.


So what do you all think?  Have I completely lost my mind?