Hi Francis,

>  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
there, too

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?

Regards,
	Ignatios Souvatzis