subenet-mask option in DHCPACK for DHCPINFORM
jw354 at cornell.edu
Tue Jul 24 16:33:48 UTC 2007
> It is neither a MUST nor is it a MUST NOT. In fact, servers MAY
> provide additional options.
> In the context of DHCPINFORM, I think this behaviour is not right,
> and we'll fix this in a future release.
> In the case of DHCPREQUEST, this behaviour is unfortunately mandatory
> to be compatible (and to actually work on the modern Internet).
> I'm a little bit disappointed to see a client that throws an error if
> it sees an option it doesn't understand. The best thing to do is to
> just ignore the option. These sorts of things do happen!
We all are disappointed that with the variety of clients out there in
running (and developing) a production enterprise DHCP
server now represents a maze of things to be done and things
to be avoided. I vaguely recall on this list, discussion of the concept
of a means to configure an option to be "sent, whether asked for
or not". In other words, a means to make your server do that thing
that servers MAY do.
Part of me thinks such a feature would be better than silently doing
very thing for a single special case. On the other hand, if^H^Hwhen
client developers throw us more curves in the future, I can hardly
that that particular configuration feature would be the end of this
and likely it wouldn't even make much a dent in the larger problem.
More information about the dhcp-users