passing values to client: how big?

David W. Hankins David_Hankins at isc.org
Tue Jan 13 18:12:05 UTC 2009


On Tue, Jan 13, 2009 at 12:42:06PM +0000, Simon Hobson wrote:
> The UDP packet is limited to 576 bytes, unless the client indicates that it 
> can accept larger. 312 bytes are allowed for the variable option part - but 
> don't forget that each option value is preceded by a byte for option code 
> and a byte for option length - eg a 4 byte option would take 6 bytes the 
> packet.

For single option contents longer than 255 octets (the DHCPv4 option
length field is one octet), multiple options of the same code are
concatenated together.  So a 256 octet option would take 260 octets
to encode, minimum.

> There is also a facility to redefine the server and file fields as option 
> space, this gives an extra 192 bytes for options.

This is also semi-automatic.  It obviously can't work if you've
configured a file or server-name parameter.  If the server needs
the extra space, and these fields aren't already in use directly,
it automatically uses them for 'option overloading'.

And because these three spaces (options/file/sname) are bifurcated,
there is some 'waste' depending on the order the options are placed
in the relative fields (if 1 or two octets are left in any field, it
can't be used).  The waste can't easily be calculated, but right now
we're slightly pessimal.  When the options space won't fit a given
option, we'll use all remaining space on one fragment, and place the
option in the next field (file/sname) in the next fragment, so there
is a guaranteed fragmentation (which spends 2 octets), when for all
we know a later option could perfectly consume the remaining space in
the options field we just fragmented to consume.  The result is we
could run out of space and drop some options off the tail, when a
simple reordering could have carried them.

Ted had a patch in the queue a long time ago actually aiming at a
method to sort the options the server desires to place in the packet
to get the optimal storage in the DHCPv4 packet.  We gave it a try in
early 3.1 alphas I think.  It had problems (it got stuck in a loop we
thought was impossible (but were still prescient enough to detect)),
so we had to back it out.

We're back where we started, but I have some ideas I learned from the
excercise so I think if we can get some time to try it, there's a way
to sort the options into the packet without loops (and also less work
overall).


The packet size issue is also another thorny one.  576 is the magic
number named in RFC 2131, but this was never intended to be a maximum
packet size, I don't think.  My interpretation of the language is that
it is an absolute minimum you must support.

So there is some confusion here; 576 octets, measuring the UDP payload,
IP payload, or link layer payload (full IP packet)?

I think all three interpretations exist in some form.  The most
nefarious is DHCP relay agents that presume a 576 octet full IP packet
size, and DHCP clients that presume a 576 DHCP packet size (UDP
payload).  This combined with client brain damage that they must
'pad' the packet out to the 576 octet size (init to zero), and the two
don't interoperate, even when they don't even need the extra space.

The client hint that it can handle a larger payload is all well and
good, but it does us no good if we're connected by a relay that drops
packets larger than 576 octets.  There is no relay agent signal for
its supported packet size ranges.  You're actually better off ignoring
the client hint unless you're directly attached or unicasting (giaddr
is zero), although we don't do this (no RFC describes this behaviour
yet).

It does mean that even clients that can receive larger packet contents
really shouldn't advertise their ability to do so, or they might dupe
servers into believing it despite relay incompatibility.  This is why
I've never updated dhclient to send a default MMS option on interface
MTU (we support single, non-fragmented packets up to 64KB).

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20090113/a0a4a02b/attachment.bin>


More information about the dhcp-users mailing list