Hi,

I think your intent is to just move the handling of ARP messages up to
the user level and also keep a larger cache up there, while still
keeping a cache of active neighbors inside the kernel. Otherwise
you'll have a high rate of context switching, one for every packet
generated as has been pointed out. But the main problem would be
generation of ARP messages, they can't be generated via raw IP socket
and we don't have a DLPI like thing on NetBSD, or do we ???  Or you
might want to add something similar, which I think should be done and
will also help in developing test tools which would level a tool to
generate raw link-layer packets.

Now in case of Neighbor Discovery (IPV6), it uses ICMPv6 messages and
so we can use raw sockets to generate Neighbor solicitation(NS) and
Neighbor Adcertisement(NA). 

I apologize for moving this discussion in another direction but it 
would be interesting to get some feedback on this list about
implementing Neighbor Discovery on NetBSD. I am currently implementing
it in the user space.

In ND there is a notion of reachability state of a neighbor, i.e. 
REACHABLE, STALE, PROBE, DELAY, INCOMPLETE. Where STALE state implies
that the neighbor has not been used in a while. While the other states
mean that there is active communication with the neighbor. So in other
an active state the neighbor could be kept in the kernel cache, while
in the STALE state, it can be kept in a table in the user space.
Also the NS and NA mesgs. are generated by the ND Daemon and all the
details are maintained in the user space. Only active neighbors and
their link-layer addresses are kept in the kernel in a very simple
an minimalistic cache. The issue of when NS messages are generated
is very well taken care of via the notion of states by the ND Daemon
and routing sockets.

Yes I would vote for having such a daemon in /sbin.


Regards,
Quaizar