What is the use of magic cookie in dhcp options

[Ralph Droms]

In the interest of giving credit where credit is due...

The magic cookie is first suggested in RFC 951.  That cookie is intended to
define the syntax of the options in the BOOTP "vend" (DHCP options) field.
Philip de Prindeville standardized the magic cookie value of 99.130.83.99 in
RFC 1048.

DHCP reused the BOOTP packet format because, at the time the dhc WG was
developing DHCP, we wanted to reuse the BOOTP forwarding (relay) agents that
were just starting to appear in routers.  Therefore, the BOOTP and DHCP
header fields are identical (so the relay agents will forward either) and
the differentiation between BOOTP and DHCP is in the options.

In theory, an entirely new syntax for options (e.g., XML) could be developed
and specified with a new magic cookie value.

My understanding is that BOOTP and DHCP both use the same cookie value.
DHCP and BOOTP messages are usually differentiated by the existence of a
DHCP message type option in the options area.

Bonus question: What does the magic cookie value 99.130.83.99 represent and
how is it encoded?  Philip told me he suggested "OREO" (in ASCII, I assume),
but Jon Postel changed it to the current value when the RFC was published
(likely due to trademark issues).

- Ralph

On 6/22/06 12:06 PM, "David W. Hankins" <David_Hankins at isc.org> wrote:

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