>> You need to know the incoming hardware the packet arrived on to
>> assign an address to the host, so I hope this is what IP_RECVIF is
>> telling you.

IP_RECVIF gets you the if_index value for the interface in question.
Mapping that to anything useful is up to the packet recipient.

>> The way sending the response back is usually accomplished is to
>> manually add an ARP entry for the host at its new address, [...p2p
>> stuff...]
> and...if the address isn't on the local network, then adding an arp
> entry will fail, no?

No.  You can add an ARP entry on a "wrong" interface easily enough,
provided you do it yourself with a routing socket.  (I know this
because I did it, once - I can babble about the motivation if anyone is
interested.)  Since DHCP requests are sent as link-layer broadcasts,
you must actually be in the same broadcast domain as the client, in
which case the ARP entry will DTRT.  (The p2p case, of course, is
trivial, as there is only one link-layer address possible.)

> kinda like the way that the arp subsystem can't properly tell you
> from which hardware address an erroneous arp datagram
> originated...just what that host claimed to be at in the arp data.

Even the from-address in the Ethernet header is only what the host
claims; most Ethernet hardware is quite capable of generating packets
with a "wrong" address in the Ethernet-header from field.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B