What is the use of magic cookie in dhcp options

David W. Hankins David_Hankins at isc.org
Thu Jun 22 16:06:26 UTC 2006


On Wed, Jun 21, 2006 at 09:43:56PM -0800, kalyanasundaram S wrote:
> in this the last field is options.. but the whole thing is not aligned, it is just bundle of hexadecimal bytes. nothing else... we need to identify in the bundle where the option field exist.

DHCP is a child of BOOTP.  What you just pasted is identical to a BOOTP
header.

DHCP is a thing that rides inside BOOTP.  It's an extension that
swallowed its host (people now think of these as DHCP packets rather
than BOOTP packets using the DHCP protocol).

It used to be that 'vendor extensions' lived in that options field in
the BOOTP header (see rfc951, this field was called 'vend' then).

So every vendor used their own format of that field.  I guess some
solved the obvious interoperability problems by putting a magic
cookie of their own in there.  One way or another each had to have a
signature of some form that made it clear the packet contained their
extensions.

Then one day someone decided a common set of extensions would produce
a lot more inter-operability and generally make the lives of sysadmins
everywhere much easier (I think his name was Ralph).

In order to do that, we have to be sure we're dealing with a DHCP Option
Buffer, and not a BOOTP Vendor Buffer.

That's why there's a magic cookie there.

The UDP port identifies the packet as being either BOOTP or DHCP, the
magic cookie narrows that down to DHCP.

> few previous fields have dynamic length too. So it is very difficult or rather not possible to find out the options field .
> so again look at the option

None of the BOOTP header fields are variable in length.  The contents
often are (who uses 128 bytes for a filename?  64 bytes for a server's
host name?  God I pity your sysadmins [1]).

So there's a lot of wasted space.


The lesson is:

1) We only parse the options buffer as a buffer containing options if
   the magic cookie specified by RFC2131 is there.

2) We treat the message like a DHCP packet IFF one of those parsed options
   was a DHCP_MESSAGE_TYPE option (so, step 1 had to succeed).

Otherwise, it's bootp.


> DHCWG is  working for a new format to avoid some of existing problem...(i am not sure how far it has gone)..

DHCPv6 (rfc3315) is alive and well.



[1] Confession: I once named a server "haleakala".  In Hawaiian, it
    means "place where the sun sets."  It happened to be the company's
    first Sun Ultra.  I thought I was pretty damn clever.  Two weeks
    later, my minion sysadmins placed a CNAME in DNS for the love of
    their own mangled fingers:  "bob"

    This was only slightly more mean to my sysadmins than the day I
    registered 'humuhumunukunukuapuaa.net'.  The Hawaii state fish.
    At least they could enter that in /etc/resolv.conf search path.

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