Why DHCP option has "magic cookie" ?

Answered Question
Oct 28th, 2011

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.

I have this problem too.
0 votes
Correct Answer by Alexander Maroukian about 2 years 5 months ago

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

Correct Answer by Alexander Maroukian about 2 years 5 months ago

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

Correct Answer by Peter Paluch about 2 years 5 months ago

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

  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 5 (3 ratings)
Correct Answer
Peter Paluch Sun, 10/30/2011 - 14:13

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

sheepuking Sat, 11/12/2011 - 21:44

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

sheepuking Sat, 11/12/2011 - 22:20

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

Correct Answer
Alexander Maroukian Sat, 11/12/2011 - 23:34

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

sheepuking Mon, 11/14/2011 - 07:41

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

Actions

Login or Register to take actions

This Discussion

Posted October 28, 2011 at 7:48 PM
Stats:
Replies:6 Avg. Rating:5
Views:3577 Votes:0
Shares:0
Tags: No tags.
Categories: Switches
+

Discussions Leaderboard

Rank Username Points
1 15,007
2 8,150
3 7,730
4 7,083
5 6,742
Rank Username Points
165
82
70
69
55