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

I would love to see the proxy arp stuff move out of the kernel and 
into a daemon.

> 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 believe the above analogy in flawed.  We handle routing protocols
in a user daemon because there are lots of different routing protocols.
And because not everyone listens to them (I diable routed on my systems).

Redirects are handled in the kernel.  Should they be moved to a daemon
as well?

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

There still needs to "some" arp in the kernel (caching the mbuf that
caused us to do an ARP).  Another reason to move ATM out of the kernel
is ATM ARP.  If ATM ARP is in a user process, it makes much easier to
have the signalling code in user-space as well.

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

IP bridging?  Sounds evil :-).

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

Other issues include deciding how to notify the daemon that it should
be hanlding an ARP request?  How does it learn all the addresses that
it need to respond to?  

-- 
Matt Thomas               Internet:   matt@3am-software.com
3am Software Foundry      WWW URL:    http://www.3am-software.com/bio/matt.html
Westford, MA              Disclaimer: I disavow all knowledge of this message