> Normally, a variant of "struct sockaddr" is some kind of address.

Yes.

> I would have expected to see some other interface structure with
> all the above information, also containing a simpler sockaddr_dl
> as one of the members, perhaps something like this:

[same structure with interface index/name removed]

Note that a `struct sockaddr' isn't an interface structure.  Even
sockaddr_dl's are used for other things as well.

> Why is all this stuff crammed together in a sockaddr variant?

Because when you use a particular `struct sockaddr' as an argument to
sendto() there needs to be enough information in there for sendto() to
figure out where to send the packet.  In the particular case of a
`struct sockaddr_dl', if you want to send a packet to a particular link
layer address on a particular ethernet, giving sendto() the ethernet
address by itself is insufficient for sendto() to figure out which of
the four ethernet interfaces you have is the one you wanted the packet
sent out of.  You need to qualify the link-layer address by the interface
for the packet's destination to be fully specified.

Now the question might be asked, who wants to send packets to particular
ethernet addresses on particular interfaces anyway?  At least one of the
answers is, some users of the ISO stack.  I'd also note that routing
protocols in particular really work better if they can determine the
interface packets arrived on, and a common way to do this is to include
a sockaddr_dl in the recvmsg() buffer solely for the purpose of carrying
in the interface index or name.  See, for example, a note from Bill Fenner
to tech-net sometime towards the end of last October.

Oh, and I think the selector field may be required for E.164 addresses.
You need to know where the address stops and the selector starts because
the protocols (e.g. X25) want it that way, but there's no way in general to
parse the information out by looking at the address.

Dennis Ferguson