draft-ietf-dhc-pxelinux-02.txt   draft-ietf-dhc-pxelinux-03.txt 
Dynamic Host Configuration Working D. Hankins Dynamic Host Configuration Working D. Hankins
Group ISC Group ISC
Intended status: Informational Intended status: Informational
Expires: January 24, 2008 Expires: January 2, 2008
Dynamic Host Configuration Protocol Options Used by PXELINUX Dynamic Host Configuration Protocol Options Used by PXELINUX
draft-ietf-dhc-pxelinux-02 draft-ietf-dhc-pxelinux-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 24, 2008. This Internet-Draft will expire on January 2, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes the use by PXELINUX of some DHCP Option Codes This document describes the use by PXELINUX of some DHCP Option Codes
numbering from 208-211. These codes were historically designated numbering from 208-211.
'Site Local', but are presently being made available for allocation
as standard DHCP Options.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. MAGIC Option . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. MAGIC Option . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Description . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Description . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Response to RFC3942 . . . . . . . . . . . . . . . . . . . 5 3.4. Response to RFC3942 . . . . . . . . . . . . . . . . . . . 5
4. Configuration File Option . . . . . . . . . . . . . . . . . . 5 4. Configuration File Option . . . . . . . . . . . . . . . . . . 5
4.1. Description . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Description . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Response to RFC3942 . . . . . . . . . . . . . . . . . . . 6 4.4. Response to RFC3942 . . . . . . . . . . . . . . . . . . . 6
4.5. Client and Server Behaviour . . . . . . . . . . . . . . . 6 4.5. Client and Server Behaviour . . . . . . . . . . . . . . . 6
5. Path Prefix Option . . . . . . . . . . . . . . . . . . . . . . 6 5. Path Prefix Option . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 7
5.4. Response to RFC3942 . . . . . . . . . . . . . . . . . . . 8 5.4. Response to RFC3942 . . . . . . . . . . . . . . . . . . . 8
5.5. Client and Server Behaviour . . . . . . . . . . . . . . . 8 5.5. Client and Server Behaviour . . . . . . . . . . . . . . . 8
6. Reboot Time Option . . . . . . . . . . . . . . . . . . . . . . 8 6. Reboot Time Option . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 9
6.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 9 6.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 9
6.4. Response to RFC3942 . . . . . . . . . . . . . . . . . . . 10 6.4. Response to RFC3942 . . . . . . . . . . . . . . . . . . . 10
6.5. Client and Server Behaviour . . . . . . . . . . . . . . . 10 6.5. Client and Server Behaviour . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Specification Conformance . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14
1. Introduction 1. Introduction
PXE, the Preboot eXecution Environment, is a first-stage network PXE, the Preboot eXecution Environment, is a first-stage network
bootstrap agent. PXE is loaded out of firmware on the client host, bootstrap agent. PXE is loaded out of firmware on the client host,
and performs DHCP [1] queries to obtain an IP Address. and performs DHCP [1] queries to obtain an IP Address.
Once on the network, it loads a second-stage bootstrap agent as Once on the network, it loads a second-stage bootstrap agent as
configured by DHCP header and option contents. configured by DHCP header and option contents.
PXELINUX is one such second-stage bootstrap agent. Once PXE has PXELINUX is one such second-stage bootstrap agent. Once PXE has
passed execution to it, PXELINUX seeks its configuration from a cache passed execution to it, PXELINUX seeks its configuration from a cache
of DHCP Options supplied to the PXE first-stage agent, and then takes of DHCP Options supplied to the PXE first-stage agent, and then takes
action based upon those options. action based upon those options.
Most frequently, this implies loading via TFTP [4] one or more images Most frequently, this implies loading via TFTP [6] one or more images
which are decompressed into memory and executed to pass execution to which are decompressed into memory and executed to pass execution to
the final Host Operating System. the final Host Operating System.
PXELINUX uses DHCP Options 208-211 to govern parts of this bootstrap PXELINUX uses DHCP Options 208-211 to govern parts of this bootstrap
process, but these options are not requested by the PXE DHCP Client process, but these options are not requested by the PXE DHCP Client
at the time it acquires its lease...at that time, the PXE bootloader at the time it acquires its lease...at that time, the PXE bootloader
has no knowledge that PXELINUX is going to be in use, and even so has no knowledge that PXELINUX is going to be in use, and even so
would have no way to know what option(s) PXELINUX might digest. would have no way to know what option(s) PXELINUX might digest.
Local installations that serve this PXELINUX image to its clients Local installations that serve this PXELINUX image to its clients
must also configure their DHCP Servers to provide these options even must also configure their DHCP Servers to provide these options even
skipping to change at page 3, line 49 skipping to change at page 3, line 49
configuration file's location which this bootloader should use to configuration file's location which this bootloader should use to
configure itself. configure itself.
o "PathPrefix" - 210 - Configures a value to be prepended to the o "PathPrefix" - 210 - Configures a value to be prepended to the
ConfigFile, to discern the directory location of the file. ConfigFile, to discern the directory location of the file.
o "RebootTime" - 211 - Configures a timeout after which the o "RebootTime" - 211 - Configures a timeout after which the
bootstrap program will reboot the system (most likely returning it bootstrap program will reboot the system (most likely returning it
to PXE). to PXE).
Prior to RFC3942 [5], these option codes numbering from 208-211 were Historically, these option codes numbering from 208-211 were
designated 'Site Local', and now are being made available for designated 'Site Local', but after publication of RFC3942 [7], they
allocation as new standard DHCP Options. Each option as they are were made available for allocation as new standard DHCP Options.
defined below carries a response to RFC3942. This document marks these codes as assigned.
This direct assignment of option code values in the option
definitions below is unusual as it is not mentioned in DHCP Option
Code assignment guidelines [3]. This document's Option Code
assignments are done within RFC3942's provisions for documenting
prior use of option codes within the new range (128-223 inclusive).
2. Terminology 2. Terminology
o "first-stage bootloader" - Although a given boot loading order may o "first-stage bootloader" - Although a given boot loading order may
have many stages, such as where a BIOS boots a DOS Boot Disk which have many stages, such as where a BIOS boots a DOS Boot Disk which
then loads a PXE executable, it is in this example only the PXE then loads a PXE executable, it is in this example only the PXE
executable that this document describes as the "first-stage executable that this document describes as the "first-stage
bootloader" - in essence, this is the first stage of booting at bootloader" - in essence, this is the first stage of booting at
which DHCP is involved. which DHCP is involved.
o "second-stage bootloader" - This describes a program loaded by the o "second-stage bootloader" - This describes a program loaded by the
first-stage bootloader at the behest of the DHCP Server. first-stage bootloader at the behest of the DHCP Server.
o "bootloader" and "network bootstrap agent" - These are synonyms, o "bootloader" and "network bootstrap agent" - These are synonyms,
excepting that "bootloader" is intentionally vague in that its excepting that "bootloader" is intentionally vague in that its
next form of bootstrapping may not in fact involve network next form of bootstrapping may not in fact involve network
resources. resources.
The key words "MAY", "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" The key words "MAY", "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT"
in this document are to be interpreted as described in RFC2119 [3]. in this document are to be interpreted as described in RFC2119 [4].
3. MAGIC Option 3. MAGIC Option
3.1. Description 3.1. Description
If this option is provided to the PXE bootloader, then the value is If this option is provided to the PXE bootloader, then the value is
checked by PXELINUX to match the octet string f1:00:74:7e. If this checked by PXELINUX to match the octet string f1:00:74:7e. If this
matches, then PXELINUX bootloaders will also consume options 209-211, matches, then PXELINUX bootloaders will also consume options 209-211,
as described below. Otherwise, they are ignored. as described below. Otherwise, they are ignored.
skipping to change at page 5, line 13 skipping to change at page 5, line 24
The code for this option is 208. The length is always four. The code for this option is 208. The length is always four.
3.3. Applicability 3.3. Applicability
This option is absolutely inapplicable to any other purpose. This option is absolutely inapplicable to any other purpose.
3.4. Response to RFC3942 3.4. Response to RFC3942
The option code 208 will be adopted for this purpose and immediately The option code 208 will be adopted for this purpose and immediately
deprecated. Future standards action may return this option to an deprecated. Future standards action may return this option to an
available status should it be neccessary. available status should it be necessary.
A collision of the use of this option is harmless (at least from A collision of the use of this option is harmless (at least from
PXELINUX' point of view) by design: if it does not match the PXELINUX' point of view) by design: if it does not match the
aforementioned magic value, the PXELINUX bootloader will take no aforementioned magic value, the PXELINUX bootloader will take no
special action. special action.
The PXELINUX project will deprecate the use of this option, future The PXELINUX project will deprecate the use of this option, future
versions of the software will not evaluate its contents. versions of the software will not evaluate its contents.
It is not only reasonable to utilize this option code for another It is reasonable to utilize this option code for another purpose, but
purpose, it is recommended, except that it is undesirable for any it is recommended to do this at a later time, given the desire to
future consumer of this option code to have to suffer potential avoid potential collisions in legacy userbases.
collisions in legacy userbases.
4. Configuration File Option 4. Configuration File Option
4.1. Description 4.1. Description
Once the PXELINUX executable has been entered from the PXE Once the PXELINUX executable has been entered from the PXE
bootloader, it evaluates this option and loads a file of that name bootloader, it evaluates this option and loads a file of that name
via TFTP. The contents of this file serve to configure PXELINUX in via TFTP. The contents of this file serve to configure PXELINUX in
its next stage of bootloading (specifying boot image names, its next stage of bootloading (specifying boot image names,
locations, boot-time flags, text to present the user in menu locations, boot-time flags, text to present the user in menu
skipping to change at page 6, line 15 skipping to change at page 6, line 15
4.2. Packet Format 4.2. Packet Format
The Configuration File Option format is as follows: The Configuration File Option format is as follows:
Code Length Config-file... Code Length Config-file...
+--------+--------+--------+--------+--------+--------+ +--------+--------+--------+--------+--------+--------+
| 209 | n | c1 | c2 | ... | c(n) | | 209 | n | c1 | c2 | ... | c(n) |
+--------+--------+--------+--------+--------+--------+ +--------+--------+--------+--------+--------+--------+
The code for this option is 209. The Config-file (c1..c(n)) is an The code for this option is 209. The Config-file (c1..c(n)) is an
NVT-ASCII printable string, it is not terminated by a zero or any NVT-ASCII [5] printable string, it is not terminated by a zero or any
other value. other value.
4.3. Applicability 4.3. Applicability
Any bootloader, PXE or otherwise, that makes use of a separate Any bootloader, PXE or otherwise, that makes use of a separate
configuration file rather than containing all configuration within configuration file rather than containing all configuration within
DHCP options (which may be impossible due to the limited space DHCP options (which may be impossible due to the limited space
available for DHCP options) may conceivably make use of this option. available for DHCP options) may conceivably make use of this option.
4.4. Response to RFC3942 4.4. Response to RFC3942
skipping to change at page 7, line 45 skipping to change at page 7, line 45
printable string, it is not terminated by zero or any other value. printable string, it is not terminated by zero or any other value.
5.3. Applicability 5.3. Applicability
This option came into existence because server administrators found This option came into existence because server administrators found
it useful to configure the prefix and suffix of the config file path it useful to configure the prefix and suffix of the config file path
separately. A group of different PXE booting clients may use the separately. A group of different PXE booting clients may use the
same path prefix, but different filenames, or vice versa. same path prefix, but different filenames, or vice versa.
The 'shortcut' this represents is worthwhile, but it is questionable The 'shortcut' this represents is worthwhile, but it is questionable
wether that needs to manifest itself on the protocol wire. whether that needs to manifest itself on the protocol wire.
It only becomes interesting from a protocol standpoint if other It only becomes interesting from a protocol standpoint if other
options are adopted which prefix this value as well - performing a options are adopted which prefix this value as well - performing a
kind of string compression is highly beneficial to the limited kind of string compression is highly beneficial to the limited
available DHCP option space. available DHCP option space.
But it's clearly inapplicable to any current use of eg the FILENAME But it's clearly inapplicable to any current use of e.g. the FILENAME
header contents, or the DHCP Boot File Name option (#67). Use of header contents, or the DHCP Boot File Name option (#67). Use of
these fields is encoded on firmware of thousands of devices which these fields is encoded on firmware of thousands of devices which
can't or are not likely to be upgraded. Altering any behaviour here can't or are not likely to be upgraded. Altering any behaviour here
is likely to cause severe compatibility problems. is likely to cause severe compatibility problems.
Although compression of the TFTP-loaded configuration file contents Although compression of the TFTP-loaded configuration file contents
is not a compelling factor, contrived configurations using these is not a compelling factor, contrived configurations using these
values may also exist: Where each of a large variety of different values may also exist: Where each of a large variety of different
clients load the same configuration file, with the same contents, but clients load the same configuration file, with the same contents, but
due to a differently configured path prefix actually load different due to a differently configured path prefix actually load different
images. Wether this sort of use is truly needed remains unproven. images. Whether this sort of use is truly needed remains unproven.
5.4. Response to RFC3942 5.4. Response to RFC3942
The code 210 will be adopted for this purpose. The code 210 will be adopted for this purpose.
5.5. Client and Server Behaviour 5.5. Client and Server Behaviour
The Path Prefix option MUST be supplied by the DHCP Server if it The Path Prefix option MUST be supplied by the DHCP Server if it
appears on the Parameter Request List, but MUST also be supplied if appears on the Parameter Request List, but MUST also be supplied if
the server administrator believed it would later be useful to the the server administrator believed it would later be useful to the
skipping to change at page 9, line 8 skipping to change at page 9, line 8
6.1. Description 6.1. Description
Should PXELINUX be executed, and then for some reason be unable to Should PXELINUX be executed, and then for some reason be unable to
reach its TFTP server to continue bootstrapping, the client will by reach its TFTP server to continue bootstrapping, the client will by
default reboot itself after 300 seconds have passed. This may be too default reboot itself after 300 seconds have passed. This may be too
long, too short, or inappropriate behaviour entirely, depending on long, too short, or inappropriate behaviour entirely, depending on
the environment. the environment.
By configuring a non-zero value in this option, admins can inform By configuring a non-zero value in this option, admins can inform
PXELINUX of what specific timeout is desired. The client will reboot PXELINUX of what specific timeout is desired. The client will reboot
itself if it fails to acheive its configured network resources within itself if it fails to achieve its configured network resources within
the specified number of seconds. the specified number of seconds.
This reboot will run through the system's normal boot-time execution This reboot will run through the system's normal boot-time execution
path, most likely leading it back to PXE and therefore PXELINUX. So, path, most likely leading it back to PXE and therefore PXELINUX. So,
in the general case, this is akin to returning the client to the DHCP in the general case, this is akin to returning the client to the DHCP
INIT state. INIT state.
By configuring zero, the feature is disabled, and instead the client By configuring zero, the feature is disabled, and instead the client
chooses to remove itself from the network and wait indefinitely for chooses to remove itself from the network and wait indefinitely for
operator intervention. operator intervention.
skipping to change at page 10, line 37 skipping to change at page 10, line 37
thread of execution has been passed to the host operating system (at thread of execution has been passed to the host operating system (at
which point this timeout is effectively obviated). which point this timeout is effectively obviated).
If the value of this option is zero, the second-stage bootloader MUST If the value of this option is zero, the second-stage bootloader MUST
NOT schedule such a timeout at all. Any second-stage bootloader that NOT schedule such a timeout at all. Any second-stage bootloader that
finds it has encountered excessive timeouts attempting to obtain its finds it has encountered excessive timeouts attempting to obtain its
host operating system SHOULD disconnect itself from the network to host operating system SHOULD disconnect itself from the network to
wait for operator intervention, but MAY continue to attempt to wait for operator intervention, but MAY continue to attempt to
acquire the host operating system indefinitely. acquire the host operating system indefinitely.
7. Security Considerations 7. Specification Conformance
To conform to this specification, clients and servers MUST implement
the Configuration File, Path Prefix, and Reboot Time options as
directed.
The MAGIC option MAY NOT be implemented, as it has been deprecated.
8. Security Considerations
PXE and PXELINUX allow any entity acting as a DHCP server to execute PXE and PXELINUX allow any entity acting as a DHCP server to execute
arbitrary code upon a system. At present, no PXE implementation is arbitrary code upon a system. At present, no PXE implementation is
known to implement Authentication mechanisms so that PXE clients can known to implement Authentication mechanisms [8] so that PXE clients
be sure they are receiving configuration information from the can be sure they are receiving configuration information from the
correct, authoritative DHCP Server. correct, authoritative DHCP Server.
The use of TFTP by PXE and PXELINUX also lacks any form of The use of TFTP by PXE and PXELINUX also lacks any form of
cryptographic signature - so a 'Man in the Middle' attack may lead to cryptographic signature - so a 'Man in the Middle' attack may lead to
an attacker's code being executed on the client system. Since this an attacker's code being executed on the client system. Since this
is not an encrypted channel, any of the TFTP loaded data may also be is not an encrypted channel, any of the TFTP loaded data may also be
exposed (such as in loading a "RAMDISK" image, which contains /etc/ exposed (such as in loading a "RAMDISK" image, which contains /etc/
passwd or similar information). passwd or similar information).
The use of the Ethernet MAC Address as the client's unique identity The use of the Ethernet MAC Address as the client's unique identity
may allow an attacker who takes on that identity to gain may allow an attacker who takes on that identity to gain
inappropriate access to a client system's network resources by being inappropriate access to a client system's network resources by being
given by the DHCP Server whatever 'keys' are required to in fact be given by the DHCP Server whatever 'keys' are required to in fact be
the target system (to boot up as though it were the target). the target system (to boot up as though it were the target).
Great care should be taken to secure PXE and PXELINUX installations, Great care should be taken to secure PXE and PXELINUX installations,
such as by using IP Firewalls, to reduce or eliminate these concerns. such as by using IP Firewalls, to reduce or eliminate these concerns.
The use of these options present no additional security risk.
A nearby attacker might feed a "Reboot Time" option value of 1 second A nearby attacker might feed a "Reboot Time" option value of 1 second
to a mass of unsuspecting clients, to effect a Denial Of Service upon to a mass of unsuspecting clients, to effect a Denial Of Service upon
the DHCP Server, but then again it may just as easily supply these the DHCP Server, but then again it may just as easily supply these
clients with rogue second-stage bootloaders which simply transmit a clients with rogue second-stage bootloaders which simply transmit a
flood of packets. flood of packets.
8. IANA Considerations This document in and by itself provides no security, nor does it
impact existing DCHP security as described in RFC2131 [1].
9. IANA Considerations
IANA is requested to: IANA is requested to:
1. Move DHCPv4 Option code 208 from 'Tentatively Assigned' to 1. Move DHCPv4 Option code 208 from 'Tentatively Assigned' to
'Assigned', referencing this document. IANA is also requested to 'Assigned', referencing this document. IANA is also requested to
mark this same option code, 208, as Deprecated. mark this same option code, 208, as Deprecated.
2. Move DHCPv4 Option code 209 from 'Tentatively Assigned' to 2. Move DHCPv4 Option code 209 from 'Tentatively Assigned' to
'Assigned', referencing this document. 'Assigned', referencing this document.
3. Move DHCPv4 Option code 210 from 'Tentatively Assigned' to 3. Move DHCPv4 Option code 210 from 'Tentatively Assigned' to
'Assigned', referencing this document. 'Assigned', referencing this document.
4. Move DHCPv4 Option code 211 from 'Tentatively Assigned' to 4. Move DHCPv4 Option code 211 from 'Tentatively Assigned' to
'Assigned', referencing this document. 'Assigned', referencing this document.
9. Acknowledgements 10. Acknowledgements
These options were designed and implemented for the PXELINUX project These options were designed and implemented for the PXELINUX project
by H. Peter Anvin, and he was instrumental in producing this by H. Peter Anvin, and he was instrumental in producing this
document. Shane Kerr has also provided feedback which has improved document. Shane Kerr has also provided feedback which has improved
this document. this document.
10. References 11. References
10.1. Normative References 11.1. Normative References
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
[2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Droms, R., "Procedures and IANA Guidelines for Definition of New
DHCP Options and Message Types", BCP 43, RFC 2939,
September 2000.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References [5] Postel, J. and J. Reynolds, "Telnet Protocol Specification",
STD 8, RFC 854, May 1983.
[4] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, 11.2. Informative References
[6] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350,
July 1992. July 1992.
[5] Volz, B., "Reclassifying Dynamic Host Configuration Protocol [7] Volz, B., "Reclassifying Dynamic Host Configuration Protocol
version 4 (DHCPv4) Options", RFC 3942, November 2004. version 4 (DHCPv4) Options", RFC 3942, November 2004.
[8] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
RFC 3118, June 2001.
Author's Address Author's Address
David W. Hankins David W. Hankins
Internet Systems Consortium, Inc. Internet Systems Consortium, Inc.
950 Charter Street 950 Charter Street
Redwood City, CA 94063 Redwood City, CA 94063
US US
Phone: +1 650 423 1307 Phone: +1 650 423 1307
Email: David_Hankins@isc.org Email: David_Hankins@isc.org
 End of changes. 29 change blocks. 
43 lines changed or deleted 66 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/