What is the use of magic cookie in dhcp options

[RajaSekhar Kavuri]

Hai

Can anyone tell me the use of the MAGIC COOKIE options in the
dhcp options.
The question i am asking may be silly but still please kindly send me
the solution to this question.What would be this value. it will be the
same value for all the vendor's who develop the DHCP client.
What will the DHCP server do with this MAGIC
COOKIE. I need to about this MAGICCOOKIE relationship with the DHCP.



Thanking you,
K.Rajasekhar

[kalyanasundaram S]

Can anyone tell me the use of the MAGIC COOKIE options in the dhcp options.

well you might give a read on some book and after go through rfcs, look at the the packet format

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| op (1) | htype (1) | hlen (1) | hops (1) |
+---------------+---------------+---------------+---------------+
| xid (4) |
+-------------------------------+-------------------------------+
| secs (2) | flags (2) |
+-------------------------------+-------------------------------+
| ciaddr (4) |
+---------------------------------------------------------------+
| yiaddr (4) |
+---------------------------------------------------------------+
| siaddr (4) |
+---------------------------------------------------------------+
| giaddr (4) |
+---------------------------------------------------------------+
| |
| chaddr (16) |
| |
| |
+---------------------------------------------------------------+
| |
| sname (64) |
+---------------------------------------------------------------+
| |
| file (128) |
+---------------------------------------------------------------+
| |
| options (variable) |
+---------------------------------------------------------------+

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.
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
| |
| file (128) |
+---------------------------------------------------------------+
| |
| 99,130,83,99,53,1,3,50,4,192,170,12,25,225 |
+---------------------------------------------------------------+

now this 99,130,83,99( in 0x 63,82,53,63) while parsing the pocket if the sequnce comes it means all the comming bytes has the option field..
99,130,83,99 --- start of option field.
then again 53 - Message type op code
1 - length of the option value
3 - option value
again 50 - requested ip addred option..it goes like this.. but where to end?
the final (255) says here option field ends... is that clear enough..

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

The question i am asking may be silly but still please kindly send me

Thats fine, me to is new to this place, but here people are pretty cool..

the solution to this question.What would be this value. it will be the
same value for all the vendor's who develop the DHCP client.

This is same for the client and server and whichever follows the RFC (BOOTP-RFC951, BOOTP extensions-RFC1048,2132 and the dhcp options)

If i am wrong plz somebody correct me...

i have got this frm the book
The DHCP hand Book
Understanding, Deployment, and Managing Automated Configuration Services
by Ralph Droms, Ted Lemon
you too try it out..

regards
-"kalyan"

[David W. Hankins]

Post by kalyanasundaram S
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.

Post by kalyanasundaram S
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.

Post by kalyanasundaram S
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.

[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

Post by David W. Hankins

Post by kalyanasundaram S
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.

Post by kalyanasundaram S
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.
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.

Post by kalyanasundaram S
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.

[Ragnar Lonn]

Post by Ralph Droms
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).

I was just about to ask where the cookie value came from :-)

So noone knows why Jon chose "99.130.83.99"? I can't see that it is
related to "OREO", which would be 79:82:69:79, but I'm not very good
at numerical analysis so I might be missing something.

/Ragnar

[Allwyn Carvalho]

My guess is that he ran a CRC-8 on the individual bytes of "OREO" to
produce the magic cookie...
Allwyn.

Post by Ragnar Lonn

Post by Ralph Droms
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).

I was just about to ask where the cookie value came from :-)
So noone knows why Jon chose "99.130.83.99"? I can't see that it is
related to "OREO", which would be 79:82:69:79, but I'm not very good
at numerical analysis so I might be missing something.
/Ragnar