10-28-2011 07:48 PM - edited 03-07-2019 03:07 AM
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.
Solved! Go to Solution.
10-30-2011 02:13 PM
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
10-30-2011 03:34 PM
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
11-12-2011 11:34 PM
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
10-30-2011 02:13 PM
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
11-12-2011 09:44 PM
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
10-30-2011 03:34 PM
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
11-12-2011 10:20 PM
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
11-12-2011 11:34 PM
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
11-14-2011 07:41 AM
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
05-22-2022 06:52 AM
thanks for sharing this helpful description. i must share this on my site. to see it click here.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide