Is there any convention on where the DHCP message type?

[David W. Hankins]

On Tue, May 09, 2006 at 09:44:47AM -0400, Ralph Blach wrote:
> Is there any convention on the where DHCP message type  ( option 53 ) is  to
> be placed  in the
> options fields?

I suppose you already know the answer to that.

DHCP Servers must be sure to give the client the message type no matter
how full the packet gets (should space run out).

ISC DHCP chooses to solve this by putting the message type on the
options buffer first, and then processing the client's parameter
request list.  In so doing, it gives this option the ultimate priority.

In actual mechanics a new parameter request list is produced by
concatenating a predetermined list with the client supplied parameter
request list...the message type is always the first on the list.

But I should probably tell you that in work done to fix bugs in our
Option Overloading support in 3.0.2 I think, I toyed with a patch
queued in the ticketing system by my predecessor, Ted Lemon, which he
put there in 2003 or something like that.  It attempted to work around
a few of the icky corner case problems by dynamically repositioning
options that were already laid out in the option buffer.

Literally, if a big option that doesn't fit in the options buffer was
found, it inserted it to the head of the options buffer and tried to
dislodge a small option that would fit more comfortably into the
FILE and SNAME fields without being split up.  Every time you split
an option up into pieces, you add 2 to its total size (the option
code/length overhead), so this increased the overall space available.

It was like putting the options in the buffer in priority list order,
but then sorting the buffer in option size order (largest options
first).  Or at least that's my memory.

I ultimately discarded that approach due to the enormity of problems
it presented me in that maintenance release: a bit much of a rewrite
for maintenance.

I do occaisionally toy with the idea of redoing this to be more
intelligent about saving space, but it's not high on my agenda.  More
of an intellectual excercise.

> Will servers always return this as the first option after
> the Magic Cookie?

The magic 8 ball wants you to ask again later.

> Is this
> specified anywhere in the RFC's?

No, the placement of this option isn't specified (except that it is a
DHCP option, and therefore goes in the options space).

> It would be very nice if the one could assume the DHCP  message type was
> always the first option after the Magice Cookie.

Recently, on the namedroppers mailing list, someone mentioned that they
put out a new version of their nameserver which stopped using DNS
compression pointers for the answer section.  So instead of 'c0 0c'
(pointing to the name in the query section), it just listed the name
again in the answer it supplied.

He soon discovered that at least one DNS implementation started to crash.
It seems they were searching the packet from the start to end looking
for this c0 0c magic number, as a marker to find the start of the answer
section (rather than having to process the query section), and I guess
would happily run off the end of the packet buffer to find it.

So dns compression pointers in the answer section are no longer
optional, realistically, for awhile anyway.

This is 'designing to perception' rather than 'designing to
specification', and inarguably as you can see above has damaged the
protocol.

So what you should be asking yourself is: do you want to be the
one who is guilty for making this mandatory?


If you've only got the packet (not reading the options out into a
data structure of some sort), it's not that hard to walk the packet
space until you find option 53.  All options have the same format,
a 1 byte code, a 1 byte length.  The only special cases are 0 and
255, pad and end respectively.  0 is easy, just skip ahead one byte
and try again, 255 is also easy: that's where you stop early rather
than finding the end of your packet buffer.

It's a really trivial loop.  You have spent more time asking here
if you can avoid writing the loop then it would have taken you to
just write it.

Slacker.


By the by: if you're not talking about some operational use of ISC
DHCP, this isn't topical for dhcp-users at isc.org.

You're also not talking about ISC DHCP specific programming/projects,
so this isn't topical for dhcp-workers at isc.org.

I think the droids you're looking for are on dhcp-hackers at isc.org.

-- 
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