DHCP option lengths

Thursday Apr 20, 2006

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.

Like this post? | | | |

Posted at 06:49PM Apr 20, 2006 by dminer in Solaris Networking
Tags: