Network Working Group M. Johnston
Request for Comments: 4578 Intel Corporation
Category: Informational S. Venaas, Ed.
UNINETT
November 2006
Network Working Group M. Johnston
Request for Comments: 4578 Intel Corporation
Category: Informational S. Venaas, Ed.
UNINETT
November 2006
Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE)
英特尔预引导执行环境（PXE）的动态主机配置协议（DHCP）选项
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.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
Abstract
摘要
We define Dynamic Host Configuration Protocol (DHCP) options being used by Preboot eXecution Environment (PXE) and Extensible Firmware Interface (EFI) clients to uniquely identify booting client machines and their pre-OS runtime environment so that the DHCP and/or PXE boot server can return the correct OS bootstrap image (or pre-boot application) name and server to the client.
我们定义了预引导执行环境（PXE）和可扩展固件接口（EFI）客户端使用的动态主机配置协议（DHCP）选项，以唯一标识引导客户端计算机及其预操作系统运行时环境，以便DHCP和/或PXE引导服务器可以返回正确的操作系统引导映像（或预引导应用程序）将名称和服务器添加到客户端。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Requirements Language ......................................2
2. Option Definitions ..............................................2
2.1. Client System Architecture Type Option Definition ..........2
2.2. Client Network Interface Identifier Option Definition ......3
2.3. Client Machine Identifier Option Definition ................4
2.4. Options Requested by PXE Clients ...........................4
3. Acknowledgements ................................................5
4. IANA Considerations .............................................5
5. Security Considerations .........................................5
6. Normative References ............................................5
1. Introduction ....................................................2
1.1. Requirements Language ......................................2
2. Option Definitions ..............................................2
2.1. Client System Architecture Type Option Definition ..........2
2.2. Client Network Interface Identifier Option Definition ......3
2.3. Client Machine Identifier Option Definition ................4
2.4. Options Requested by PXE Clients ...........................4
3. Acknowledgements ................................................5
4. IANA Considerations .............................................5
5. Security Considerations .........................................5
6. Normative References ............................................5
These DHCP [2] options are being widely used by PXE-compliant clients to uniquely identify booting client machines themselves and their pre-OS runtime environment so that the DHCP and/or PXE boot server can return the correct OS bootstrap image (or pre-boot application) name and server to the client. In the past, this work was done by examining the network Media Access Code (MAC) address in the "chaddr" field in the BOOTP/ DHCP header and keeping a database of MAC addresses on the BOOTP/DHCP server. This was deemed insufficient for large and complex networks for two main reasons. 1) Multiple laptops could end up with the same MAC address if the network interface was in a shared docking station. 2) Multiple network devices and MAC addresses could be used by one machine for redundancy or because of repairs. Another issue that came up was the machine that could change its pre-OS runtime environment. This issue caused the creation of another new option to identify the runtime environment so that the correct binary image could be matched up with the booting machine. These options are defined by Intel in the PXE [3] and EFI [4] specifications and are being documented in this draft for completeness within the IETF.
这些DHCP[2]选项正被PXE兼容客户端广泛使用，以唯一地标识引导客户端计算机本身及其操作系统前运行时环境，以便DHCP和/或PXE引导服务器可以将正确的操作系统引导映像（或预引导应用程序）名称和服务器返回给客户端。在过去，这项工作是通过检查BOOTP/DHCP头中“chaddr”字段中的网络媒体访问代码（MAC）地址并在BOOTP/DHCP服务器上保留MAC地址数据库来完成的。由于两个主要原因，这对于大型复杂网络来说是不够的。1） 如果网络接口位于共享扩展底座中，则多台笔记本电脑可能最终具有相同的MAC地址。2） 一台机器可以使用多个网络设备和MAC地址进行冗余或修复。出现的另一个问题是可能改变其操作系统运行前环境的机器。此问题导致创建另一个新选项来标识运行时环境，以便正确的二进制映像可以与引导计算机匹配。这些选项由Intel在PXE[3]和EFI[4]规范中定义，并记录在本草案中，以确保IETF中的完整性。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
There are three DHCP options [5] defined for use by PXE clients.
PXE客户端定义了三个DHCP选项[5]。
The format of the option is:
该选项的格式为：
Code Len 16-bit Type
+----+-----+-----+-----+
| 93 | n | n1 | n2 |
+----+-----+-----+-----+
Code Len 16-bit Type
+----+-----+-----+-----+
| 93 | n | n1 | n2 |
+----+-----+-----+-----+
Octet "n" gives the number of octets containing "architecture types" (not including the code and len fields). It MUST be an even number greater than zero. Clients that support more than one architecture type MAY include a list of these types in their initial DHCP and PXE boot server packets. The list of supported architecture types MAY be reduced in any packet exchange between the client and server(s). Octets "n1" and "n2" encode a 16-bit architecture type identifier that describes the pre-boot runtime environment(s) of the client machine.
八位字节“n”给出包含“架构类型”的八位字节数（不包括代码和len字段）。它必须是大于零的偶数。支持多个体系结构类型的客户端可能会在其初始DHCP和PXE引导服务器数据包中包含这些类型的列表。在客户端和服务器之间的任何分组交换中，支持的体系结构类型的列表可以减少。八位字节“n1”和“n2”编码一个16位体系结构类型标识符，该标识符描述客户机的预引导运行时环境。
As of the writing of this document, the following pre-boot architecture types have been requested.
在编写本文档时，已请求以下预引导体系结构类型。
Type Architecture Name
---- -----------------
0 Intel x86PC
1 NEC/PC98
2 EFI Itanium
3 DEC Alpha
4 Arc x86
5 Intel Lean Client
6 EFI IA32
7 EFI BC
8 EFI Xscale
9 EFI x86-64
Type Architecture Name
---- -----------------
0 Intel x86PC
1 NEC/PC98
2 EFI Itanium
3 DEC Alpha
4 Arc x86
5 Intel Lean Client
6 EFI IA32
7 EFI BC
8 EFI Xscale
9 EFI x86-64
This option MUST be present in all DHCP and PXE packets sent by PXE-compliant clients and servers.
此选项必须出现在所有符合PXE的客户端和服务器发送的DHCP和PXE数据包中。
The format of the option is:
该选项的格式为：
Code Len Type Major Minor
+----+-----+----+-----+-----+
| 94 | 3 | t | M | m |
+----+-----+----+-----+-----+
Code Len Type Major Minor
+----+-----+----+-----+-----+
| 94 | 3 | t | M | m |
+----+-----+----+-----+-----+
Octet "t" encodes a network interface type. For now the only supported value is 1 for Universal Network Device Interface (UNDI). Octets "M" and "m" describe the interface revision. To encode the UNDI revision of 2.11, "M" would be set to 2, and "m" would be set to 11 (0x0B).
八位组“t”编码网络接口类型。目前，通用网络设备接口（UNDI）唯一支持的值是1。八位字节“M”和“M”描述接口修订。要对UNDI修订版2.11进行编码，“M”将设置为2，“M”将设置为11（0x0B）。
Revision Description
-------- -----------
< 2.00 LANDesk service agent boot ROMs. No PXE APIs.
Revision Description
-------- -----------
< 2.00 LANDesk service agent boot ROMs. No PXE APIs.
2.00 First generation PXE boot ROMs. (PXENV+) [3]
2.00 第一代PXE引导ROM。（pxev+）[3]
2.01 Second generation PXE boot ROMs. (!PXE) [3]
2.01 第二代PXE引导ROM。（！PXE）[3]
3.00 32/64-bit UNDI specification. (Alpha) [4] EFI boot services driver only. No EFI runtime support.
3.00 32/64位UNDI规范。（Alpha）[4]仅限EFI引导服务驱动程序。没有EFI运行时支持。
3.10 32/64-bit UNDI specification. (Beta) [4] First generation EFI runtime driver support.
3.10 32/64位UNDI规范。（测试版）[4]第一代EFI运行时驱动程序支持。
3.20 32/64-bit UNDI specification. (Release) [4] Second generation EFI runtime driver support.
3.20 32/64位UNDI规范。（发布）[4]第二代EFI运行时驱动程序支持。
This option MUST be present in all DHCP and PXE packets sent by PXE-compliant clients and servers.
此选项必须出现在所有符合PXE的客户端和服务器发送的DHCP和PXE数据包中。
The format of the option is:
该选项的格式为：
Code Len Type Machine Identifier
+----+-----+----+-----+ . . . +-----+
| 97 | n | t | | . . . | |
+----+-----+----+-----+ . . . +-----+
Code Len Type Machine Identifier
+----+-----+----+-----+ . . . +-----+
| 97 | n | t | | . . . | |
+----+-----+----+-----+ . . . +-----+
Octet "t" describes the type of the machine identifier in the remaining octets in this option. 0 (zero) is the only value defined for this octet at the present time, and it describes the remaining octets as a 16-octet Globally Unique Identifier (GUID). Octet "n" is 17 for type 0. (One definition of GUID can be found in Appendix A of the EFI specification [4].)
八位字节“t”描述此选项中剩余八位字节中的机器标识符类型。0（零）是目前为此八位字节定义的唯一值，它将剩余八位字节描述为16位八位字节全局唯一标识符（GUID）。对于类型0，八位组“n”为17。（在EFI规范[4]的附录A中可以找到GUID的一个定义。）
This option MUST be present in all DHCP and PXE packets sent by PXE-compliant clients and servers.
此选项必须出现在所有符合PXE的客户端和服务器发送的DHCP和PXE数据包中。
All compliant PXE clients MUST include a request for DHCP options 128 through 135 in all DHCP and PXE packets. The format and contents of these options are NOT defined by the PXE specification. These options MAY be present in the DHCP and PXE boot server replies and are meant for use by the downloaded network bootstrap programs. These options are NOT used by the PXE boot ROMs.
所有兼容的PXE客户端必须在所有DHCP和PXE数据包中包含对DHCP选项128到135的请求。PXE规范未定义这些选项的格式和内容。这些选项可能出现在DHCP和PXE引导服务器回复中，供下载的网络引导程序使用。PXE引导ROM不使用这些选项。
As options 128-135 are not officially assigned for PXE use (before November 2004 they were considered site-specific options, [6]), use of these option values for PXE may conflict with other uses of the same options on the same networks.
由于选项128-135未正式分配给PXE使用（在2004年11月之前，它们被视为特定于现场的选项[6]），因此在PXE中使用这些选项值可能会与相同网络上相同选项的其他使用发生冲突。
The authors thank Bernie Volz for valuable input.
作者感谢Bernie Volz的宝贵意见。
IANA has updated the numbering space defined for public DHCP options in [7] with references to this document for options 93, 94, and 97 (previously, there were references to [8]). Also, IANA marked options 128-135 as being used by PXE and referenced this document.
IANA已更新了[7]中为公共DHCP选项定义的编号空间，并参考了本文件中选项93、94和97（之前，曾参考[8]）。此外，IANA将选项128-135标记为PXE正在使用，并引用了本文件。
By specifying incorrect values for some of these options, a client may get access to, and possibly attempt to execute, code intended for another platform or client. This may have security ramifications. Also note that these options contain information about a client's system architecture and pre-OS runtime environment that is revealed to anyone who is able to listen in on DHCP messages sent by the client. This information may be of use to potential attackers.
通过为其中一些选项指定不正确的值，客户机可以访问并可能尝试执行用于其他平台或客户机的代码。这可能会对安全产生影响。还请注意，这些选项包含有关客户端的系统体系结构和操作系统运行前环境的信息，这些信息将向能够侦听客户端发送的DHCP消息的任何人公开。此信息可能对潜在攻击者有用。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[2] Droms，R.，“动态主机配置协议”，RFC 2131，1997年3月。
[3] Henry, M. and M. Johnston, "Preboot Execution Environment (PXE) Specification", September 1999, <http://www.pix.net/software/pxeboot/archive/pxespec.pdf>.
[3] Henry，M.和M.Johnston，“预引导执行环境（PXE）规范”，1999年9月<http://www.pix.net/software/pxeboot/archive/pxespec.pdf>.
[4] Intel Corp., "Extensible Firmware Interface Specification", December 2002, <http://developer.intel.com/technology/efi/ main_specification.htm>.
[4] 英特尔公司，“可扩展固件接口规范”，2002年12月<http://developer.intel.com/technology/efi/ main_specification.htm>。
[5] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[5] Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[6] Volz, B., "Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options", RFC 3942, November 2004.
[6] Volz，B.“重新分类动态主机配置协议版本4（DHCPv4）选项”，RFC 3942，2004年11月。
[7] Droms, R., "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", BCP 43, RFC 2939, September 2000.
[7] Droms，R.，“新DHCP选项和消息类型定义的程序和IANA指南”，BCP 43，RFC 2939，2000年9月。
[8] Droms, R., "Unused Dynamic Host Configuration Protocol (DHCP) Option Codes", RFC 3679, January 2004.
[8] Droms，R.，“未使用的动态主机配置协议（DHCP）选项代码”，RFC 3679，2004年1月。
Authors' Addresses
作者地址
Michael Johnston Intel Corporation MS. JF1-239 2111 NE 25th Ave. Hillsboro, OR 97124 USA
迈克尔·约翰斯顿英特尔公司JF1-239 2111美国希尔斯伯勒东北25大街，邮编：97124
Phone: +1 503-264-9703
EMail: michael.johnston@intel.com
Phone: +1 503-264-9703
EMail: michael.johnston@intel.com
Stig Venaas UNINETT Trondheim NO-7465 Norway
挪威第7465号特隆赫姆施蒂格·维纳斯酒店
EMail: venaas@uninett.no
EMail: venaas@uninett.no
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。