Internet Engineering Task Force (IETF) T. Huth
Request for Comments: 5970 J. Freimann
Category: Standards Track IBM Germany R&D GmbH
ISSN: 2070-1721 V. Zimmer
Intel
D. Thaler
Microsoft
September 2010
Internet Engineering Task Force (IETF) T. Huth
Request for Comments: 5970 J. Freimann
Category: Standards Track IBM Germany R&D GmbH
ISSN: 2070-1721 V. Zimmer
Intel
D. Thaler
Microsoft
September 2010
DHCPv6 Options for Network Boot
用于网络引导的DHCPv6选项
Abstract
摘要
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a framework for passing configuration information to nodes on a network. This document describes new options for DHCPv6 that SHOULD be used for booting a node from the network.
IPv6动态主机配置协议（DHCPv6）提供了一个框架，用于将配置信息传递给网络上的节点。本文档介绍了DHCPv6的新选项，这些选项应用于从网络引导节点。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5970.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5970.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Conventions .....................................................3
3. Options .........................................................3
3.1. Boot File Uniform Resource Locator (URL) Option ............3
3.2. Boot File Parameters Option ................................4
3.3. Client System Architecture Type Option .....................5
3.4. Client Network Interface Identifier Option .................6
4. Appearance of the Options .......................................7
5. Download Protocol Considerations ................................7
6. IANA Considerations .............................................7
7. Security Considerations .........................................8
8. Acknowledgements ................................................8
9. References ......................................................9
9.1. Normative References .......................................9
9.2. Informative References .....................................9
1. Introduction ....................................................2
2. Conventions .....................................................3
3. Options .........................................................3
3.1. Boot File Uniform Resource Locator (URL) Option ............3
3.2. Boot File Parameters Option ................................4
3.3. Client System Architecture Type Option .....................5
3.4. Client Network Interface Identifier Option .................6
4. Appearance of the Options .......................................7
5. Download Protocol Considerations ................................7
6. IANA Considerations .............................................7
7. Security Considerations .........................................8
8. Acknowledgements ................................................8
9. References ......................................................9
9.1. Normative References .......................................9
9.2. Informative References .....................................9
This document describes DHCPv6 options that SHOULD be used to provide configuration information for a node that must be booted using the network rather than from local storage.
本文档介绍了DHCPv6选项，这些选项应用于为必须使用网络而不是从本地存储引导的节点提供配置信息。
Network booting is used, for example, in some environments where administrators have to maintain a large number of nodes. By serving all boot and configuration files from a central server, the effort required to maintain these nodes is greatly reduced.
例如，在管理员必须维护大量节点的某些环境中，会使用网络引导。通过从中央服务器提供所有引导和配置文件，可以大大减少维护这些节点所需的工作量。
A typical boot file would be, for example, an operating system kernel or a boot-loader program. To be able to execute such a file, the firmware running on the client node must perform the following two steps (see Figure 1): First get all information that is required for downloading and executing the boot file. Second, download the boot file and execute it.
例如，典型的引导文件是操作系统内核或引导加载程序。为了能够执行这样的文件，客户端节点上运行的固件必须执行以下两个步骤（参见图1）：首先获取下载和执行引导文件所需的所有信息。其次，下载引导文件并执行它。
+------+
_______________________\| DHCP |
/ 1 Get boot file info /|Server|
+------+ +------+
| Host |
+------+ +------+
\_______________________\| File |
2 Download boot file /|Server|
+------+
+------+
_______________________\| DHCP |
/ 1 Get boot file info /|Server|
+------+ +------+
| Host |
+------+ +------+
\_______________________\| File |
2 Download boot file /|Server|
+------+
Figure 1: Network Boot Sequence
图1：网络引导顺序
The information that is required for booting over the network MUST include at least the details about the server on which the boot files can be found, the protocol to be used for the download (for example, HTTP [RFC2616] or TFTP [RFC1350]), and the path and name of the boot file on the server. Additionally, the server and client MAY exchange information about the parameters that should be passed to the OS kernel or boot-loader program, respectively, or information about the supported boot environment.
通过网络引导所需的信息必须至少包括有关可在其中找到引导文件的服务器的详细信息、用于下载的协议（例如，HTTP[RFC2616]或TFTP[RFC1350]）以及服务器上引导文件的路径和名称。此外，服务器和客户机可以交换有关应分别传递给操作系统内核或引导加载程序的参数的信息，或有关支持的引导环境的信息。
DHCPv6 allows client nodes to ask a DHCPv6 server for configuration parameters. This document provides new options that a client can request from the DHCPv6 server to satisfy its requirements for booting. It also introduces a new IANA registry for processor architecture types that are used by the OPTION_CLIENT_ARCH_TYPE option (see Section 3.3).
DHCPv6允许客户端节点向DHCPv6服务器请求配置参数。本文档提供了新的选项，客户机可以从DHCPv6服务器请求这些选项以满足其引导要求。它还为OPTION_CLIENT_ARCH_TYPE选项使用的处理器体系结构类型引入了一个新的IANA注册表（请参见第3.3节）。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Terminology specific to IPv6 and DHCPv6 are used in the same way as is defined in the "Terminology" sections of [RFC3315].
IPv6和DHCPv6专用术语的使用方式与[RFC3315]中“术语”部分的定义相同。
Option formats comply with DHCPv6 options per [RFC3315] (Section 6). The boot-file-url option (see Section 3.1) is mandatory for booting, all other options are optional.
根据[RFC3315]（第6节），选项格式符合DHCPv6选项。引导文件url选项（见第3.1节）对于引导是必需的，所有其他选项都是可选的。
The server sends this option to inform the client about a URL to a boot file.
服务器发送此选项以通知客户端启动文件的URL。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPT_BOOTFILE_URL | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. boot-file-url (variable length) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPT_BOOTFILE_URL | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. boot-file-url (variable length) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format description:
格式说明：
option-code OPT_BOOTFILE_URL (59).
选项代码OPT_BOOTFILE_URL（59）。
option-len Length of the boot-file-url in octets.
选项len启动文件url的长度（以八位字节为单位）。
boot-file-url This string is the URL for the boot file. It MUST comply with STD 66 [RFC3986]. The string is not NUL-terminated.
启动文件url此字符串是启动文件的url。它必须符合STD 66[RFC3986]。字符串不是以NUL结尾的。
If the host in the URL is expressed using an IPv6 address rather than a domain name, the address in the URL then MUST be enclosed in "[" and "]" characters, conforming to [RFC3986]. Clients that have DNS implementations SHOULD support the use of domain names in the URL.
如果URL中的主机使用IPv6地址而不是域名表示，则URL中的地址必须包含在“[”和“]”字符中，符合[RFC3986]。具有DNS实现的客户端应支持在URL中使用域名。
This option is sent by the server to the client. It consists of multiple UTF-8 ([RFC3629]) strings. They are used to specify parameters for the boot file (similar to the command line arguments in most modern operating systems). For example, these parameters could be used to specify the root file system of the OS kernel, or the location from which a second-stage boot-loader program can download its configuration file.
此选项由服务器发送到客户端。它由多个UTF-8（[RFC3629]）字符串组成。它们用于指定启动文件的参数（类似于大多数现代操作系统中的命令行参数）。例如，这些参数可用于指定操作系统内核的根文件系统，或第二阶段引导加载程序可从中下载其配置文件的位置。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPT_BOOTFILE_PARAM | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| param-len 1 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ parameter 1 .
. (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. <multiple Parameters> .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| param-len n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ parameter n .
. (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPT_BOOTFILE_PARAM | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| param-len 1 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ parameter 1 .
. (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. <multiple Parameters> .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| param-len n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ parameter n .
. (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format description:
格式说明：
option-code OPT_BOOTFILE_PARAM (60).
选项代码OPT_BOOTFILE_PARAM（60）。
option-len Length of the Boot File Parameters option in octets (not including the size of the option-code and option-len fields).
选项len启动文件参数选项的长度，以八位字节为单位（不包括选项代码和选项len字段的大小）。
param-len 1...n This is a 16-bit integer that specifies the length of the following parameter in octets (not including the parameter-length field).
param len 1…n这是一个16位整数，以八位字节为单位指定以下参数的长度（不包括参数长度字段）。
parameter 1...n These UTF-8 strings are parameters needed for booting, e.g., kernel parameters. The strings are not NUL-terminated.
参数1…n这些UTF-8字符串是引导所需的参数，例如内核参数。字符串不是以NUL结尾的。
When the boot firmware executes the boot file that has been specified in the OPT_BOOTFILE_URL option, it MUST pass these parameters, if present, in the order that they appear in the OPT_BOOTFILE_PARAM option.
当引导固件执行在OPT_BOOTFILE_URL选项中指定的引导文件时，它必须按照这些参数在OPT_BOOTFILE_PARAM选项中出现的顺序传递这些参数（如果存在）。
This option provides parity with the Client System Architecture Type option defined for DHCPv4 in Section 2.1 of [RFC4578].
此选项提供与[RFC4578]第2.1节中为DHCPv4定义的客户机系统架构类型选项的奇偶性。
The format of the option is:
该选项的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_CLIENT_ARCH_TYPE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. architecture-types (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_CLIENT_ARCH_TYPE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. architecture-types (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_CLIENT_ARCH_TYPE (61).
选项代码选项\客户\拱门\类型（61）。
option-len Length of the "architecture-types" field in octets. It MUST be an even number greater than zero. See Section 2.1 of [RFC4578] for details.
选项len“架构类型”字段的长度（以八位字节为单位）。它必须是大于零的偶数。详见[RFC4578]第2.1节。
architecture-types A list of one or more architecture types, as specified in Section 2.1 of [RFC4578]. Each architecture type identifier in this list is a 16-bit value that describes the pre-boot runtime
体系结构类型[RFC4578]第2.1节中规定的一种或多种体系结构类型的列表。此列表中的每个体系结构类型标识符都是一个16位的值，用于描述预引导运行时
environment of the client machine. A list of valid values is maintained by the IANA (see Section 6).
客户端计算机的环境。IANA维护有效值列表（见第6节）。
The client MAY use this option to send a list of supported architecture types to the server, so the server can decide which boot file should be provided to the client. If a client supports more than one pre-boot environment (for example, both 32-bit and 64-bit executables), the most preferred architecture type MUST be listed as first item, followed by the others with descending priority.
客户端可以使用此选项向服务器发送受支持的体系结构类型列表，以便服务器可以决定应向客户端提供哪个引导文件。如果客户机支持多个预引导环境（例如，32位和64位可执行文件），则最首选的体系结构类型必须列为第一项，然后是其他优先级递减的体系结构类型。
If the client used this option in the request, the server SHOULD include this option to inform the client about the pre-boot environments that are supported by the boot file. The list MUST only contain architecture types that have initially been queried by the client. The items MUST also be listed in order of descending priority.
如果客户机在请求中使用了此选项，服务器应包括此选项，以通知客户机启动文件支持的预启动环境。该列表必须仅包含客户端最初查询过的体系结构类型。项目还必须按优先级降序排列。
If the client supports the Universal Network Device Interface (UNDI) (see [PXE21] and [UEFI23]), it may send the Client Network Interface Identifier option to a DHCP server to provide information about its level of UNDI support.
如果客户机支持通用网络设备接口（UNDI）（参见[PXE21]和[UEFI23]），它可以将客户机网络接口标识符选项发送到DHCP服务器，以提供有关其UNDI支持级别的信息。
This option provides parity with the Client Network Interface Identifier option defined for DHCPv4 in Section 2.2 of [RFC4578].
此选项提供与[RFC4578]第2.2节中为DHCPv4定义的客户端网络接口标识符选项的奇偶校验。
The format of the option is:
该选项的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_NII | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Major | Minor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_NII | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Major | Minor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_NII (62).
选项代码选项NII（62）。
option-len 3
选项len 3
Type As specified in Section 2.2 of [RFC4578].
[RFC4578]第2.2节中规定的类型。
Major As specified in Section 2.2 of [RFC4578].
[RFC4578]第2.2节中规定的主要部件。
Minor As specified in Section 2.2 of [RFC4578].
[RFC4578]第2.2节中规定的小调。
The list of valid Type, Major, and Minor values is maintained in the Unified Extensible Firmware Interface specification [UEFI23].
有效类型、主要值和次要值的列表保存在统一可扩展固件接口规范[UEFI23]中。
These options MUST NOT appear in DHCPv6 messages other than the types Solicit, Advertise, Request, Renew, Rebind, Information-Request, and Reply.
除了请求、播发、请求、续订、重新绑定、信息请求和回复类型之外，这些选项不得出现在DHCPv6消息中。
The option-codes of these options MAY appear in the Option Request option in the DHCPv6 message types Solicit, Request, Renew, Rebind, Information-Request, and Reconfigure.
这些选项的选项代码可能出现在DHCPv6消息类型“请求、请求、续订、重新绑定、信息请求和重新配置”中的“选项请求”选项中。
The Boot File URL option does not place any constraints on the protocol used for downloading the boot file, other than that it MUST be possible to specify it in a URL. For the sake of administrative simplicity, we strongly recommend that, at a minimum, implementers of network boot loaders implement the well-known and established HyperText Transfer Protocol (HTTP) [RFC2616] for downloading. Please note that for IPv6, this supersedes [RFC906], which recommended using TFTP for downloading (see [RFC3617] for the 'tftp' URL definition).
启动文件URL选项不会对用于下载启动文件的协议施加任何约束，除非必须能够在URL中指定它。为了简化管理，我们强烈建议网络引导加载程序的实现者至少实现众所周知的和已建立的超文本传输协议（HTTP）[RFC2616]进行下载。请注意，对于IPv6，这将取代[RFC906]，后者建议使用TFTP下载（“TFTP”URL定义请参见[RFC3617]）。
When using the Internet Small Computer System Interface (iSCSI) for booting, the 'iscsi' URI is formed as defined in [RFC4173]. The functionality attributed in RFC 4173 to a root path option is provided for IPv6 by the Boot File URL option instead.
使用Internet小型计算机系统接口（iSCSI）进行引导时，“iSCSI”URI的格式如[RFC4173]中所定义。RFC 4173中归属于根路径选项的功能由引导文件URL选项提供给IPv6。
The following options have been assigned by the IANA from the option number space defined in Section 24 of the DHCPv6 RFC [RFC3315].
IANA根据DHCPv6 RFC[RFC3315]第24节中定义的选项编号空间分配了以下选项。
+-------------------------+-------+--------------+
| Option name | Value | Specified in |
+-------------------------+-------+--------------+
| OPT_BOOTFILE_URL | 59 | Section 3.1 |
| OPT_BOOTFILE_PARAM | 60 | Section 3.2 |
| OPTION_CLIENT_ARCH_TYPE | 61 | Section 3.3 |
| OPTION_NII | 62 | Section 3.4 |
+-------------------------+-------+--------------+
+-------------------------+-------+--------------+
| Option name | Value | Specified in |
+-------------------------+-------+--------------+
| OPT_BOOTFILE_URL | 59 | Section 3.1 |
| OPT_BOOTFILE_PARAM | 60 | Section 3.2 |
| OPTION_CLIENT_ARCH_TYPE | 61 | Section 3.3 |
| OPTION_NII | 62 | Section 3.4 |
+-------------------------+-------+--------------+
This document also introduces a new IANA registry for processor architecture types. The name of this registry is "Processor Architecture Types". Registry entries consist of a 16-bit integer recorded in decimal format and a descriptive name. The initial values of this registry can be found in [RFC4578], Section 2.1.
本文档还介绍了处理器体系结构类型的新IANA注册表。此注册表的名称为“处理器体系结构类型”。注册表项由十进制格式记录的16位整数和描述性名称组成。该注册表的初始值可在[RFC4578]第2.1节中找到。
The assignment policy for values is through Expert Review (see [RFC5226]), and any requests for values must supply the descriptive name for the processor architecture type.
值的分配策略通过专家评审（参见[RFC5226]），任何值请求都必须提供处理器体系结构类型的描述性名称。
In untrusted networks, a rogue DHCPv6 server could send the new DHCPv6 options described in this document. The booting clients could then be provided with a wrong URL so that either the boot fails or, even worse, the client boots the wrong operating system that has been provided by a malicious file server. To prevent this kind of attack, clients SHOULD use authentication of DHCPv6 messages (see Section 21 in [RFC3315]).
在不受信任的网络中，恶意DHCPv6服务器可能会发送本文档中描述的新DHCPv6选项。然后，引导客户端可能会被提供错误的URL，从而导致引导失败，或者更糟糕的是，客户端引导恶意文件服务器提供的错误操作系统。为防止此类攻击，客户端应使用DHCPv6消息的身份验证（请参阅[RFC3315]中的第21节）。
Note also that DHCPv6 messages are sent unencrypted by default. So the boot file URL options are sent unencrypted over the network, too. This can become a security risk since the URLs can contain sensitive information like user names and passwords (for example, a URL like "ftp://username:password@servername/path/file"). At the current point in time, there is no possibility to send encrypted DHCPv6 messages, so it is strongly RECOMMENDED not to use sensitive information in the URLs in untrusted networks (using passwords in URLs is deprecated anyway, according to [RFC3986]).
还请注意，默认情况下，DHCPv6消息未加密发送。因此，引导文件URL选项也在网络上以未加密的方式发送。这可能会成为一种安全风险，因为URL可能包含诸如用户名和密码之类的敏感信息（例如，URL，如“ftp://username:password@服务器名/路径/文件“）。在当前时间点，不可能发送加密的DHCPv6消息，因此强烈建议不要在不受信任的网络中的URL中使用敏感信息（根据[RFC3986]，在URL中使用密码是不推荐的）。
Even if the DHCPv6 transaction is secured, this does not protect against attacks on the boot file download channel. Consequently, we recommend that either (a) implementers use protocols like HTTPS [RFC2818] or Transport Layer Security (TLS) within HTTP [RFC2817] to prevent spoofing or (b) the boot-loader software implement a mechanism for signing boot images and a configurable signing key. The latter is done so that if a malicious image is provided, it can be detected and rejected.
即使DHCPv6事务是安全的，也不能防止启动文件下载通道上的攻击。因此，我们建议（a）实施者在HTTP[RFC2817]中使用HTTPS[RFC2818]或传输层安全性（TLS）等协议来防止欺骗，或者（b）引导加载程序软件实现对引导映像和可配置签名密钥进行签名的机制。后者是为了在提供恶意映像时能够检测并拒绝该映像。
The authors would like to thank Ruth Li, Dong Wei, Kathryn Hampton, Phil Dorah, Richard Chan, and Fiona Jensen for discussions that led to this document.
作者想感谢Ruth Li，魏东，Kathryn Hampton，Phil Dorah，Richard Chan和Fiona Jensen讨论，导致这一文件。
The authors would also like to thank Ketan P. Pancholi, Alfred Hoenes, Gabriel Montenegro, and Ted Lemon for corrections and suggestions.
作者还要感谢Ketan P.Pancholi、Alfred Hoenes、Gabriel Montegon和Ted Lemon的纠正和建议。
[PXE21] Johnston, M., "Preboot Execution Environment (PXE) Specification", September 1999, <http://www.pix.net/software/pxeboot/archive/pxespec.pdf>.
[PXE21]Johnston，M.，“预引导执行环境（PXE）规范”，1999年9月<http://www.pix.net/software/pxeboot/archive/pxespec.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4173] Sarkar, P., Missimer, D., and C. Sapuntzakis, "Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol", RFC 4173, September 2005.
[RFC4173]Sarkar，P.，Missimer，D.，和C.Sapuntzakis，“使用互联网小型计算机系统接口（iSCSI）协议引导客户端”，RFC 41732005年9月。
[RFC4578] Johnston, M. and S. Venaas, "Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE)", RFC 4578, November 2006.
[RFC4578]Johnston，M.和S.Venaas，“英特尔预引导执行环境（PXE）的动态主机配置协议（DHCP）选项”，RFC 4578，2006年11月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[UEFI23] UEFI Forum, "Unified Extensible Firmware Interface Specification, Version 2.3", May 2009, <http://www.uefi.org/>.
[UEFI23]UEFI论坛，“统一可扩展固件接口规范，版本2.3”，2009年5月<http://www.uefi.org/>.
[RFC906] Finlayson, R., "Bootstrap Loading using TFTP", RFC 906, June 1984.
[RFC906]Finlayson，R.，“使用TFTP引导加载”，RFC906，1984年6月。
[RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, July 1992.
[RFC1350]Sollins，K.，“TFTP协议（修订版2）”，STD 33，RFC 1350，1992年7月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
[RFC2817]Khare，R.和S.Lawrence，“在HTTP/1.1中升级到TLS”，RFC 28172000年5月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC3617] Lear, E., "Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP)", RFC 3617, October 2003.
[RFC3617]李尔，E.“普通文件传输协议（TFTP）的统一资源标识符（URI）方案和适用性声明”，RFC3617，2003年10月。
Authors' Addresses
作者地址
Thomas H. Huth IBM Germany Research & Development GmbH Schoenaicher Strasse 220 Boeblingen 71032 Germany
Thomas H.Huth IBM德国研发有限公司Schoenaicher Strasse 220 Boeblingen 71032德国
Phone: +49-7031-16-2183
EMail: thuth@de.ibm.com
Phone: +49-7031-16-2183
EMail: thuth@de.ibm.com
Jens T. Freimann IBM Germany Research & Development GmbH Schoenaicher Strasse 220 Boeblingen 71032 Germany
Jens T.Freimann IBM德国研发有限公司Schoenaicher Strasse 220 Boeblingen 71032德国
Phone: +49-7031-16-1122
EMail: jfrei@de.ibm.com
Phone: +49-7031-16-1122
EMail: jfrei@de.ibm.com
Vincent Zimmer Intel 2800 Center Drive DuPont WA 98327 USA
Vincent Zimmer英特尔2800中心驱动美国华盛顿州杜邦98327
Phone: +1 253 371 5667
EMail: vincent.zimmer@intel.com
Phone: +1 253 371 5667
EMail: vincent.zimmer@intel.com
Dave Thaler Microsoft One Microsoft Way Redmond WA 98052 USA
Dave Thaler微软单向雷蒙德华盛顿98052美国
Phone: +1 425 703-8835
EMail: dthaler@microsoft.com
Phone: +1 425 703-8835
EMail: dthaler@microsoft.com