Re: Broadcast traffic on vlans leaks into the parent interface on NetBSD-5.1

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Tue, 4 Dec 2012 22:17:23 -0800
    From:        jnemeth%victoria.tc.ca@localhost (John Nemeth)
    Message-ID:  <201212050617.qB56HNCf018610%vtn1.victoria.tc.ca@localhost>

  | Obtaining an address via DHCP is a four step process, and the
  | client can't legitimately use the new address until the fourth step is
  | completed.

Agreed.

  | To what address would you like the DHCP server to send its responses?

You should really "look at the details", but if you're suggesting that
0.0.0.0 might be an appropriate place to send it, then you really do
consider how that could possibly work.

  | I suppose the DHCP server could send responses to the broadcast address,

That is one of its options, and is the one most commonly used I think.

The other option is to send to the assigned address.  The client can't
claim it yet, but that doesn't mean that the server cannot make use of it.
Naturally, doing this is a little tricky, since we obviously cannot ARP
for the MAC address to send to, so the server needs to (one way or another)
defeat its host's normal ARP processing to make this happen (sending via
BPF is one way it can do that, another is to force populate the ARP cache
as if an ARP response had already been received).  The effect is that
an ethernet header is crafted by the server to address the packet back to
the MAC address of the client - the client then needs to accept that
packet, even though it doesn't know that the IP address in the dest addr
field belongs to it.

Naturally, not all clients can do this,, so DHCP (actually, originally,
BOOTP) has a bit in the request that the client can set to instruct
the server to use a broadcast reply.  Even when the client could hande
it, there's no guarantee that the server can make this method work.

  | but I couldn't guarantee that every client would be listening for them
  | there (it's been a while since I looked at the details).

A dhcp client that cannot accept a broadcast reply is fundamentally broken.
Sending the reply that way has always been one of the options for the
server.

  |      We use ISC's DHCP server.  As third party software, it is designed
  | to be portable to many systems.  BPF is a fairly portable interface,
  | thus a reasonable interface for it to use.

Yes, that's what I was attempting to say...   Even though there are now
other ways, why would an application for which code has already been
written, and debugged, and works essentially everywhere, want to change
to use the new interface.

The point from this for us, is that it isn't necessarily because of a
current defect in NetBSD's IP stack that the server is using BPF for its
purposes, however unfortunate that it might be that it (once) needed to
resort to that extreme.

kre