cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
24504
Views
2
Helpful
7
Replies

Why DHCP option has "magic cookie" ?

sheepuking wu
Level 1
Level 1

In RFC 951, the format of BOOTP packet was legislated, but the vendor information was not legislated in this document,  so the authors of this document had described that :

"If the 'vend' field is used, it is recommended that a 4 byte 'magic number' be the first item within 'vend'.  This lets a server determine what kind of information it is seeing in this field. "

I think it meant that the format of vendor information wasn't fixed in RFC 951, and any vendor can legislate a new format of vendor information by itself. And the value in "magic cookie" can be set by any vendor.

But in RFC 2131, the format of DHCP packet was legislated, and the "magic cooke" was fixed to values 99, 130, 83 and 99, I think it meant that the format of option information in DHCP packet was fixed absolutely and any vendor can't legislate a new format by itself.

My question are as follow:

Since the format of option information in DHCP packet was fixed absolutely, why the network device needs "magic cookie" to  identify the mode in which the succeeding data is to be interpreted ?  I think the magic cookie is not useful in DHCP packet because the format of option information is fixed. In other words, there is only one format of option information forever.

Thank you.

3 Accepted Solutions

Accepted Solutions

Peter Paluch
Cisco Employee
Cisco Employee

Hello,

In my understanding, DHCP messages are formatted in an identical way to BOOTP messages. Without the specific magic cookie, it would be impossible to differentiate between a BOOTP and a DHCP message. In fact, the fixed magic cookie present in the BOOTP message means that this is really a DHCP message, and everything that follows the magic number is to be interpreted as DHCP options.

So the magic value of 99, 130, 83 and 99 is not really a vendor's magic to differentiate its own options. Rather, it is a distinguisher to know that this is a DHCP message, and the "vendor options" are really DHCP options.

Best regards,

Peter

View solution in original post

Hi,

As far as I know the 99.130.83.99 was defined almost 10 years before RFC 2131 in RFC 1048. DHCP message type is recognized by DHCP message type option.

Best regards,

Alex

EDIT: I did find the old thread about it which aswered my question when I was wondering before on the same question:

https://lists.isc.org/pipermail/dhcp-users/2006-June/000978.html

View solution in original post

Hi Sheepuking,

As mr. Ralph Droms which was editor of the RFC 2132 and RFC 2131 and chairman of DHCP working group said this 99.130.83.99 was fixed in RFC 1048. The fix of the value was intentended to make interoperability easier I assume. So in RFC 951 the use was intended to give addional vendor extentions but was fixed in RFC 1048 and since it is there in this format.

Best regards,

Alex

View solution in original post

7 Replies 7

Peter Paluch
Cisco Employee
Cisco Employee

Hello,

In my understanding, DHCP messages are formatted in an identical way to BOOTP messages. Without the specific magic cookie, it would be impossible to differentiate between a BOOTP and a DHCP message. In fact, the fixed magic cookie present in the BOOTP message means that this is really a DHCP message, and everything that follows the magic number is to be interpreted as DHCP options.

So the magic value of 99, 130, 83 and 99 is not really a vendor's magic to differentiate its own options. Rather, it is a distinguisher to know that this is a DHCP message, and the "vendor options" are really DHCP options.

Best regards,

Peter

Hi Peter,

Thanks for your help,

according to RFC1542, the BOOTP packets also has the magic cookie "99,130,83,99"

I think the format of option in BOOTP packet is same as DHCP packet,

the difference between DHCP packet and BOOTP packet is that DHCP packet has option 53

( ie, DHCP message type option), and BOOTP doesn't have option 53.

This is my personal thinking.

Best regards,

sheepuking

Hi,

As far as I know the 99.130.83.99 was defined almost 10 years before RFC 2131 in RFC 1048. DHCP message type is recognized by DHCP message type option.

Best regards,

Alex

EDIT: I did find the old thread about it which aswered my question when I was wondering before on the same question:

https://lists.isc.org/pipermail/dhcp-users/2006-June/000978.html

Hi Alex,

Thanks for your help , accroding to the description in the web site:

https://lists.isc.org/pipermail/dhcp-users/2006-June/000978.html

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

I found that the format of vendor information was fixed in RFC 2132, in other words, every vendor used the same format of that field in DHCP/BOOTP packet  . So I don't understand what is the use of magic cookie in DHCP/BOOTP packet and I described this question here.

Best regards.

sheepuking

Hi Sheepuking,

As mr. Ralph Droms which was editor of the RFC 2132 and RFC 2131 and chairman of DHCP working group said this 99.130.83.99 was fixed in RFC 1048. The fix of the value was intentended to make interoperability easier I assume. So in RFC 951 the use was intended to give addional vendor extentions but was fixed in RFC 1048 and since it is there in this format.

Best regards,

Alex

Hi Alex,

Thanks for your help, I agree the fix of the magic value was intentended to make interoperability easier. I think it is better that there is no magic cookie in BOOTP/DHCP since the format of option is fixed and the magic cookie may be unuseful here. This is my personal thinking and maybe this thinking is correct or incorrect.

Best regards,

sheepuking

avaxo9575
Level 1
Level 1

thanks for sharing this helpful description. i must share this on my site. to see it click here.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: