[I'm CCing this back to the list, because I believe other people will
have the same questions and comments.]


qv@cs.unh.edu (Quaizar Vohra) writes:

> 
> The whole idea of neighbor discovery is to make on-link 
> communication more robust. So I think link-layer resolution should 
> be fast and hence should be within the kernel.

This has very little to do with speed.  The only time you incur extra
delay (and then only a little) when sending an IP packet is when you
have to create an ARP entry.  Once you do this, you never do it again
unless you exceed both timeout thresholds.  This will only happen if:
A) you haven't talked with that host for a long time, or B) the host
went away (which is more or less a subset of A).

Really, if you're worrying about the speed of an ARP query, then
you're ARPing *way* too often, and are probably hosing your network
into the ground.  In practice, this just isn't an issue.

> Most hosts don't
> change their default routes very often and don't use different
> routers for different networks (redirects takes care of this).
> So on hosts, link layer address resolution takes place and needs
> to be quicker without loss of invoking packets.

For packets generated from the local host, you should never even try
to send a packet until the routing information is complete.  For
packets being forwarded, you might occasionally drop one while you're
waiting for the ARP entry to come back (again, only if you haven't
talked to the host for a long time), but you'd do so with the current
model, too.  Nothing additional lost.

> Also no. of routes tend to be fewer than no. of neighbors for
> which one needs to keep link-layer info. and so one needs flushing
> and hence more link-layer soliciting.

Actually, both electrical and *sanity* limitations restrict the number
of neighbors you can have, especially on an Ethernet.  And even if you
consider huge (poorly designed) bridging networks like CMU's SCS (HI
CHRIS!), you're not talking to even a respectable fraction of the
hosts at once, so the size of your ARP table isn't really an issue.

Also, the current implementation doesn't limit the number of ARP
entries; it's perfectly willing to allocate as many as you want.  My
model would allow, if you so desire (and are willing to implement it
B-)), keeping only a cache of the most recently/frequently used
entries in the kernel, and a larger set of known entries outside,
thereby allowing you to reduce the size of the kernel routing table
without increasing the number of ARP requests you have to send.  So
you get more functionality.  (I think gated does something similar
with the IP routing table.)