Network Working Group D. Hankins
Request for Comments: 5071 ISC
Category: Informational December 2007
Network Working Group D. Hankins
Request for Comments: 5071 ISC
Category: Informational December 2007
Dynamic Host Configuration Protocol Options Used by PXELINUX
PXELINUX使用的动态主机配置协议选项
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
This document describes the use by PXELINUX of some DHCP Option Codes numbering from 208-211.
本文档描述了PXELINUX使用一些编号为208-211的DHCP选项代码。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. MAGIC Option . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Description . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Response to RFC 3942 . . . . . . . . . . . . . . . . . . . 5
4. Configuration File Option . . . . . . . . . . . . . . . . . . 5
4.1. Description . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Response to RFC 3942 . . . . . . . . . . . . . . . . . . . 6
4.5. Client and Server Behaviour . . . . . . . . . . . . . . . 6
5. Path Prefix Option . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 7
5.4. Response to RFC 3942 . . . . . . . . . . . . . . . . . . . 8
5.5. Client and Server Behaviour . . . . . . . . . . . . . . . 8
6. Reboot Time Option . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 9
6.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 10
6.4. Response to RFC 3942 . . . . . . . . . . . . . . . . . . . 10
6.5. Client and Server Behaviour . . . . . . . . . . . . . . . 10
7. Specification Conformance . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. MAGIC Option . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Description . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Response to RFC 3942 . . . . . . . . . . . . . . . . . . . 5
4. Configuration File Option . . . . . . . . . . . . . . . . . . 5
4.1. Description . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Response to RFC 3942 . . . . . . . . . . . . . . . . . . . 6
4.5. Client and Server Behaviour . . . . . . . . . . . . . . . 6
5. Path Prefix Option . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 7
5.4. Response to RFC 3942 . . . . . . . . . . . . . . . . . . . 8
5.5. Client and Server Behaviour . . . . . . . . . . . . . . . 8
6. Reboot Time Option . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 9
6.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 10
6.4. Response to RFC 3942 . . . . . . . . . . . . . . . . . . . 10
6.5. Client and Server Behaviour . . . . . . . . . . . . . . . 10
7. Specification Conformance . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . . 12
PXE, the Preboot eXecution Environment, is a first-stage network bootstrap agent. PXE is loaded out of firmware on the client host, and performs DHCP [3] queries to obtain an IP address.
PXE是预引导执行环境，是第一阶段的网络引导代理。PXE从客户端主机上的固件中加载，并执行DHCP[3]查询以获取IP地址。
Once on the network, it loads a second-stage bootstrap agent as configured by DHCP header and option contents.
一旦进入网络，它将加载由DHCP头和选项内容配置的第二阶段引导代理。
PXELINUX is one such second-stage bootstrap agent. Once PXE has passed execution to it, PXELINUX seeks its configuration from a cache of DHCP options supplied to the PXE first-stage agent, and then takes action based upon those options.
PXELINUX就是这样的第二阶段引导代理。一旦PXE将执行传递给它，PXELINUX就会从提供给PXE第一阶段代理的DHCP选项缓存中查找其配置，然后根据这些选项采取操作。
Most frequently, this implies loading via Trivial File Transfer Protocol (TFTP) [6] one or more images that are decompressed into memory, then executed to pass execution to the final Host Operating System.
最常见的情况是，这意味着通过普通文件传输协议（TFTP）[6]加载一个或多个映像，这些映像被解压缩到内存中，然后执行以将执行传递给最终的主机操作系统。
PXELINUX uses DHCP options 208-211 to govern parts of this bootstrap 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 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. Local installations that serve this PXELINUX image to its clients must also configure their DHCP servers to provide these options even though they are not on the DHCP Parameter Request List [4].
PXELINUX使用DHCP选项208-211来管理此引导过程的某些部分，但PXE DHCP客户端在获取其租约时不会请求这些选项。当时，PXE引导加载程序不知道PXELINUX将被使用，即使如此，也无法知道PXELINUX可能会消化哪些选项。为其客户端提供此PXELINUX映像的本地安装还必须配置其DHCP服务器以提供这些选项，即使它们不在DHCP参数请求列表中[4]。
These options are:
这些选择包括：
o "MAGIC" - 208 - An option whose presence and content verifies to the PXELINUX bootloader that the options numbered 209-211 are for the purpose as described herein.
o “MAGIC”-208-其存在和内容向PXELINUX引导加载程序验证编号为209-211的选项是否用于本文所述目的的选项。
o "ConfigFile" - 209 - Configures the path/filename component of the configuration file's location, which this bootloader should use to configure itself.
o “ConfigFile”-209-配置配置文件位置的路径/文件名组件，此引导加载程序应使用该组件来配置自身。
o "PathPrefix" - 210 - Configures a value to be prepended to the ConfigFile to discern the directory location of the file.
o “PathPrefix”-210-配置要在ConfigFile前面加上的值，以识别文件的目录位置。
o "RebootTime" - 211 - Configures a timeout after which the bootstrap program will reboot the system (most likely returning it to PXE).
o “RebootTime”-211-配置一个超时，在此超时之后引导程序将重新引导系统（很可能将其返回PXE）。
Historically, these option codes numbering from 208-211 were designated 'Site Local', but after publication of RFC3942 [8], they were made available for allocation as new standard DHCP options.
历史上，编号为208-211的这些选项代码被指定为“现场本地”，但在RFC3942[8]发布后，它们作为新的标准DHCP选项可供分配。
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 [5]. This document's Option Code assignments are done within RFC 3942's provisions for documenting prior use of option codes within the new range (128-223 inclusive).
以下选项定义中选项代码值的这种直接分配是不寻常的，因为DHCP选项代码分配指南[5]中没有提及。本文件的期权代码分配在RFC 3942关于记录新范围（128-223包括在内）内期权代码先前使用的规定范围内完成。
o "first-stage bootloader" - Although a given bootloading order may 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 executable that this document describes as the "first-stage bootloader" -- in essence, this is the first stage of booting at which DHCP is involved.
o “第一阶段引导加载程序”-虽然给定的引导加载顺序可能有许多阶段，例如BIOS引导DOS引导磁盘，然后再加载PXE可执行文件，但在本例中，本文档描述为“第一阶段引导加载程序”的PXE可执行文件-本质上，这是涉及DHCP的引导的第一阶段。
o "second-stage bootloader" - This describes a program loaded by the first-stage bootloader at the behest of the DHCP server.
o “第二阶段引导加载程序”-描述了第一阶段引导加载程序根据DHCP服务器的要求加载的程序。
o "bootloader" and "network bootstrap agent" - These are synonyms, excepting that "bootloader" is intentionally vague in that its next form of bootstrapping may not in fact involve network resources.
o “引导加载器”和“网络引导代理”-这是同义词，但“引导加载器”故意含糊其辞，因为它的下一种引导形式实际上可能不涉及网络资源。
The key words "MAY", "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in RFC 2119 [2].
本文件中的关键词“可能”、“必须”、“不得”、“应该”和“不应该”应按照RFC 2119[2]中的说明进行解释。
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 matches, then PXELINUX bootloaders will also consume options 209-211, as described below. Otherwise, they are ignored.
如果此选项提供给PXE引导加载程序，则PXELINUX将检查该值以匹配八位字节字符串f1:00:74:7e。如果匹配，那么PXELINUX引导加载程序也将使用选项209-211，如下所述。否则，它们将被忽略。
This measure was intended to ensure that, as the 'Site Local' option space is not allocated from a central authority, no conflict would result in a PXELINUX bootloader improperly digesting options intended for another purpose.
此措施旨在确保，由于“站点本地”选项空间不是由中央机构分配的，因此不会有冲突导致PXELINUX引导加载程序错误地消化用于其他目的的选项。
The MAGIC Option format is as follows:
魔术选项格式如下所示：
Code Length m1 m2 m3 m4
+--------+--------+--------+--------+--------+--------+
| 208 | 4 | 0xF1 | 0x00 | 0x74 | 0x7E |
+--------+--------+--------+--------+--------+--------+
Code Length m1 m2 m3 m4
+--------+--------+--------+--------+--------+--------+
| 208 | 4 | 0xF1 | 0x00 | 0x74 | 0x7E |
+--------+--------+--------+--------+--------+--------+
The code for this option is 208. The length is always four.
此选项的代码为208。长度总是四。
This option is absolutely inapplicable to any other purpose.
此选项绝对不适用于任何其他用途。
The option code 208 will be adopted for this purpose and immediately deprecated. Future standards action may return this option to an available status should it be necessary.
为此，将采用选项代码208，并立即弃用。如有必要，未来的标准行动可能会将此选项恢复为可用状态。
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 aforementioned magic value, the PXELINUX bootloader will take no special action.
从设计上看，使用此选项的冲突是无害的（至少从PXELINUX的角度来看是无害的）：如果它与前面提到的魔法值不匹配，PXELINUX引导加载程序将不采取特殊操作。
The PXELINUX project will deprecate the use of this option; future versions of the software will not evaluate its contents.
PXELINUX项目将拒绝使用此选项；软件的未来版本将不会评估其内容。
It is reasonable to utilize this option code for another purpose, but it is recommended to do this at a later time, given the desire to avoid potential collisions in legacy user bases.
将此选项代码用于其他目的是合理的，但建议以后再使用，因为希望避免遗留用户群中的潜在冲突。
Once the PXELINUX executable has been entered from the PXE bootloader, it evaluates this option and loads a file of that name via TFTP. The contents of this file serve to configure PXELINUX in its next stage of bootloading (specifying boot image names, locations, boot-time flags, text to present the user in menu selections, etc).
一旦从PXE引导加载程序输入了PXELINUX可执行文件，它将评估此选项并通过TFTP加载该名称的文件。此文件的内容用于在引导加载的下一阶段配置PXELINUX（指定引导映像名称、位置、引导时间标志、在菜单选择中显示用户的文本等）。
In the absence of this option, the PXELINUX agent will search the TFTP server (as determined by PXE prior to this stage) for a config file of several default names.
如果没有此选项，PXELINUX代理将在TFTP服务器（由PXE在此阶段之前确定）中搜索多个默认名称的配置文件。
The Configuration File Option format is as follows:
配置文件选项格式如下：
Code Length Config-file...
+--------+--------+--------+--------+--------+--------+
| 209 | n | c1 | c2 | ... | c(n) |
+--------+--------+--------+--------+--------+--------+
Code Length Config-file...
+--------+--------+--------+--------+--------+--------+
| 209 | n | c1 | c2 | ... | c(n) |
+--------+--------+--------+--------+--------+--------+
The code for this option is 209. The Config-file (c1..c(n)) is an NVT-ASCII [1] printable string; it is not terminated by a zero or any other value.
此选项的代码为209。配置文件（c1..c（n））是一个NVT-ASCII[1]可打印字符串；它不以零或任何其他值终止。
Any bootloader, PXE or otherwise, that makes use of a separate configuration file rather than containing all configurations within DHCP options (which may be impossible due to the limited space available for DHCP options) may conceivably make use of this option.
任何引导加载程序（PXE或其他）如果使用单独的配置文件，而不是包含DHCP选项中的所有配置（这可能是不可能的，因为DHCP选项的可用空间有限），则可以考虑使用此选项。
The code 209 will be adopted for this purpose.
为此，将采用209号规范。
The Config File Option MUST be supplied by the DHCP server if it appears on the Parameter Request List, but MUST also be supplied if the server administrator believed it would later be useful to the client (such as because the server is configured to offer a second-stage boot image, which they know will make use of it). The option MUST NOT be supplied if no value has been configured for it, or if a value of zero length has been configured.
如果配置文件选项出现在参数请求列表中，则必须由DHCP服务器提供，但如果服务器管理员认为该选项稍后对客户端有用，则也必须提供该选项（例如，因为服务器配置为提供第二阶段引导映像，他们知道将使用该映像）。如果未为该选项配置任何值，或已配置零长度值，则不得提供该选项。
The DHCP client MUST only cache this option in a location the second-stage bootloader may access.
DHCP客户端只能将此选项缓存在第二阶段引导加载程序可以访问的位置。
The second-stage bootloader MUST, in concert with other DHCP options and fields, use this option's value as a filename to be loaded via TFTP and read for further second-stage-loader-specific configuration parameters. The format and content of such a file is specific to the second-stage bootloader, and as such, is out of scope of this document.
第二阶段引导加载程序必须与其他DHCP选项和字段一起使用此选项的值作为文件名，通过TFTP加载，并读取更多第二阶段加载程序特定的配置参数。此类文件的格式和内容特定于第二阶段引导加载程序，因此不在本文档的范围内。
In PXELINUX' case, it is often the case that several different environments would have the same TFTP path prefix, but would have different filenames (for example: hosts' bootloader images and config files may be kept in a directory structure derived from their Media Access Control (MAC) address). Consequently, it was deemed worthwhile to deliver a TFTP path prefix configuration option, so that these two things could be configured separately in a DHCP Server configuration: the prefix and the possibly host-specific file location.
在PXELINUX的情况下，通常情况下，几个不同的环境将具有相同的TFTP路径前缀，但具有不同的文件名（例如：主机的引导加载程序映像和配置文件可能保存在从其媒体访问控制（MAC）地址派生的目录结构中）。因此，有必要提供TFTP路径前缀配置选项，以便在DHCP服务器配置中分别配置这两件事：前缀和可能的主机特定文件位置。
The actual filename that PXELINUX requests from its TFTP server is derived by prepending this value to the Config File Option above. Once this config file is loaded and during processing, any TFTP file paths specified within it are similarly processed -- prepending the contents of this option.
PXELINUX从其TFTP服务器请求的实际文件名是通过在上面的Config File选项前面加上该值而得到的。加载此配置文件后，在处理过程中，将对其中指定的任何TFTP文件路径进行类似的处理——在该选项的内容前面加上前缀。
The Path Prefix Option format is as follows:
路径前缀选项格式如下所示：
Code Length Path-Prefix...
+--------+--------+--------+--------+--------+--------+
| 210 | n | p1 | p2 | ... | p(n) |
+--------+--------+--------+--------+--------+--------+
Code Length Path-Prefix...
+--------+--------+--------+--------+--------+--------+
| 210 | n | p1 | p2 | ... | p(n) |
+--------+--------+--------+--------+--------+--------+
The code for this option is 210. The Path Prefix is an NVT-ASCII printable string; it is not terminated by zero or any other value.
此选项的代码为210。路径前缀是一个NVT-ASCII可打印字符串；它不以零或任何其他值终止。
This option came into existence because server administrators found it useful to configure the prefix and suffix of the config file path separately. A group of different PXE booting clients may use the same path prefix, but different filenames, or vice versa.
此选项之所以存在，是因为服务器管理员发现单独配置配置文件路径的前缀和后缀很有用。一组不同的PXE引导客户端可能使用相同的路径前缀，但文件名不同，反之亦然。
The 'shortcut' this represents is worthwhile, but it is questionable whether that needs to manifest itself on the protocol wire.
这代表的“快捷方式”是值得的，但这是否需要在协议线路上体现出来还是值得怀疑的。
It only becomes interesting from a protocol standpoint if other options are adopted that prefix this value as well -- performing a kind of string compression is highly beneficial to the limited available DHCP option space.
只有从协议的角度来看，如果还采用了前缀为该值的其他选项，它才会变得有趣——执行一种字符串压缩对有限的可用DHCP选项空间非常有益。
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 these fields is encoded on firmware of thousands of devices that can't or are not likely to be upgraded. Altering any behaviour here is likely to cause severe compatibility problems.
但它显然不适用于当前的任何使用，例如文件名头内容或DHCP启动文件名选项（#67）。这些字段的使用在数千个无法或不可能升级的设备的固件上进行编码。在这里改变任何行为都可能导致严重的兼容性问题。
Although compression of the TFTP-loaded configuration file contents is not a compelling factor, contrived configurations using these values may also exist: where each of a large variety of different clients load the same configuration file, with the same contents, but due to a differently configured path prefix actually load different images. Whether this sort of use is truly needed remains unproven.
尽管TFTP加载的配置文件内容的压缩不是一个令人信服的因素，但也可能存在使用这些值的人为配置：大量不同的客户端中的每一个都加载具有相同内容的相同配置文件，但由于不同配置的路径前缀，实际加载不同的映像。这种用途是否真的需要还没有得到证实。
The code 210 will be adopted for this purpose.
为此，将采用代码210。
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 the server administrator believed it would later be useful to the client (such as because the server is configured to offer a second-stage boot image that they know will make use of it). The option MUST NOT be supplied if no value has been configured for it, or if a value of zero length has been configured.
如果路径前缀选项出现在参数请求列表中，则该选项必须由DHCP服务器提供，但如果服务器管理员认为该选项稍后对客户端有用，则该选项也必须提供（例如，因为服务器配置为提供第二阶段引导映像，他们知道该映像将使用它）。如果未为该选项配置任何值，或已配置零长度值，则不得提供该选项。
The DHCP client MUST only cache this option in a location where the second-stage bootloader may access it.
DHCP客户端必须仅将此选项缓存在第二阶段引导加载程序可以访问它的位置。
The second-stage bootloader MUST prepend this option's value, if any, to the contents of the ConfigFile option prior to obtaining the resulting value via TFTP, or the default 'Config File Search Path', which the second-stage bootloader iterates in the absence of a Config File Option. The client MAY prepend the value to other configuration directives within that file once it has been loaded. The client MUST NOT prepend this option's value to any other DHCP option contents or field, unless explicitly stated in a document describing that option or field.
第二阶段引导加载程序必须在通过TFTP或默认“配置文件搜索路径”获取结果值之前，将此选项的值（如果有）预先添加到ConfigFile选项的内容中，第二阶段引导加载程序在没有配置文件选项的情况下迭代该路径。一旦加载该文件，客户机可以将该值前置到该文件中的其他配置指令。除非在描述该选项或字段的文档中明确说明，否则客户端不得将该选项的值前置到任何其他DHCP选项内容或字段。
Should PXELINUX be executed, and then for some reason, be unable to reach its TFTP server to continue bootstrapping, the client will, by default, reboot itself after 300 seconds have passed. This may be too long, too short, or inappropriate behaviour entirely, depending on the environment.
如果PXELINUX被执行，然后由于某种原因，无法到达其TFTP服务器继续引导，那么默认情况下，客户端将在300秒后重新引导自身。这可能太长、太短或完全不适当的行为，取决于环境。
By configuring a non-zero value in this option, admins can inform PXELINUX of which specific timeout is desired. The client will reboot itself if it fails to achieve its configured network resources within the specified number of seconds.
通过在此选项中配置非零值，管理员可以通知PXELINUX需要哪个特定超时。如果客户端未能在指定的秒数内实现其配置的网络资源，则客户端将重新启动自身。
This reboot will run through the system's normal boot-time execution 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 INIT state.
此重新启动将通过系统的正常启动时执行路径运行，很可能会将其引导回PXE，从而导致PXELINUX。因此，在一般情况下，这类似于将客户端返回到DHCP初始状态。
By configuring zero, the feature is disabled, and instead the client chooses to remove itself from the network and wait indefinitely for operator intervention.
通过配置zero，该功能将被禁用，而客户机选择从网络中删除自己，并无限期地等待操作员干预。
It should be stressed that this is in no way related to configuring a lease time. The perceived transition to INIT state is due to client running state -- reinitializing itself -- not due to lease timer activity. That is, it is not safe to assume that a PXELINUX client will abandon its lease when this timer expires.
应该强调的是，这与配置租赁时间无关。感知到的到INIT状态的转换是由于客户端运行状态——重新初始化自身——而不是由于租约计时器活动。也就是说，假设PXELINUX客户端在该计时器过期时将放弃其租约是不安全的。
The Reboot Time Option format is as follows:
重新启动时间选项格式如下：
Code Length
+--------+--------+--------+--------+--------+--------+
| 211 | 4 | Reboot Time |
+--------+--------+--------+--------+--------+--------+
Code Length
+--------+--------+--------+--------+--------+--------+
| 211 | 4 | Reboot Time |
+--------+--------+--------+--------+--------+--------+
The code for this option is 211. The length is always four. The Reboot Time is a 32-bit (4 byte) integer in network byte order.
此选项的代码为211。长度总是四。重新启动时间是网络字节顺序的32位（4字节）整数。
Any network bootstrap program in any sufficiently complex networking environment could conceivably enter into such a similar condition, either due to having its IP address stolen out from under it by a rogue client on the network, by being moved between networks where its PXE-derived DHCP lease is no longer valid, or any similar means.
任何足够复杂的网络环境中的任何网络引导程序都可能进入类似的状态，原因可能是网络上的恶意客户端从其下窃取了其IP地址，也可能是在其PXE派生的DHCP租约不再有效的网络之间移动，或者是任何类似的方式。
It seems desirable for any network bootstrap agent to implement an ultimate timeout for it to start over.
似乎任何网络引导代理都需要实现一个最终超时，以便重新启动。
The client may, for example, get different working configuration parameters from a different DHCP server upon restarting.
例如，客户端可能在重新启动时从不同的DHCP服务器获取不同的工作配置参数。
The code 211 will be adopted for this purpose.
为此，将采用代码211。
The Reboot Time Option MUST be supplied by the DHCP server if it appears on the Parameter Request List, but MUST also be supplied if the server administrator believed it would later be useful to the client (such as because the server is configured to offer a second-stage boot image that they know will make use of it). The option MUST NOT be supplied if no value has been configured for it, or if it contains a value of zero length.
如果重新启动时间选项出现在参数请求列表中，则必须由DHCP服务器提供，但如果服务器管理员认为该选项稍后对客户端有用，则必须提供该选项（例如，因为服务器配置为提供第二阶段引导映像，他们知道该映像将使用该映像）。如果没有为该选项配置值，或者该选项包含零长度值，则不得提供该选项。
The DHCP client MUST only cache this option in a location the second-stage bootloader may access.
DHCP客户端只能将此选项缓存在第二阶段引导加载程序可以访问的位置。
If the value of this option is nonzero, the second-stage bootloader MUST schedule a timeout: after a number of seconds equal to this option's value have passed, the second-stage bootloader MUST reboot the system, ultimately returning the path of execution back to the first-stage bootloader. It MUST NOT reboot the system once the thread of execution has been passed to the host operating system (at which point, this timeout is effectively obviated).
如果此选项的值为非零，则第二阶段引导加载程序必须安排超时：在经过与此选项值相等的秒数后，第二阶段引导加载程序必须重新启动系统，最终将执行路径返回第一阶段引导加载程序。一旦执行线程被传递到主机操作系统，它就不能重新启动系统（此时，此超时有效地被消除）。
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 finds it has encountered excessive timeouts attempting to obtain its host operating system SHOULD disconnect itself from the network to wait for operator intervention, but MAY continue to attempt to acquire the host operating system indefinitely.
如果此选项的值为零，则第二阶段引导加载程序不得安排此类超时。任何第二阶段引导加载程序发现其在尝试获取其主机操作系统时遇到过多超时，应断开自身与网络的连接，以等待操作员干预，但可能会继续尝试无限期获取主机操作系统。
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.
MAGIC选项可能无法实现，因为它已被弃用。
PXE and PXELINUX allow any entity acting as a DHCP server to execute arbitrary code upon a system. At present, no PXE implementation is known to implement authentication mechanisms [7] so that PXE clients can be sure they are receiving configuration information from the correct, authoritative DHCP server.
PXE和PXELINUX允许任何充当DHCP服务器的实体在系统上执行任意代码。目前，还没有已知的PXE实现来实现身份验证机制[7]，因此PXE客户端可以确保他们从正确的权威DHCP服务器接收配置信息。
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 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 exposed (such as in loading a "RAMDISK" image, which contains /etc/passwd or similar information).
PXE和PXELINUX使用TFTP也缺乏任何形式的加密签名——因此“中间人”攻击可能导致攻击者的代码在客户端系统上执行。由于这不是加密通道，因此也可以公开任何TFTP加载的数据（例如在加载包含/etc/passwd或类似信息的“RAMDISK”映像时）。
The use of the Ethernet MAC Address as the client's unique identity may allow an attacker who takes on that identity to gain inappropriate access to a client system's network resources by being given by the DHCP server whatever 'keys' are required, in fact, to be the target system (to boot up as though it were the target).
使用以太网MAC地址作为客户端的唯一身份可能会允许攻击者通过DHCP服务器提供目标系统所需的任何“密钥”来获得对客户端系统网络资源的不适当访问，事实上，这是目标系统（将其作为目标系统启动）。
Great care should be taken to secure PXE and PXELINUX installations, such as by using IP firewalls, to reduce or eliminate these concerns.
应特别注意PXE和PXELINUX安装的安全，如使用IP防火墙，以减少或消除这些问题。
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 (DoS) upon the DHCP server, but then again it may just as easily supply these clients with rogue second-stage bootloaders that simply transmit a flood of packets.
附近的攻击者可能会向大量毫无戒心的客户端提供1秒的“重新启动时间”选项值，从而在DHCP服务器上实施拒绝服务（DoS），但同样，它也可能会向这些客户端提供恶意的第二阶段引导加载程序，这些程序只会传输大量数据包。
This document in and by itself provides no security, nor does it impact existing DCHP security as described in RFC 2131 [3].
本文档本身不提供安全性，也不影响RFC 2131[3]中所述的现有DCHP安全性。
IANA has done the following:
IANA已完成以下工作：
1. Moved DHCPv4 Option code 208 from 'Tentatively Assigned' to 'Assigned', referencing this document. IANA has marked this same option code, 208, as Deprecated.
1. 参考本文件，将DHCPv4选项代码208从“暂定分配”移至“已分配”。IANA已将同一选项代码208标记为已弃用。
2. Moved DHCPv4 Option code 209 from 'Tentatively Assigned' to 'Assigned', referencing this document.
2. 参考此文档，将DHCPv4选项代码209从“暂定分配”移动到“已分配”。
3. Moved DHCPv4 Option code 210 from 'Tentatively Assigned' to 'Assigned', referencing this document.
3. 参考此文档，将DHCPv4选项代码210从“暂定分配”移动到“已分配”。
4. Moved DHCPv4 Option code 211 from 'Tentatively Assigned' to 'Assigned', referencing this document.
4. 参考此文档，将DHCPv4选项代码211从“暂定分配”移动到“已分配”。
These options were designed and implemented for the PXELINUX project by H. Peter Anvin, and he was instrumental in producing this document. Shane Kerr has also provided feedback that has improved this document.
这些选项是由H.Peter Anvin为PXELINUX项目设计和实施的，他在编写本文档时发挥了重要作用。Shane Kerr还提供了改进本文件的反馈。
[1] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[1] Postel，J.和J.Reynolds，“Telnet协议规范”，STD 8，RFC 854，1983年5月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[3] Droms，R.，“动态主机配置协议”，RFC 2131，1997年3月。
[4] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[4] Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[5] Droms, R., "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", BCP 43, RFC 2939, September 2000.
[5] Droms，R.，“新DHCP选项和消息类型定义的程序和IANA指南”，BCP 43，RFC 2939，2000年9月。
[6] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, July 1992.
[6] Sollins，K.，“TFTP协议（第2版）”，STD 33，RFC 1350，1992年7月。
[7] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[7] Droms，R.和W.Arbaugh，“DHCP消息的身份验证”，RFC31182001年6月。
[8] Volz, B., "Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options", RFC 3942, November 2004.
[8] Volz，B.“重新分类动态主机配置协议版本4（DHCPv4）选项”，RFC 3942，2004年11月。
Author's Address
作者地址
David W. Hankins Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 US
David W.Hankins Internet Systems Consortium，Inc.位于美国加利福尼亚州红木市Charter Street 950号，邮编94063
Phone: +1 650 423 1307
EMail: David_Hankins@isc.org
Phone: +1 650 423 1307
EMail: David_Hankins@isc.org
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.