>> We handle forward ARP queries in the kernel, [...].
>> Contrast this with IP routing.
>> We handle RIP requests through a user-level program.  [...]

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

And you don't have to do ARP, either; you can wire down your whole ARP
table at boot time.  In a secure environment (whatever _that_ means)
you may well _prefer_ to do so.

> There still needs to "some" arp in the kernel (caching the mbuf that
> caused us to do an ARP).

You don't _have_ to cache that packet.  But the kernel _does_ need to
know a _little_ about ARP; you don't want to have to context-switch to
your userland daemon for every packet, so the kernel has to know enough
ARP to cache frequently used ARP entries.  (Note that this is true of
IP routing as well: the kernel knows enough about routes that you don't
take a context switch to the routing daemon for every packet.)

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

Wellll...yeah, except that the "limited and very simple piece of code"
is significantly simpler than a full IP routing daemon, but the code
that would be required to ARP for the boot host (or next-hop gateway,
if booting through a gateway) is roughly as complex as the code that
would be required to do full ARP queries in normal operation.

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

Presumably we'd acquire the notion of an ARP socket, akin to the
routing socket.  It would have to hear about any Ethernet interfaces
going up or down, but that can be handled.

Now, one final note: despite all the above, I don't really like the
notion of moving ARP out into user-land.  It feels too much like
something that really belongs in the Ethernet device drivers, and was
pulled out of them only to improve code sharing...and then got re-used
for similar address resolution protocols on other media.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu
		    01 EE 31 F6 BB 0C 34 36  00 F3 7C 5A C1 A0 67 1D