DHCP option lengths
By Dave Miner on Apr 20, 2006
> > 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.