Frame Tagging

[Ted Lemon]

On Aug 2, 2013, at 4:34 PM, Alex Bligh <alex at alex.org.uk> wrote:
> This makes sense for dhcp client but less for dhcdpd

There are a couple of issues that motivate the use of lpf on the DHCP server.   The most obvious one is that if the DHCP server is serving local clients on multiple interfaces, it has no way to know on which interface it received a packet.   This is important so you don't give a client an address on the wrong subnet.

Secondly, it's necessary when _replying_ to the client to control the interface on which the reply is sent.   This can't be done with layer 3 routing, because the destination is the all-ones broadcast address, which is not subnet-specific.

Thirdly, it's desirable not to broadcast the response.   The DHCP protocol spec permits this: once an IP address has been assigned to the client, the response can be unicast to that address, using the link-layer address provided in the chaddr field of the DHCP packet.   However, there is no ARP table entry for the newly-assigned IP address, and the client isn't permitted to reply to ARP messages yet.   So you can't unicast to the client using the socket API, since it doesn't provide a mechanism for pushing entries into the ARP table.

Hence, lpf.