Is there any convention on where the DHCP message type?
ralph.blach at gmail.com
Wed May 10 21:53:45 UTC 2006
I was just asking, because I wanted adhere to the spec. Thanks for you
On 5/9/06, David W. Hankins <David_Hankins at isc.org> wrote:
> 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
> 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.
> 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
More information about the dhcp-users