I answered a question today about DHCP option lengths on our internal DHCP support list, a question which has come up before and no doubt will again. I might as well post it here for posterity.
> > Working with a customer on their custom jumpstart environment and they
> > ran into the 255 byte limit. I did find the notes in the documentation
> > confirming the length limit in our DHCP server. The customer came back
> > and said that they don't seem to be having the problem with their Linux
> > (RedHat/SE Linux) DHCP servers when using longer macro parameters for
> > their network installations.
First, it's important to get the terminology straight, because it's key
to understand what is happening.
The DHCP specifications talk about "options". The format of each option
in a DHCP packet is specified in such a way that the individual option
has a one-byte unsigned length, followed by the data. That means that
an individual option passed in a DHCP packet can have a length no
greater than 255 bytes.
Solaris DHCP provides a concept of "macros", which are merely a
configuration convenience which allows options to be grouped together.
Macros don't have a length limit, so you can specify any number of
options in a macro.
Generally, the problem customers encounter is that the vendor options we
use in Solaris for automating Jumpstart installs all end up collapsed
into one DHCP option, because that's the way the standard works, and we
run into the 255 byte limit there. It's highly unlikely that you'll run
into it in any other case. The usual workaround is to use shorter paths
to the installation image, as those are the options which eat up most of
the space in the packet; symlinks work well for this purpose.
> > Is there a DRAFT change to DHCP to allow longer macros?
There is an RFC, 3396, which specifies a way to pass more than 255 bytes
for an option. It works by passing multiple instances of the option in
the packet, requiring the client to concatenate them together, which
means the server has to carefully order them in order for the client to
reconstruct them correctly. We have not implemented this option in
either the Solaris client or server, but CR 4867934 records the need to
do so; adding another call record there wouldn't hurt - it's already one
of the highest-priority RFE's we have against DHCP, but there are no
resources currently assigned to work in that area.
> > Is the Linux-based DHCP server ignoring the standards?
No, I'm sure they're using the RFC 3396 conventions. The maintainers of
the most popular DHCP server on Linux are quite cognizant of remaining
compliant with the protocol standards.