Matt Thomas <matt@lkg.dec.com> writes:

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

So?  AFAIK, on at least ARCnet, ARP is also optional.  Hell; one could
envision building MAC addresses from IP addresses and tossing ARP
completely, but I wasn't going to mention that.  (Obviously this
wouldn't be scalable to IPv6.  And obviously you have to maintain
compatibility with any legacy systems you have.)

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

Probably.

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

No.  As I discussed already, this would have no effect on how many
packets we lose while building the ARP table.

> > 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 idea is more or less `bridging by massive proxy ARP'.  It's
simple, and it would work.  Obviously, in this case you wouldn't want
the whole proxy ARP table in the kernel.  You'd also need a way of
issuing ARP requests and seeing the replies from the user-level
daemon.

> Other issues include deciding how to notify the daemon that it should
> be hanlding an ARP request?

The routing socket interface already handles this with RTM_LOSS.