I'm implementing DHCP on a tiny device and I can do some parsing optimization if I assume the Message Type DHCP option is always the first option and the response parameter list is in the same order as the request parameter list. I actually can't find whether this is required by the standard. Does anyone know whether this is actually required?
RFC 2131 § 4.1 deals with the construction of DHCP messages. The only restrictions is has about option order are:
... The last option must always be the 'end' option.
...
... The options in the 'sname' and 'file' fields (if in use as indicated by the 'options overload' option) MUST begin with the first octet of the field, MUST be terminated by an 'end' option, and MUST be followed by 'pad' options to fill the remainder of the field. ...
There is no requirement that other options be listed in any particular order.
Additionally, RFC 3046 § 2.0 discusses the implementation of "sub-options", and explicitly states:
The sub-options need not appear in sub-option code order.
However, RFC 2132 § 9.8, which described the "Parameter Request List" DHCP option, says this:
The client MAY list the options in order of preference. The DHCP server is not required to return the options in the requested order, but MUST try to insert the requested options in the order requested by the client.
"MUST try" implies that there are some times it won't happen (such as if the response doesn't fit in the available space without being rearranged), so you probably cannot rely on it if you are expecting to work with DHCP servers that may send large (or large numbers of) options.