Subject: Re: real ARP, anyone?
From: Ignatios Souvatzis <firstname.lastname@example.org>
Date: 10/24/1995 23:49:58
> In your previous mail you wrote:
> does anyone work on a real ARP implementation? I mean, one which can
> handle multiple protocols for link level and user protocol?
> => I am some notes about this idea (because I have already done
> Neighbor Discovery (which includes address resolution) for IPv6
> and I want to extend it to ATM).
as I understand, IPv6 does NOT use ARP as per RFC 826?
> => good thought! I believe the link-layer part (exactly arpcom-ifnet)
> must be made generic with ARP input functions. Most of the code
> can be shared then it is not so trivial to write. Another point is
> if some protocol specific parts are introduced into the ifnet struct
> this should be done in a flexible way and without recompiling
> the whole stuff for minor changes (for instance the arpcom stuff
> is not good because on SunOS when you add multicast support you
> break FDDI drivers: it is obviously bad engineering).
well, I'm talking about adding ARP over (e.g.) ARCnet and AX25 support
to existing BSD-with-Sources; commercial Unices simply dont count in,
the vendors have to look after themselves. They can look after
themselves for an implementation---I just pursue a hobby. I guess the
free *BSD's will be able to pick up my code, BSDi's stuff, too; and other
OSes will be able to learn from them... (Linux seems to have a clean ARP
implementation, which is a shame :-/) I even dont KNOW whats inside SUNs
arpcom structures, if any, besides guessing that
-a) SUN doesnt develop SunOS anymore, and what they left us with, is
networking-wise basically BSD4.3
-b) I dont know at all how Solaris networking is done.
Well, my idea is to...
- move the broadcast resolution into the net/if_ethersubr.c or fddisubr
or arcsubr.c, that are the modules which know what to do
- move the macro or convenience function call for multicasting mapping
move the rest of netinet/if_ether.c to net/if_arp.c and clean it up,
changing a few parameters to use struct sockaddr * instead of u_longs
(for IP addresses).
- check if anythink must be changed in NetBSDs arp program, but I guess
that wouldn't be much...
- * add some convenience function or arc output function to the ifnet
interface OR just to the if_XXXsubr.c files, for the arp module to call
to build the headers, OR
* add a ARP protocol family type, so that the normal if_output can be
used to build the full ARP header
If IPv6 does not use RFC826 style ARP at all, I might even be very
tempted to just forget about the other-than-IPv4-stuff for the network
(as opposed to cable) protocol. Would make the change even more painless.
What do you think about that?