Subject: [dhcwg] RE: RFC 3942 notice: PXELINUX, DHCP options 208-211

From: "Bernie Volz" <[email-masked]>
Date: Tue, 18 Jan 2005 20:04:53 -0500

Thanks Peter!

Do you intend to write the required Internet-Draft (for submission as an
RFC) or do you want to have these options included in a "general" options
draft (for which I'm willing to act as editor).

- Bernie

> -----Original Message-----
> From: H. Peter Anvin [mailto:[email-masked]] 
> Sent: Tuesday, January 18, 2005 7:48 PM
> To: [email-masked]; [email-masked]; [email-masked]; David W. Hankins
> Cc: [email-masked]
> Subject: RFC 3942 notice: PXELINUX, DHCP options 208-211
> 
> 
> Dear friends,
> 
> In accordance with RFC 3942 I would like to submit the following DHCP 
> options for official consideration.  These options are used 
> by PXELINUX, 
> which is part of the SYSLINUX distribution, and although exact usage 
> count is impossible to determine, is widely held to be the 
> most widely 
> used method for booting Linux from a network.
> 
> ----------
> 
> Option 208: pxelinux.magic (string)
> Must be set to F1:00:74:7E (241.0.116.126) for PXELINUX to 
> recognize any 
> special DHCP options whatsoever.
> 
> Option 209: pxelinux.configfile (text)
> Specifies the PXELINUX configuration file name.
> 
> Option 210: pxelinux.pathprefix (text)
> Specifies the PXELINUX common path prefix, instead of 
> deriving it from 
> the boot file name. This almost certainly needs to end in whatever 
> character the TFTP server OS uses as a pathname separator, e.g. slash 
> (/) for Unix.
> 
> Option 211: pxelinux.reboottime (unsigned integer 32 bits) 
> Specifies, in seconds, the approximate time to wait before 
> reboot in the 
> event of TFTP failure. 0 means wait forever (in reality, it waits 
> approximately 136 years.)
> 
> ----------
> 
> Out of these, option 208 is strictly use as a safety and is obviously 
> not required if 209-211 become official assignments.
> 
> It is my belief that 209, 210 and 211 are of general interest 
> and should 
> be promoted to official.  In particular a more withspread use of 211 
> would probably improve remote booting reliability by giving 
> the server 
> explicit control over the early boot failure policy.
> 
> Option 210 could arguably be considered redundant with option 
> 17, but I 
> personally feel they are distinct enough to warrant separate 
> assignments.  In particular, 210 is more of a "current working 
> directory" than a root image path.
> 
> 	-hpa
> 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "H. Peter Anvin" <[email-masked]>
Date: Tue, 18 Jan 2005 16:48:28 -0800

Dear friends,

In accordance with RFC 3942 I would like to submit the following DHCP 
options for official consideration.  These options are used by PXELINUX, 
which is part of the SYSLINUX distribution, and although exact usage 
count is impossible to determine, is widely held to be the most widely 
used method for booting Linux from a network.

----------

Option 208: pxelinux.magic (string)
Must be set to F1:00:74:7E (241.0.116.126) for PXELINUX to recognize any 
special DHCP options whatsoever.

Option 210: pxelinux.pathprefix (text)
Specifies the PXELINUX common path prefix, instead of deriving it from 
the boot file name. This almost certainly needs to end in whatever 
character the TFTP server OS uses as a pathname separator, e.g. slash 
(/) for Unix.

Option 211: pxelinux.reboottime (unsigned integer 32 bits)
Specifies, in seconds, the approximate time to wait before reboot in the 
event of TFTP failure. 0 means wait forever (in reality, it waits 
approximately 136 years.)

----------

It is my belief that 209, 210 and 211 are of general interest and should 
be promoted to official.  In particular a more withspread use of 211 
would probably improve remote booting reliability by giving the server 
explicit control over the early boot failure policy.

Option 210 could arguably be considered redundant with option 17, but I 
personally feel they are distinct enough to warrant separate 
assignments.  In particular, 210 is more of a "current working 
directory" than a root image path.

	-hpa

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 21 Jan 2005 09:58:19 -0800

> draft (for which I'm willing to act as editor).

As I use pxelinux in an at-home testlab, and am familiar with the
options' use, I'm also willing to write (or co-author) the I-D for
these options specifically if that would make for less work for Mr.
Volz or Mr. Anvin.

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz" <[email-masked]>
Date: Fri, 21 Jan 2005 14:19:15 -0500

David/Peter:

I'm not planning to get started on writing a consolidated draft of options
for the reclassified range until about the May timeframe (when the
notification period has expired).

While it would be nice if we could do something along the lines of RFC 2132,
I think we'll need more.

I was planning on grouping the options and having each grouping have
essentially what existing options documents contain:
- Introduction/motivation of the option(s)
- Format of the option(s)
- Client/server(/relay agent) behavior

So, if you want to start work on writing something up for the PXELINUX
options, feel free.

If you're really eager to get started, I'd suggest doing it as a separate
draft. This won't be bad as it might be a useful template for others to
follow?

- Bernie

> From: David W. Hankins [mailto:[email-masked]] 
> Sent: Friday, January 21, 2005 12:58 PM
> To: Bernie Volz
> Cc: 'H. Peter Anvin'; [email-masked]; [email-masked]
> Subject: Re: RFC 3942 notice: PXELINUX, DHCP options 208-211
> 
> 
> > Do you intend to write the required Internet-Draft (for 
> submission as 
> > an
> As I use pxelinux in an at-home testlab, and am familiar with 
> the options' use, I'm also willing to write (or co-author) 
> the I-D for these options specifically if that would make for 
> less work for Mr. Volz or Mr. Anvin.
> 
> --

---

From: "H. Peter Anvin" <[email-masked]>
Date: Fri, 21 Jan 2005 14:48:18 -0800

> draft. This won't be bad as it might be a useful template for others to

Well, since David volunteered, this probably makes sense.  David, is 
that OK with you?  Oh... and I finally figured out why I hadn't received 
your emails (for a completely stupid reason, it set off one of my spam 
patterns; I found all the emails in an otherwise unused spam folder :-?).

David: as far as 0 is concerned, the main thing I don't want is for 0 to 
mean "don't wait."  PXELINUX actually interprets it as 0x10000000, but 
detecting the "don't wait" is actually extra logic.  Other than that I'm 
agnostic.

I haven't written an ID before, nor do I have experience working with 
IETF.  I'm kind of in the early stages of trying to draft up an 
extension to TFTP that I'm hoping to publish after implementing it in 
tftp-hpa.

Option 210 cannot affect the boot file, I'm afraid; it will break every 
ROM that is currently out there, and it will break it in an 
unpredictable fashion (you don't know what it will do if it receives 
210; it will either use it or drop it.)

One of the real ugly features about DHCP and PXE is that the DHCP is 
performed by the PXE stack and then the data is handed off to the NBP. 
It is theoretically possible to re-issue the request asking for 
different options, but a lot of (somewhat bogus) DHCP configurations 
that are in active use will break if they are too different.

I'm not fundamentally against using VIVSO, but not too many DHCP servers 
today support it as far as I know.  Additionally, VIVSO presupposes 
proper handling of RFC 3396 concatenation, which is somewhat painful to 
implement.

	-hpa

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 25 Jan 2005 12:38:11 -0800

> >draft. This won't be bad as it might be a useful template for others to

Following my example?  Sounds dangerous.

I'll give it a swing.

> that OK with you?  Oh... and I finally figured out why I hadn't received 

Be glad to.

> detecting the "don't wait" is actually extra logic.  Other than that I'm 

I see, I hadn't thought of that, and configuring 1 second is approximately
equivalent to configuring 0.  This is probably better to leave as-is then.

> IETF.

I'm in a similar boat with the exception that these are both things I
feel a compulsion to change.

I'm considering seeking therapy.

> 210; it will either use it or drop it.)

I didn't mean to suggest that it should; rather that I think it should
be allowed to affect more than just option 209 within DHCP, or else it
loses its point.  You may as well include the full pathname in option
209 rather than splitting it into two options.

I understand the administrative benefit on the DHCP Servers, being
able to specify leading path and filename separately, but if that
is the desire then the servers could 'automagically' concatenate the
configuration options rather than sending them as two DHCP options
in the packet (which wastes both option allocation space and 2 bytes
in the DHCP payload).

But, if option 210 is to be prepended to both option 209 and option
67 (we assume the server administrator or DHCP server knows if the
client supports this) or others, then we have a protocol reason.  A
possibly significant savings of packet space, since bootloader directory
names often contain hashes of client packet information (chaddr, vendor
id, hardware architecture, selected boot environment...) and can be
relatively large.

> that are in active use will break if they are too different.

WinPE does something like that.  After booting, it sends a new DISCOVER
with a Requested-Address option specifying the address the PXE loader
just received.

First, ISC DHCP's "ping check" functionality incorrectly detects this
as a colllision (PXE responds to the ICMP echo, which we always do on
receiving DISCOVERs on a naive assumption that clients do not DISCOVER
if they have already bound to an address), and RESETs the lease.

Second if you get past the above (probably by disabling ping-check if
the vendor-class-identifier matches WinPE), a bug in ISC DHCP lease
finding allows a client with a different unique identifier to have the
lease it requests, so long as one of the hardware address or client
identifier matches.  But, the lease is then tagged with a client
identifier, so it can never be allocated to the PXE client again...the
PXE client gets a new lease next time it boots.  And round and round
you go until all free or backup leases are consumed.

Third, if the lease was RESET as in #1 or we fixed the bug in the second
condition then the client would get OFFERed a different lease from the
PXE layer.  But WinPE cannot change PXE's network address.  So it just
sits there forever, rebooting itself to hope the next time it will get
an OFFER for the address that PXE already bound to.

I have faith any implementation you would consider would not suck nearly
that much for any parties involved.

I think sending INFORMs is safe, and should work reliably across server
implementations.

That can be a lot cleaner than asking the server to endure special
configuration to over-ride the clients' option request lists and so
forth (I almost wish PXE didn't send an option request list).

But since the servers already need to be configured to know to send
the boot parameters to each client specifically...it's not that far
of a stretch to ask them to also over-ride requested options (and I
can make ISC DHCP config syntax easier to bear in that regard).

So making pxelinux speak DHCP packets is possibly more work than
reward.