>Dennis's analysis seems dead-on to me.  The fix would be to have some
>kind of BSD Sockets API extension that could be used to identify the
>arriving interface for DHCP REQUEST packets.  Ideally, such an 
>extension would be coordinated with the other *BSD kernel folks,
>so it could be more widely implemented than just NetBSD.

i don't think so, if you consider what dhcpd is doing.

a host with *no ip address* is requesting an ip address.  it's sending
a request for this ip address to, effectively, a link local ip
broadcast address.  it does us very little good to know that the
datagram was received at that ip address, since we (a) can't respond
from that ip address, (b) can't respond to the ip address the request
came from, and (c) we'll be receiving packets on every interface bound
for that address.  the use of bpf here is, as i understand things,
mandatory, since the *only* valid identifier we have for the requestor
is the ethernet address and the only way to use it properly to send
the response back is via bpf.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."