> But I can't help but wonder, with seeing this case and the code > changes required in ip_input, if the change to DHCP's architecture > that requires this was actually a good one.
I think the problem is actually the opposite -- too many vendors implement special-case code to handle DHCP, and that leads to a multitude of odd implementations to interoperate with. Combine that with a weakly-worded RFC (e.g. the fact that servers can ignore the broadcast bit is a crime) and you get hacks. That said, I think the end-result is still vastly preferable given that it led to a net reduction of 800 lines of code, allowed the DHCP client to get out of the business of constructing UDP and IP checksums, allowed firewall rules to be consistently applied to DHCP traffic, enabled DHCP to work properly with DR, and will allow DHCP to work with IPMP in the future. Regardless, that's not this case. -- meem
