In message <199608301705.NAA03689@zygorthian-space-raiders.MIT.EDU>  "Charles M. Hannum" wrote:
> 
> We have this curious assymetry in the networking code.

Agreed, 

> 
> 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.
> 
> 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 think there 2 differences here: 
    1) You need arp to use the LAN, and you can perfectly life with 
       the magic in static enviroment. Eg. if routed dies I can at
       least from a local network a connection to the machine. if the arpd
       would be dead I can start walking (or driving) to werever that guy is.
       (Yes that makes sometimes a real big difference for me :-))

    2) The arp-protocol is somehow a little bit more complicated
	eg. it has to get all arp-queries on the net and at least
	invalidate stale entries (if an arp request comes in from
	a machine I have a different arp-entry for this must be replaced
	or invalidated , because this machine could have changed its
	ethernet address for decnet or other old protocols)

	This can become a tremendous load if you have a lot of
	machines on your net, because you get context switch for
	each packet. In the kernel there is a short lookup and 99%
	of the packets are just thrown away with not much overhead.

Also I think rarp is a 'special' thing that has nothing to do with arp.
Eg. arp is a protocol to determine the MAC-address using an IP address by
asking the target machine (eg no 'central' authority) rarp is a query
to a database to get an IP-address for a system using the MAC-address as a key.

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

I can't see the advantage of replacing kernel code with mandatory user-code.
The sum of used memory is constant. Making the different methods
optional (either compile time or lkm) would further that goal too.

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

I can't see how this makes bridging trivial, but than I don't know what 
you once discussed :-)))

> 
> 
> So what do you all think?  Have I completely lost my mind?
> 

No I don't think so, it looks appealing to get consistent design, but I think 
the disadvantages are to big for the advantage of a more consistent design.

Stefan

--
Stefan Grefen                                Tandem Computers Europe Inc.
grefen@hprc.tandem.com                       High Performance Research Center
You should never bet against anything in science at odds of more than
about 10^12 to 1.
                -- Ernest Rutherford