> Date: Thu, 27 Feb 1997 18:56:58 +0100 (MET)
> From: Matthias Drochner <drochner@zelux6.zel.kfa-juelich.de>
> References: <199702271719.LAA00574@lotharon.endicor.com>

> Excerpts from netbsd: 27-Feb-97 Re: ATM NIC support Ty
> Sarna@endicor.com (1131)

> > Does Ignatious' ARP work help at all for this, or is ATMARP something
> > very different (I'm fairly ignorant about ATM)?

> The ATMARP as used for CLIP (RFC1577) uses the same structure
> as the well-known arp.

It does _not_. It has to deal with, apparently, seperate address and
subaddress fields, and with seperate length fields for source and
destination.

It should be possible, however, to multiplex between the two (in the
in_arpinput() function) using the hardware type field or better, call
the right one from atm_input() or equivalent.

On output, you can call the "right" resolution function anyway, as
this is done by the network driver which knows what to do (well,
really by the {ether,fddi,arc}_output vs. atm_output()).

The data structures I'm about to introduce allow for variable length
addresses for an interface 

 (struct ifnet gets an pointer to the struct sockaddr_dl in the
 if_addrlist of the interface, for fast access; the fixed address
 link level address field in struct arpcom goes away),

and a struct sockaddr_dl even contains a sdl_slen field (selector
length) in addition to the sdl_alen (address length) field, which can
be used (I guess) for the subaddress. In the routing table, a struct
sockaddr (in its sockaddr_dl variant) is used for link level
addresses, too. So I guess implementing ATMARP and InATMARP isn't too
difficult after my pending change. But they still are similar, but
different, from ARP and InARP.

Regards,
	Ignatios Souvatzis