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

[jnemeth%victoria.tc.ca@localhost (John Nemeth)]

On Apr 29,  4:38pm, Robert Elz wrote:
}
}     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.

     If you look at ISC's changelog for dhclient, you'll find my name.
However, it's been quite a few years since I've dugged into the
protocol/code at that level, and I don't have time to do it at this
moment.

}   | 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.

     No, it can't.  Obtaining an address is a four step process.  The
first step, the client broadcasts a DISCOVER request.  The second step,
all servers that receive the message respond with an OFFER.  After
that, the client will make a REQUEST to one of the servers, and finally
the server will ACK.  Typically, there is only one server for a given
network segment, but you can't assume that.  And, there is no assigned
address until the third step is completed.

} 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.

     Yes, I'm aware of the broadcast bit.  The local cable company's
DHCP server would fail to respond if the bit was set.  I don't know if
it still has that problem, and I have other things to do besides
probing it.

} 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.

     I don't think this is a problem, since we provide the BPF
interface anyways, and the DHCP software might not be the only software
using it.

}-- End of excerpt from Robert Elz