[syslinux] pxelinux magic options 208

[Jeffrey Hutzelman]

--On Wednesday, November 03, 2010 06:18:52 PM -0400 Daniel Feenberg 
<feenberg at nber.org> wrote:

> I have 2 groups of machines, and within each group the pxelinux menu
> configuration is standard. It would be great to have 2 configuration
> files rather than one for each machine.
>
> I found the pxelinux magic option configfile (209) in
>
>    http://syslinux.zytor.com/wiki/index.php/PXELINUX
>
> and it suggests for ISC dhcpd:
>
>    site-option-space "pxelinux";
>    option pxelinux.magic f1:00:74:7e;
>    option pxelinux.configfile "common";
>
> however version 4.1.1-P1 rejects this syntax, claiming not to recognize
> "pxelinux" in the first line. The wiki suggests this is good for ISC
> dhcpd version 3 - is it possible 4.1.1-P1 does not support it?

It works fine, but you failed to copy the block above which defines the 
"pxelinux" option space.  Without that, the DHCP server doesn't know what 
you're talking about.

> In looking for an answer, I found http://tools.ietf.org/html/rfc5071
> which states that "The option code 208 will be adopted for this purpose
> and immediately deprecated." It also states "The magic option MAY NOT be
> implemented, as it has been deprecated." This leaves me quite confused.

Not surprising, if you haven't followed all of the references and perhaps 
also read some of the mailing list traffic leading up to RFC3942. 
Particularly, consider these points...

Option codes 128..254 were previously classified as "site options", 
intended to be defined by local administrators in cases where the DHCP 
servers and all relevant clients are explicitly known to agree on their 
meaning.  Unfortunately, DHCP option codes are scarce, and this range 
represented fully half of the available option codes.  To make things more 
complicated, quite a few hardware and software vendors designed their 
products to respond to site-specific options rather than vendor-specific 
options (the latter are encoded in a different way, which identifies the 
vendor and does not conflict with non-vendor options).  To address these 
issues, RFC3942 reclassified codes 128..223 to make them available for 
public assignment, essentially cutting the number of site-specific options 
in half.  It also specified means for documenting existing vendor-specific 
use of options in this range.

What RFC5071 does is document the four options in use by PXELINUX, and 
adopt the three which actually carry configuration (the config file, path 
prefix, and reboot timeout options).  The text you quote pertains to the 
fourth option, "MAGIC", which was intended to allow PXELINUX to detect 
cases where the same option codes were used for data intended for another 
purpose.  Since the three useful codes are now actually registered, the 
MAGIC option is not actually needed.  The first sentence you quote 
describes what was done with that option code: it was added to the 
registry, to document its purpose, but immediately marked deprecated, 
because it is no longer needed and can safely be reallocated.

The second sentence you quote describes how implementations of RFC5071 are 
expected to behave with respect to the MAGIC option, code 208.  It applies 
only to that option and not to the config file, path prefix, or reboot 
timeout options.  Further, it must be read in the context of RFC2119, which 
defines the uppercase requirements keywords.  "MAY" means that a compliant 
implementation is permitted, but not required, to do something.  "MAY NOT" 
means that a compliant implementation is permitted, but not required, to 
NOT do something.  That is, they mean the same thing.  "MAY NOT" does not 
mean the same as "MUST NOT".

In any case, PXELINUX does implement option codes 209..211.  I don't recall 
whether it still implements option 208, but as long as you provide it with 
the correct value or not at all, it doesn't matter.


-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
   Carnegie Mellon University - Pittsburgh, PA