Network Working Group T. Lemon
Request for Comments: 4361 Nominum
Updates: 2131, 2132, 3315 B. Sommerfield
Category: Standards Track Sun Microsystems
February 2006
Network Working Group T. Lemon
Request for Comments: 4361 Nominum
Updates: 2131, 2132, 3315 B. Sommerfield
Category: Standards Track Sun Microsystems
February 2006
Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)
动态主机配置协议版本4（DHCPv4）的特定于节点的客户端标识符
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document specifies the format that is to be used for encoding Dynamic Host Configuration Protocol Version Four (DHCPv4) client identifiers, so that those identifiers will be interchangeable with identifiers used in the DHCPv6 protocol. This document also addresses and corrects some problems in RFC 2131 and RFC 2132 with respect to the handling of DHCP client identifiers.
本文档指定了用于编码动态主机配置协议第四版（DHCPv4）客户端标识符的格式，以便这些标识符可以与DHCPv6协议中使用的标识符互换。本文档还解决并纠正了RFC 2131和RFC 2132中有关DHCP客户端标识符处理的一些问题。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Applicability ...................................................2
4. Problem Statement ...............................................3
4.1. Client identities are ephemeral. ...........................3
4.2. Clients can accidentally present multiple identities. ......3
4.3. RFC 2131/2132 and RFC 3315 identifiers are incompatible. ...4
4.4. RFC 2131 does not require the use of a client identifier. ..4
5. Requirements ....................................................4
6. Implementation ..................................................6
6.1. DHCPv4 Client Behavior .....................................6
6.2. DHCPv6 Client Behavior .....................................7
6.3. DHCPv4 Server Behavior .....................................7
6.4. Changes from RFC 2131 ......................................8
6.5. Changes from RFC 2132 ......................................9
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Applicability ...................................................2
4. Problem Statement ...............................................3
4.1. Client identities are ephemeral. ...........................3
4.2. Clients can accidentally present multiple identities. ......3
4.3. RFC 2131/2132 and RFC 3315 identifiers are incompatible. ...4
4.4. RFC 2131 does not require the use of a client identifier. ..4
5. Requirements ....................................................4
6. Implementation ..................................................6
6.1. DHCPv4 Client Behavior .....................................6
6.2. DHCPv6 Client Behavior .....................................7
6.3. DHCPv4 Server Behavior .....................................7
6.4. Changes from RFC 2131 ......................................8
6.5. Changes from RFC 2132 ......................................9
7. Notes on DHCP Clients in Multi-stage Network Booting ............9
8. Security Considerations ........................................10
9. References .....................................................10
9.1. Normative References ......................................10
9.2. Informative References ....................................10
7. Notes on DHCP Clients in Multi-stage Network Booting ............9
8. Security Considerations ........................................10
9. References .....................................................10
9.1. Normative References ......................................10
9.2. Informative References ....................................10
This document specifies the way in which Dynamic Host Configuration Protocol Version 4 [RFC2131] clients should identify themselves. DHCPv4 client implementations that conform to this specification use a DHCP Unique Identifier (DUID) as specified in Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315]. The DUID is encapsulated in a DHCPv4 client identifier option, as described in "DHCP Options and BOOTP Vendor Extensions" [RFC2132]. The behaviour described here supersedes the behavior specified in RFC2131 and RFC2132.
本文档规定了动态主机配置协议版本4[RFC2131]客户端识别自身的方式。符合此规范的DHCPv4客户端实现使用IPv6动态主机配置协议（DHCPv6）[RFC3315]中指定的DHCP唯一标识符（DUID）。DUID封装在DHCPv4客户机标识符选项中，如“DHCP选项和BOOTP供应商扩展”[RFC2132]中所述。此处描述的行为取代RFC2131和RFC2132中指定的行为。
The reason for making this change is that as we make the transition from IPv4 to IPv6, there will be network devices that must use both DHCPv4 and DHCPv6. Users of these devices will have a smoother network experience if the devices identify themselves consistently, regardless of the version of DHCP they are using at any given moment. Most obviously, DNS updates made by the DHCP server on behalf of the client will be handled more correctly. This change also addresses certain limitations in the functioning of RFC 2131/2132-style DHCP client identifiers.
做出此更改的原因是，当我们从IPv4过渡到IPv6时，将有一些网络设备必须同时使用DHCPv4和DHCPv6。如果这些设备一致地标识自己，那么这些设备的用户将拥有更流畅的网络体验，而不管他们在任何给定时刻使用的DHCP版本如何。最明显的是，DHCP服务器代表客户端进行的DNS更新将得到更正确的处理。此更改还解决了RFC 2131/2132样式DHCP客户端标识符功能中的某些限制。
This document first describes the problem to be solved. It then states the new technique that is to be used to solve the problem. Finally, it describes the specific changes that one would have to make to RFC 2131 and RFC 2132 in order for those documents not to contradict what is described in this document.
本文档首先描述了要解决的问题。然后陈述了用于解决该问题的新技术。最后，它描述了必须对RFC 2131和RFC 2132进行的具体更改，以便这些文档不会与本文档中描述的内容相矛盾。
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]中所述进行解释。
This document updates RFC 2131 and RFC 2132. This document also specifies behavior that is required of DHCPv4 and DHCPv6 clients that are intended to operate in a dual-stack configuration. Finally, this document recommends behavior for host configurations where more than one DHCP client must operate in sequence in order to fully configure
本文档更新了RFC 2131和RFC 2132。本文档还指定了打算在双堆栈配置中运行的DHCPv4和DHCPv6客户端所需的行为。最后，本文档建议主机配置的行为，其中必须按顺序操作多个DHCP客户端才能完全配置
the client (e.g., a network boot loader and the operating system it loads).
客户端（例如，网络引导加载程序及其加载的操作系统）。
DHCPv4 clients and servers that are implemented according to this document should be implemented as if the changes specified in sections 6.3 and 6.4 have been made to RFC 2131 and RFC 2132. DHCPv4 clients should, in addition, follow the behavior specified in section 6.1. DHCPv6 clients should follow the behavior specified in section 6.2. DHCPv4 servers should additionally follow the behavior specified in section 6.3.
根据本文件实施的DHCPv4客户端和服务器应按照第6.3节和第6.4节中规定的变更对RFC 2131和RFC 2132进行实施。此外，DHCPv4客户端应遵循第6.1节中规定的行为。DHCPv6客户端应遵循第6.2节中指定的行为。DHCPv4服务器还应遵循第6.3节中规定的行为。
4.1. Client identities are ephemeral.
4.1. 客户身份是短暂的。
RFC 2132 recommends that client identifiers be generated by using the permanent link-layer address of the network interface that the client is trying to configure. One result of this recommendation is that when the network interface hardware on a client computer is replaced, the identity of the client changes. The client loses its IP address and any other resources associated with its old identifier (for example, its domain name as published through the DHCPv4 server).
RFC 2132建议通过使用客户端尝试配置的网络接口的永久链路层地址来生成客户端标识符。此建议的一个结果是，当更换客户端计算机上的网络接口硬件时，客户端的标识会发生变化。客户端将丢失其IP地址以及与其旧标识符（例如，通过DHCPv4服务器发布的域名）关联的任何其他资源。
4.2. Clients can accidentally present multiple identities.
4.2. 客户端可能会意外地显示多个标识。
Consider a DHCPv4 client that has two network interfaces, one of which is wired and one of which is wireless. The DHCPv4 client will succeed in configuring either zero, one, or two network interfaces. Under the current specification, each network interface will receive a different IP address. The DHCPv4 server will treat each network interface as a completely independent DHCPv4 client, on a completely independent host.
考虑一个DHCPv4客户端，它有两个网络接口，其中一个是有线的，其中一个是无线的。DHCPv4客户端将成功配置零、一或两个网络接口。根据当前规范，每个网络接口将接收不同的IP地址。DHCPv4服务器将在完全独立的主机上将每个网络接口视为完全独立的DHCPv4客户端。
Thus, when the client presents some information to be updated in a network directory service, such as the DNS, the name that is presented will be the same on both interfaces, but the identity that is presented will be different. What will happen is that one of the two interfaces will get the name, and will retain that name as long as it has a valid lease, even if it loses its connection to the network, while the other network interface will never get the name. In some cases, this will achieve the desired result; when only one network interface is connected, sometimes its IP address will be published. In some cases, the one connected interface's IP address will not be the one that is published. When there are two interfaces, sometimes the correct one will be published, and sometimes not.
因此，当客户机在网络目录服务（如DNS）中提供一些要更新的信息时，所提供的名称在两个接口上都是相同的，但所提供的标识将不同。将发生的情况是，两个接口中的一个将获得该名称，并且只要它具有有效租约，即使它失去与网络的连接，也将保留该名称，而另一个网络接口将永远不会获得该名称。在某些情况下，这将达到预期的结果；当只连接一个网络接口时，有时会发布其IP地址。在某些情况下，已连接接口的IP地址将不是已发布的IP地址。当有两个接口时，有时会发布正确的接口，有时则不会。
This is likely to be a particular problem with modern laptops, which usually have built-in wireless ethernet and wired ethernet. When the user is near a wired outlet, he or she may want the additional speed and privacy provided by a wired connection, but that same user may unplug from the wired network and wander around, still connected to the wireless network. When a transition like this happens, under the current scheme, if the address of the wired interface is the one that gets published, this client will be seen by hosts attempting to connect to it as if it has intermittent connectivity, even though it actually has continuous network connectivity through the wireless port.
这可能是现代笔记本电脑的一个特殊问题，它们通常内置无线以太网和有线以太网。当用户靠近有线插座时，他或她可能希望通过有线连接提供额外的速度和隐私，但同一用户可能会从有线网络拔下插头，四处走动，仍然连接到无线网络。在当前方案下，当发生这样的转换时，如果有线接口的地址是发布的地址，则尝试连接到该客户端的主机将看到该客户端，就好像它具有间歇性连接一样，即使它实际上通过无线端口具有连续的网络连接。
Another common case of a duplicate identity being presented occurs when a boot monitor such as a Pre-Boot Execution Environment (PXE) loader specifies one DHCP client identifier, and then the operating system loaded by the boot loader specifies a different identity.
当引导监视器（如预引导执行环境（PXE）加载程序）指定一个DHCP客户端标识符，然后引导加载程序加载的操作系统指定另一个标识时，出现重复标识的另一种常见情况。
4.3. RFC 2131/2132 and RFC 3315 identifiers are incompatible.
4.3. RFC 2131/2132和RFC 3315标识符不兼容。
The 'client identifier' option is used by DHCPv4 clients and servers to identify clients. In some cases, the value of the 'client identifier' option is used to mediate access to resources (for example, the client's domain name, as published through the DHCPv4 server). RFC 2132 and RFC 3315 specify different methods for deriving client identifiers. These methods guarantee that the DHCPv4 and DHCPv6 identifiers will be different. This means that mediation of access to resources using these identifiers will not work correctly in cases where a node may be configured using DHCPv4 in some cases and DHCPv6 in other cases.
DHCPv4客户端和服务器使用“客户端标识符”选项来标识客户端。在某些情况下，“客户端标识符”选项的值用于调解对资源的访问（例如，通过DHCPv4服务器发布的客户端域名）。RFC 2132和RFC 3315指定用于派生客户端标识符的不同方法。这些方法保证DHCPv4和DHCPv6标识符将不同。这意味着在某些情况下使用DHCPv4配置节点，而在其他情况下使用DHCPv6配置节点的情况下，使用这些标识符访问资源的中介将无法正常工作。
4.4. RFC 2131 does not require the use of a client identifier.
4.4. RFC 2131不需要使用客户端标识符。
RFC 2131 allows the DHCPv4 server to identify clients either by using the client identifier option sent by the client or, if the client did not send one, the client's link-layer address. Like the client identifier format recommended by RFC 2131, this suffers from the problems previously described in sections 4.2 and 4.3.
RFC 2131允许DHCPv4服务器通过使用客户机发送的客户机标识符选项或（如果客户机未发送）客户机的链路层地址来识别客户机。与RFC 2131推荐的客户机标识符格式一样，该格式也存在前面第4.2节和第4.3节所述的问题。
In order to address the problems stated in section 4, DHCPv4 client identifiers must have the following characteristics:
为了解决第4节中所述的问题，DHCPv4客户端标识符必须具有以下特征：
- They must be persistent, in the sense that a particular host's client identifier must not change simply because a piece of network hardware is added or removed.
- 它们必须是持久性的，也就是说，特定主机的客户端标识符不能仅仅因为添加或删除了网络硬件而更改。
- It must be possible for the client to represent itself as having more than one network identity, for example, so that a client with two network interfaces can express to the DHCPv4 server that these two network interfaces are to receive different IP addresses, even if they happen to be connected to the same link.
- 例如，客户端必须能够将自己表示为具有多个网络标识，以便具有两个网络接口的客户端可以向DHCPv4服务器表示这两个网络接口将接收不同的IP地址，即使它们恰好连接到同一链路。
- In cases where the DHCPv4 client is expressing more than one network identity at the same time, it must nevertheless be possible for the DHCPv4 server to determine that the two network identities belong to the same host.
- 在DHCPv4客户端同时表示多个网络标识的情况下，DHCPv4服务器必须能够确定这两个网络标识属于同一主机。
- In some cases it may be desirable for a DHCP client to present the same identity on two interfaces, so that if they both happen to be connected to the same network, they will both receive the same IP address. In such cases, it must be possible for the client to use exactly the same identifier for each interface.
- 在某些情况下，DHCP客户端可能希望在两个接口上显示相同的标识，这样，如果它们碰巧都连接到同一网络，它们都将接收相同的IP地址。在这种情况下，客户端必须能够为每个接口使用完全相同的标识符。
- DHCPv4 servers that do not conform to this specification, but that are compliant with the older client identifier specification, must correctly handle client identifiers sent by clients that conform to this specification.
- 不符合此规范但符合旧客户端标识符规范的DHCPv4服务器必须正确处理符合此规范的客户端发送的客户端标识符。
- DHCPv4 servers that do conform to this specification must interoperate correctly with DHCPv4 clients that do not conform to this specification, except that when configuring such clients, behaviors such as those described in section 2 may occur.
- 符合本规范的DHCPv4服务器必须与不符合本规范的DHCPv4客户端正确互操作，但在配置此类客户端时，可能会出现第2节所述的行为。
- The use by DHCPv4 clients of the chaddr field of the DHCPv4 packet as an identifier must be deprecated.
- DHCPv4客户端使用DHCPv4数据包的chaddr字段作为标识符的做法必须予以反对。
- DHCPv4 client identifiers used by dual-stack hosts that also use DHCPv6 must use the same host identification string for both DHCPv4 and DHCPv6. For example, a DHCPv4 server that uses the client's identity to update the DNS on behalf of a DHCPv4 client must register the same client identity in the DNS that would be registered by the DHCPv6 server on behalf of the DHCPv6 client running on that host, and vice versa.
- 同时使用DHCPv6的双堆栈主机使用的DHCPv4客户端标识符必须对DHCPv4和DHCPv6使用相同的主机标识字符串。例如，使用客户端标识代表DHCPv4客户端更新DNS的DHCPv4服务器必须在DNS中注册与DHCPv6服务器代表该主机上运行的DHCPv6客户端注册的相同的客户端标识，反之亦然。
In order to satisfy all but the last of these requirements, we need to construct a DHCPv4 client identifier out of two parts. One part must be unique to the host on which the client is running. The other must be unique to the network identity being presented. The DHCP Unique Identifier (DUID) and Identity Association Identifier (IAID) specified in RFC 3315 satisfy these requirements.
为了满足除最后一个需求之外的所有需求，我们需要用两部分构造一个DHCPv4客户机标识符。一个部分必须是运行客户端的主机的唯一部分。另一个必须是呈现的网络标识所特有的。RFC 3315中指定的DHCP唯一标识符（DUID）和身份关联标识符（IAID）满足这些要求。
In order to satisfy the last requirement, we must use the DUID to identify the DHCPv4 client. So, taking all the requirements together, the DUID and IAID described in RFC 3315 are the only possible solution.
为了满足最后一个要求，我们必须使用DUID来标识DHCPv4客户机。因此，综合所有需求，RFC 3315中描述的DUID和IAID是唯一可能的解决方案。
By following these rules, a compliant DHCPv4 client will interoperate correctly with both compliant and non-compliant DHCPv4 servers. A non-compliant DHCPv4 client will also interoperate correctly with a compliant DHCPv4 server. If either server or client is not compliant, the goals stated in the document are not met, but there is no loss of functionality.
通过遵循这些规则，兼容的DHCPv4客户端将与兼容和不兼容的DHCPv4服务器进行正确的互操作。不兼容的DHCPv4客户端也将与兼容的DHCPv4服务器正确互操作。如果服务器或客户端不兼容，则文档中所述的目标无法实现，但不会丢失功能。
Here we specify changes to the behavior of DHCPv4 clients and servers. We also specify changes to the wording in RFC 2131 and RFC 2132. DHCPv4 clients, servers, and relay agents that conform to this specification must implement RFC 2131 and RFC 2132 with the wording changes specified in sections 6.3 and 6.4.
这里我们指定对DHCPv4客户端和服务器行为的更改。我们还指定了对RFC 2131和RFC 2132中措辞的更改。符合本规范的DHCPv4客户端、服务器和中继代理必须实施RFC 2131和RFC 2132，并在第6.3节和第6.4节规定的措辞更改。
DHCPv4 clients conforming to this specification MUST use stable DHCPv4 node identifiers in the dhcp-client-identifier option. DHCPv4 clients MUST NOT use client identifiers based solely on layer two addresses that are hard-wired to the layer two device (e.g., the ethernet MAC address) as suggested in RFC 2131, except as allowed in section 9.2 of RFC 3315. DHCPv4 clients MUST send a 'client identifier' option containing an Identity Association Unique Identifier, as defined in section 10 of RFC 3315, and a DHCP Unique Identifier, as defined in section 9 of RFC 3315. These together constitute an RFC 3315-style binding identifier.
符合此规范的DHCPv4客户端必须在dhcp客户端标识符选项中使用稳定的DHCPv4节点标识符。除非RFC 3315第9.2节允许，否则DHCPv4客户端不得使用仅基于硬连接至第二层设备的第二层地址（例如以太网MAC地址）的客户端标识符，如RFC 2131中所建议。DHCPv4客户端必须发送“客户端标识符”选项，该选项包含RFC 3315第10节中定义的身份关联唯一标识符和RFC 3315第9节中定义的DHCP唯一标识符。这些共同构成RFC315样式绑定标识符。
The general format of the DHCPv4 'client identifier' option is defined in section 9.14 of RFC 2132.
RFC 2132第9.14节定义了DHCPv4“客户标识符”选项的一般格式。
To send an RFC 3315-style binding identifier in a DHCPv4 'client identifier' option, the type of the 'client identifier' option is set to 255. The type field is immediately followed by the IAID, which is an opaque 32-bit quantity. The IAID is immediately followed by the DUID, which consumes the remaining contents of the 'client identifier' option. The format of the 'client identifier' option is as follows:
要在DHCPv4“客户端标识符”选项中发送RFC 3315样式的绑定标识符，“客户端标识符”选项的类型设置为255。type字段后面紧跟着IAID，它是一个不透明的32位量。IAID后面紧跟DUID，DUID使用“客户端标识符”选项的剩余内容。“客户端标识符”选项的格式如下所示：
Code Len Type IAID DUID
+----+----+-----+----+----+----+----+----+----+---
| 61 | n | 255 | i1 | i2 | i3 | i4 | d1 | d2 |...
+----+----+-----+----+----+----+----+----+----+---
Code Len Type IAID DUID
+----+----+-----+----+----+----+----+----+----+---
| 61 | n | 255 | i1 | i2 | i3 | i4 | d1 | d2 |...
+----+----+-----+----+----+----+----+----+----+---
Any DHCPv4 client that conforms to this specification SHOULD provide a means by which an operator can learn what DUID the client has chosen. Such clients SHOULD also provide a means by which the operator can configure the DUID. A device that is normally configured by both a DHCPv4 and DHCPv6 client SHOULD automatically use the same DUID for DHCPv4 and DHCPv6 without any operator intervention.
符合本规范的任何DHCPv4客户机都应提供一种方法，操作员可以通过该方法了解客户机选择的DUID。此类客户机还应提供操作员配置DUID的方法。通常由DHCPv4和DHCPv6客户端配置的设备应自动为DHCPv4和DHCPv6使用相同的DUID，而无需任何操作员干预。
DHCPv4 clients that support more than one network interface SHOULD use the same DUID on every interface. DHCPv4 clients that support more than one network interface SHOULD use a different IAID on each interface.
支持多个网络接口的DHCPv4客户端应在每个接口上使用相同的DUID。支持多个网络接口的DHCPv4客户端应在每个接口上使用不同的IAID。
A DHCPv4 client that generates a DUID and that has stable storage MUST retain this DUID for use in subsequent DHCPv4 messages, even after an operating system reboot.
生成DUID并具有稳定存储的DHCPv4客户端必须保留此DUID，以便在后续DHCPv4消息中使用，即使在操作系统重新启动后也是如此。
Any DHCPv6 client that conforms to this specification SHOULD provide a means by which an operator can learn what DUID the client has chosen. Such clients SHOULD also provide a means by which the operator can configure the DUID. A device that is normally configured by both a DHCPv4 and DHCPv6 client SHOULD automatically use the same DUID for DHCPv4 and DHCPv6 without any operator intervention.
符合本规范的任何DHCPv6客户机都应提供一种方法，操作员可以通过该方法了解客户机选择的DUID。此类客户机还应提供操作员配置DUID的方法。通常由DHCPv4和DHCPv6客户端配置的设备应自动为DHCPv4和DHCPv6使用相同的DUID，而无需任何操作员干预。
This document does not require any change to DHCPv4 or DHCPv6 servers that follow RFC 2131 and RFC 2132. However, some DHCPv4 servers can be configured not to conform to RFC 2131 and RFC 2132, in the sense that they ignore the 'client identifier' option and use the client's hardware address instead.
本文档不要求对遵循RFC 2131和RFC 2132的DHCPv4或DHCPv6服务器进行任何更改。但是，一些DHCPv4服务器可以配置为不符合RFC 2131和RFC 2132，因为它们忽略了“客户机标识符”选项，而是使用客户机的硬件地址。
DHCPv4 servers that conform to this specification MUST use the 'client identifier' option to identify the client if the client sends it.
符合此规范的DHCPv4服务器必须使用“客户端标识符”选项来标识客户端（如果客户端发送）。
DHCPv4 servers MAY use administrator-supplied values for chaddr and htype to identify the client in the case where the administrator is assigning a fixed IP address to the client, even if the client sends a client identifier option. This is ONLY permitted in the case where the DHCPv4 server administrator has provided the values for chaddr and htype, because in this case if it causes a problem, the administrator can correct the problem by removing the offending configuration information.
在管理员向客户端分配固定IP地址的情况下，DHCPv4服务器可能会使用管理员为chaddr和htype提供的值来标识客户端，即使客户端发送了客户端标识符选项。只有在DHCPv4服务器管理员提供了chaddr和htype的值的情况下才允许这样做，因为在这种情况下，如果它导致问题，管理员可以通过删除有问题的配置信息来纠正问题。
In section 2 of RFC 2131, on page 9, the text that reads "; for example, the 'client identifier' may contain a hardware address, identical to the contents of the 'chaddr' field, or it may contain another type of identifier, such as a DNS name" is deleted.
在RFC 2131第2节第9页上，删除“例如，‘客户端标识符’可能包含与‘chaddr’字段内容相同的硬件地址，或者可能包含另一种类型的标识符，如DNS名称”的文本。
In section 4.2 of RFC 2131, the text "The client MAY choose to explicitly provide the identifier through the 'client identifier' option. If the client supplies a 'client identifier', the client MUST use the same 'client identifier' in all subsequent messages, and the server MUST use that identifier to identify the client. If the client does not provide a 'client identifier' option, the server MUST use the contents of the 'chaddr' field to identify the client." is replaced by the text "The client MUST explicitly provide a client identifier through the 'client identifier' option. The client MUST use the same 'client identifier' option for all messages."
在RFC 2131第4.2节中“客户端可以选择通过“客户端标识符”选项显式提供标识符。如果客户端提供“客户端标识符”，则客户端必须在所有后续消息中使用相同的“客户端标识符”，服务器必须使用该标识符来标识客户端。如果客户端未提供“客户端标识符”选项，则服务器必须使用“chaddr”字段的内容来标识客户端。“替换为文本”客户端必须通过“客户端标识符”选项显式提供客户端标识符。客户端必须对所有消息使用相同的“客户端标识符”选项。”
In the same section, the text "Use of 'chaddr' as the client's unique identifier may cause unexpected results, as that identifier may be associated with a hardware interface that could be moved to a new client. Some sites may choose to use a manufacturer's serial number as the 'client identifier', to avoid unexpected changes in a client's network address due to transfer of hardware interfaces among computers. Sites may also choose to use a DNS name as the 'client identifier', causing address leases to be associated with the DNS name rather than a specific hardware box." is replaced by the text "The DHCP client MUST NOT rely on the 'chaddr' field to identify it."
在同一节中，文本“使用‘chaddr’作为客户端的唯一标识符可能会导致意外结果，因为该标识符可能与可移动到新客户端的硬件接口相关联。一些站点可能会选择使用制造商的序列号作为“客户端标识符”，以避免由于计算机之间的硬件接口传输而导致客户端网络地址发生意外变化。站点也可以选择使用DNS名称作为“客户端标识符”，导致地址租约与DNS名称而不是特定的硬件框相关联。“替换为文本“DHCP客户端不得依赖“chaddr”字段来识别它。”
In section 4.4.1 of RFC 2131, the text "The client MAY include a different unique identifier" is replaced with "The client MUST include a unique identifier".
在RFC 2131第4.4.1节中，“客户可能包括不同的唯一标识符”替换为“客户必须包括唯一标识符”。
In section 3.1, items 4 and 6; section 3.2 item 3 and 4; and section 4.3.1, where RFC 2131 says that 'chaddr' may be used instead of the 'client identifier' option, the text "or 'chaddr'" and "'chaddr' or" is deleted.
第3.1节第4项和第6项；第3.2节第3项和第4项；以及第4.3.1节，其中RFC 2131规定可以使用“chaddr”代替“客户标识符”选项，删除文本“或‘chaddr’”和“‘chaddr’或”。
Note that these changes do not relieve the DHCPv4 server of the obligation to use 'chaddr' as an identifier if the client does not send a 'client identifier' option. Rather, they oblige clients that conform with this document to send a 'client identifier' option, and not rely on 'chaddr' for identification. DHCPv4 servers MUST use 'chaddr' as an identifier in cases where 'client identifier' is not sent, in order to support old clients that do not conform with this document.
请注意，如果客户端不发送“客户端标识符”选项，这些更改不会免除DHCPv4服务器使用“chaddr”作为标识符的义务。相反，它们要求符合本文档的客户发送“客户标识符”选项，而不是依赖“chaddr”进行标识。DHCPv4服务器必须在未发送“客户端标识符”的情况下使用“chaddr”作为标识符，以支持不符合本文档要求的旧客户端。
The text in section 9.14, beginning with "The client identifier MAY consist of" through "that meet this requirement for uniqueness." is replaced with "the client identifier consists of a type field whose value is normally 255, followed by a four-byte IA_ID field, followed by the DUID for the client as defined in RFC 3315, section 9." The text "its minimum length is 2" in the following paragraph is deleted.
第9.14节中的文本以“客户标识符可能包括”至“满足唯一性要求的”开头，替换为“客户标识符包括一个类型字段，其值通常为255，后跟一个四字节的IA_ID字段，后跟RFC 3315第9节中定义的客户DUID。”删除以下段落中的“其最小长度为2”。
In some cases a single device may actually run more than one DHCP client in sequence, in the process of loading an operating system over the network. In such cases, it may be that the first-stage boot uses a different client identifier, or no client identifier, than the subsequent stage or stages.
在某些情况下，在通过网络加载操作系统的过程中，单个设备可能实际按顺序运行多个DHCP客户端。在这种情况下，第一阶段引导可能使用与后续阶段不同的客户机标识符，或者没有客户机标识符。
The effect of this, under the DHCPv4 protocol, is that the two (in some cases more than two!) boot stages will present different identities. A DHCPv4 server will therefore allocate two different IP addresses to the two different boot stages.
在DHCPv4协议下，这样做的效果是两个（在某些情况下超过两个！）引导阶段将呈现不同的身份。因此，DHCPv4服务器将为两个不同的启动阶段分配两个不同的IP地址。
Some DHCP servers work around this problem for the common case where the boot Programmable Read Only Memory (PROM) presents no client identifier, and the operating system DHCP client presents a client identifier constructed from the Message Authentication Code (MAC) address of the network interface -- both are treated as the same identifier. This prevents the consumption of an extra IP address.
一些DHCP服务器针对以下常见情况解决此问题：引导可编程只读存储器（PROM）不提供客户端标识符，而操作系统DHCP客户端提供由网络接口的消息身份验证码（MAC）地址构造的客户端标识符——两者被视为相同的标识符。这可以防止消耗额外的IP地址。
A compliant DHCPv4 client does not use a client identifier constructed from the MAC address of the network interface, because network interfaces are not stable. So a compliant DHCPv4 client cannot be supported by a simple hack like the one described previously; this may have some significant impact at some sites.
兼容的DHCPv4客户端不使用根据网络接口的MAC地址构造的客户端标识符，因为网络接口不稳定。因此，一个兼容的DHCPv4客户端不能被前面描述的简单黑客所支持；这可能会对某些场地产生重大影响。
We cannot state the solution to this problem as a set of requirements, because the circumstances in which this occurs vary too widely. However, we can make some suggestions.
我们不能把这个问题的解决方案说成是一套要求，因为发生这种情况的环境差异太大。不过，我们可以提出一些建议。
First, we suggest that DHCP clients in network boot loaders request short lease times, so that their IP addresses are not retained. Such clients should send a DHCPRELEASE message to the DHCP server before moving on to the next stage of the boot process. Such clients should provide a way for the operating system DHCP client to configure a DUID to use in subsequent boots. DHCP clients in the final stage should, where possible, configure the DUID used by the boot PROM to be the same as the DUID used by the operating system.
首先，我们建议网络引导加载程序中的DHCP客户端请求较短的租用时间，以便不保留其IP地址。在进入引导过程的下一阶段之前，此类客户端应向DHCP服务器发送DHCPRELEASE消息。这样的客户端应该为操作系统DHCP客户端提供一种方式来配置DUID，以便在后续引导中使用。最后阶段的DHCP客户端应尽可能将引导PROM使用的DUID配置为与操作系统使用的DUID相同。
Second, implementors of DHCPv4 clients that are expected to only be used in a multi-stage network boot configuration, that are not expected ever to network boot using DHCPv6, and that have a MAC address that cannot be easily changed may not need to implement the changes described in this specification. There is some danger in making this assumption--the first solution suggested is definitely better. A compromise might be to have the final-stage DHCP client detect whether it is running on legacy hardware; if it is, it uses the old identifier; if it is not, it follows the scheme described in the previous paragraph.
其次，DHCPv4客户机的实现者可能不需要实现本规范中描述的更改，这些客户机预期仅在多级网络引导配置中使用，不会使用DHCPv6进行网络引导，并且具有不易更改的MAC地址。做出这样的假设有一定的危险性——提出的第一个解决方案肯定更好。一个折衷方案可能是让最终阶段的DHCP客户端检测它是否在遗留硬件上运行；如果是，则使用旧标识符；如果不是，则遵循上一段中描述的方案。
This document raises no new security issues. Potential exposure to attack in the DHCPv4 protocol is discussed in section 7 of the DHCP protocol specification [RFC2131] and in Authentication for DHCP messages [RFC3118]. Potential exposure to attack in the DHCPv6 protocol is discussed in section 23 of RFC 3315.
本文件没有提出新的安全问题。DHCP协议规范[RFC2131]第7节和DHCP消息的身份验证[RFC3118]中讨论了DHCPv4协议中可能遭受的攻击。RFC 3315第23节讨论了DHCPv6协议中可能遭受的攻击。
[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月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132]Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年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月。
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3118]Droms，R.和W.Arbaugh，“DHCP消息的身份验证”，RFC31182001年6月。
Authors' Addresses
作者地址
Ted Lemon Nominum 2385 Bay Road Redwood City, CA 94063 USA
美国加利福尼亚州红木市海湾路2385号Ted Lemon Nominum 94063
Phone: +1 650 381 6000
EMail: mellon@nominum.com
Phone: +1 650 381 6000
EMail: mellon@nominum.com
Bill Sommerfeld Sun Microsystems 1 Network Drive Burlington, MA 01824
马萨诸塞州伯灵顿市比尔·索末菲尔德太阳微系统1号网络驱动器01824
Phone: +1 781 442 3458
EMail: sommerfeld@sun.com
Phone: +1 781 442 3458
EMail: sommerfeld@sun.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。