Stefan Grefen <grefen@hprc.tandem.com> writes:

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

True, but:

1) One would hope that it doesn't die.  If the code is buggy, it's
just as easy (if not more so), and just as dangerous (if not more so),
for it to be buggy in the kernel.

2) Actually, the routing table would probably (depending on how one
chose to implement it) be left in the state that it was when the
program died.  In the all too common case of some dork mistyping a
`kill' command, you'd still have an ARP entry for whatever machine
you're connected from.

3) Most people I know connect the console of Really Important machines
to a terminal server or something, so they can access the console when
things are truly hosed.

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

Actually, you make it sound substantially less complicated than other
routing protocols.  B-)

Also, it is *not* the case that you read and cache every ARP reply.
In fact, the policy is to only caches entries from machines you've
contacted.  If this weren't the case, large bridging networks wouldn't
be possible.  (Okay, so maybe it would be a good thing.)

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

They are actually the same protocol, and they are inherently closely
tied.  If you wanted, you could even keep the information in the same
user-level table.

The point is, this gives you virtually infinite flexibility.

> I can't see the advantage of replacing kernel code with mandatory user-code.
> The sum of used memory is constant.

init(8) is required even if you're not using IP.  Should we put it in
the kernel?

In general, anything that can be moved to user-level code with no
noticable additional overhead should be moved.  (Yes, this is an
argument for a mini-kernel.)