dhcp rfc

Dynamic Host Configuration Protocol

1. Introduction

DHCP协议给因特网主机提供配置参数。DHCP由两个部分组成：将特定的主机配置参数从DHCP服务器传递到主机的协议和将网络地址分配给主机的机制。

The Dynamic Host Configuration Protocol (DHCP) provides configuration parameters to Internet hosts. DHCP consists of two components: a protocol for delivering host-specific configuration parameters from a DHCP server to a host and a mechanism for allocation of network addresses to hosts.

DHCP是建立再客户端－服务器模型上的，再这里指定的DHCP服务器主机分配网络地址并将配置参数传递给动态配置的主机。贯穿整个文档，“服务器”指通过DHCP提供初始化参数的主机，“客户端”指向DHCP服务器请求初始化参数的主机。

DHCP is built on a client-server model, where designated DHCP server hosts allocate network addresses and deliver configuration parameters to dynamically configured hosts. Throughout the remainder of this document, the term "server" refers to a host providing initialization parameters through DHCP, and the term "client" refers to a host requesting initialization parameters from a DHCP server.

除非是系统管理员的明确配置，主机不应该作为DHCP服务器。如果任意的主机都可以响应DHCP请求，那么因特网中硬件和协议实现的多样性将不能实现操作的可靠性。例如，IP要求设置许多协议实现软件中的参数。因为IP可以用在许多不同种类的网络硬件中，那些参数的值不可以被推测或者假设有正确的默认值。同样，分布式的地址分配方案轮询/答辩机制来发现那些已经在使用的地址。IP主机可能不能总是防护他们的网络地址，所以这个分布式的地址分配方案不可以保证避免相同网络地址的分配。

A host should not act as a DHCP server unless explicitly configured to do so by a system administrator. The diversity of hardware and protocol implementations in the Internet would preclude reliable operation if random hosts were allowed to respond to DHCP requests. For example, IP requires the setting of many parameters within the protocol implementation software. Because IP can be used on many dissimilar kinds of network hardware, values for those parameters cannot be guessed or assumed to have correct defaults. Also, distributed address allocation schemes depend on a polling/defense mechanism for discovery of addresses that are already in use. IP hosts may not always be able to defend their network addresses, so that such a distributed address allocation scheme cannot be guaranteed to avoid allocation of duplicate network addresses.

DHCP支持三种IP地址分配机制。“自动分配”，DHCP给客户端分配一个永久IP地址。“动态分配”

，DHCP给客户端分配一个IP地址，这个地址只能使用一段时间，（或者直到客户端放弃这个地址）。“手动分配”，客户端的IP地址由网络管理员分配，DHCP只是简单的用来将分配的地址传达给客户端。特定的网络将使用一种和多种这些机制，根据网络管理员的政策。

DHCP supports three mechanisms for IP address allocation. In "automatic allocation", DHCP assigns a permanent IP address to a client. In "dynamic allocation", DHCP assigns an IP address to a client for a limited period of time (or until the client explicitly relinquishes the address). In "manual allocation", a client’s IP address is assigned by the network administrator, and DHCP is used simply to convey the assigned address to the client. A particular network will use one or more of these mechanisms, depending on the policies of the network administrator.

动态分配是三种机制中唯一一种允许自动将曾经分配给客户端，但现在不再需要的地址重新使用的机制。因而，对于分配地址给只是暂时与网络连接的客户端，或者一组不需要永久IP地址的客户端共享一个有限的地址池时，动态分配显得特别有用。对于给要长期连接到网络上的新客户端分配IP地址，但这个网络的IP地址非常缺乏，回收老客户端已经放弃的地址是很重要的时候，动态分配可能也是一个好的选择。手动分配允许利用DHCP来消除在（不管任何原因）DHCP机制外管理IP地址的分配是理想的的情况下就IP地址手动配置的主机有错误倾向的过程

Dynamic allocation is the only one of the three mechanisms that allows automatic reuse of an address that is no longer needed by the client to which it was assigned. Thus, dynamic allocation is particularly useful for assigning an address to a client that will be connected to the network only temporarily or for sharing a limited pool of IP addresses among a group of clients that do not need permanent IP addresses. Dynamic allocation may also be a good choice for assigning an IP address to a new client being permanently connected to a network where IP addresses are sufficiently scarce that it is important to reclaim them when old clients are retired. Manual allocation allows DHCP to be used to eliminate the error-prone process of manually configuring hosts with IP addresses in environments where (for whatever reasons) it is desirable to manage IP address assignment outside of the DHCP mechanisms.

DHCP消息格式基于BOOTP消息的格式，捕捉BOOTP中继代理行为描述为BOOTP规格的一部分并且允许BOOTP客户端和DHCP服务器同时存在相互配合作用。使用BOOTP中继代理可以消除在每个物理网段都要一个DHCP服务器的必要性。

The format of DHCP messages is based on the format of BOOTP messages, to capture the BOOTP relay agent behavior described as part of the BOOTP specification [7, 21] and to allow interoperability of existing BOOTP clients with DHCP servers. Using BOOTP relay agents eliminates the necessity of having a DHCP server on each physical network segment.

1. 1. Changes to RFC 1541

1. 1. Related Work

1. 1. Problem definition and issues

1. 1. Requirements

1. 1. Terminology

1. 1. Design goals

下列的列表给出了DHCP的综合的设计目标。

The following list gives general design goals for DHCP.

1. DHCP应该是一种手段而不是一种政策。DHCP必须允许本地系统管理员控制想要的全部配置参数；例如本地系统管理员应该能够执行有关分配和进入想要的局部资源的局部政策。

o DHCP should be a mechanism rather than a policy. DHCP must allow local system administrators control over configuration parameters where desired; e.g., local system administrators should be able to enforce local policies concerning allocation and access to local resources where desired.

1. 客户端应该不要求手动的配置。每个客户端应该能够不在用户的干涉下发现合适的局部配置参数并将那些参数合并到自己的配置中。

o Clients should require no manual configuration. Each client should be able to discover appropriate local configuration parameters without user intervention and incorporate those parameters into its own configuration.

1. 网络应该不要求给单独的客户端进行手动配置。在正常环境下，网络管理员不应该输入客户端的配置参数。

o Networks should require no manual configuration for individual clients. Under normal circumstances, the network manager should not have to enter any per-client configuration parameters.

1. DHCP不应该要求每个子网有一个服务器。为经济和比例着想，DHCP必须越过路由器工作和穿过BOOTP中继代理的干涉。

o DHCP should not require a server on each subnet. To allow for scale and economy, DHCP must work across routers or through the intervention of BOOTP relay agents.

1. DHCP客户端必须对接收到一个配置参数请求的多个应答有所准备。一些安装可能包含多个重叠的DHCP服务器来加强可靠性和提高性能。

o A DHCP client must be prepared to receive multiple responses to a request for configuration parameters. Some installations may include multiple, overlapping DHCP servers to enhance reliability and increase performance.

1. DHCP必须与静态配置的，没有参与的主机和现有的网络协议实现并存。

o DHCP must coexist with statically configured, non-participating hosts and with existing network protocol implementations.

1. DHCP必须和RFC951和RFC1542中描述的BOOTP中继代理行为相互操作。

o DHCP must interoperate with the BOOTP relay agent behavior as described by RFC 951 and by RFC 1542 [21].

1. DHCP必须为现存的BOOTP客户端提供服务。

o DHCP must provide service to existing BOOTP clients.

下面的列表给出了网络层参数的传输的细节的设计目标。DHCP必须：

The following list gives design goals specific to the transmission of the network layer parameters. DHCP must:

1. 保证任何网络地址不能被一个以上的DHCP客户端同时使用，

o Guarantee that any specific network address will not be in use by more than one DHCP client at a time,

1. 在DHCP客户端重新启动的时候保留DHCP客户端的配置。不论什么时候，对于每个请求的应答，应该分配相同的配置参数（例如，网络地址）给同一个DHCP客户端。

o Retain DHCP client configuration across DHCP client reboot. A DHCP client should, whenever possible, be assigned the same configuration parameters (e.g., network address) in response to each request,

1. 在服务器重新启动的时候保留DHCP客户端配置，并且不论什么时候，尽管DHCP机制重新启动，应该分配相同的配置参数给同一个DHCP客户端。

o Retain DHCP client configuration across server reboots, and, whenever possible, a DHCP client should be assigned the same configuration parameters despite restarts of the DHCP mechanism,

1. 允许给新客户端自动分配配置参数以避免为新客户端手动配置。

o Allow automated assignment of configuration parameters to new clients to avoid hand configuration for new clients,

1. 支持给特定客户端分配固定或永久的配置参数。

o Support fixed or permanent allocation of configuration parameters to specific clients.

1. Protocol Summary

从客户端的观点看，DHCP是BOOTP的扩展。这允许现存的BOOTP客户端不需要改变任何客户端的初始化软件就可以和DHCP服务器相互操作。RFC1542详细讲述了BOOTP与DHCP的客户端和服务器之间的相互作用。在3和4节有一些优化DHCP客户端和服务器之间的相互作用的新的，可选的处理。

From the client’s point of view, DHCP is an extension of the BOOTP mechanism. This behavior allows existing BOOTP clients to interoperate with DHCP servers without requiring any change to the clients’ initialization software. RFC 1542 [2] details the interactions between BOOTP and DHCP clients and servers [9]. There are some new, optional transactions that optimize the interaction between DHCP clients and servers that are described in sections 3 and 4.

图1给出了DHCP消息的格式，表1描述了DHCP消息的每个域。圆括号里的数字表示每个域以字节为单位的大小。图中给出了域的名称将在整个文档中使用，来参照DHCP消息中的域。

Figure 1 gives the format of a DHCP message and table 1 describes each of the fields in the DHCP message. The numbers in parentheses indicate the size of each field in octets. The names for the fields given in the figure will be used throughout this document to refer to the fields in DHCP messages.

DHCP和BOOTP之间有两个主要的区别。第一，DHCP通过定义可以给客户端分配适用于一个有限租期的网络地址，允许将网络地址连续的分配给不太的客户端。第二，DHCP提供了给客户端获得所有它需要的为了操作的IP配置参数的手段。

There are two primary differences between DHCP and BOOTP. First, DHCP defines mechanisms through which clients can be assigned a network address for a finite lease, allowing for serial reassignment of network addresses to different clients. Second, DHCP provides the mechanism for a client to acquire all of the IP configuration parameters that it needs in order to operate.

DHCP引入了术语的小变化，目的是阐明一个域的含义。BOOTP中的“vendor extensions”域在DHCP中被重命名为“options”域。同样的，在BOOTP的“vendor extensions”域内部使用的带标签的项目，曾经被正式的参照为“vendor extensions”，现在被简单的命名为“options”。

DHCP introduces a small change in terminology intended to clarify the meaning of one of the fields. What was the "vendor extensions" field in BOOTP has been re-named the "options" field in DHCP. Similarly, the tagged data items that were used inside the BOOTP "vendor extensions" field, which were formerly referred to as "vendor extensions," are now termed simply "options."

Figure 1: Format of a DHCP message

DHCP定义了一个新的“client identifier”选项，用来将客户端的标识符清楚的传给DHCP服务器。这个改变消除了BOOTP消息的“chaddr”域的过载，在那里“chaddr”即用来作为BOOTP应答消息传输的硬件地址，用作为客户端标识符。“client identifier”是一把不透明的钥匙，不被服务器解释；例如，“client identifier”可能包含和“chaddr”域的内容一样的硬件地址，或可能包含其它类型的标识符，比如说DNS名字。DHCP客户端选择的“client identifier”必须在客户端连接的子网内是唯一的。如果客户端在一个消息中使用了“client identifier”，它必须在所有后继消息中使用相同的标识符，以确保所有的服务器正确的识别这个客户端。

DHCP defines a new ’client identifier’ option that is used to pass an explicit client identifier to a DHCP server. This change eliminates the overloading of the ’chaddr’ field in BOOTP messages, where ’chaddr’ is used both as a hardware address for transmission of BOOTP reply messages and as a client identifier. The ’client identifier’ is an opaque key, not to be interpreted by the server; 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. The ’client identifier’ chosen by a DHCP client MUST be unique to that client within the subnet to which the client is attached. If the client uses a ’client identifier’ in one message, it MUST use that same identifier in all subsequent messages, to ensure that all servers correctly identify the client.

DHCP阐明“siaddr”域的解释是用在客户端的引导过程的下一步的服务器的地址。如果服务器准备提供下一个引导服务（例如，一个操作系统的可执行的映像的传递），DHCP可能在“siaddr”域中返回它自己的地址。DHCP服务器总是在“server identifier”选项中返回它自己的地址。

DHCP clarifies the interpretation of the ’siaddr’ field as the address of the server to use in the next step of the client’s bootstrap process. A DHCP server may return its own address in the ’siaddr’ field, if the server is prepared to supply the next bootstrap service (e.g., delivery of an operating system executable image). A DHCP server always returns its own address in the ’server identifier’ option.

FIELD OCTETS  DESCRIPTION

----- ------  -----------

op 1    Message op code / message type.

1 = BOOTREQUEST, 2 = BOOTREPLY

消息操作码/消息类型

htype           1    Hardware address type, see ARP section in "Assigned Numbers" RFC; e.g., ’1’ = 10mb ethernet.

                      硬件地址类型，

hlen 1  Hardware address length (e.g. ’6’ for 10mb ethernet).

                      硬件地址长度

hops            1    Client sets to zero, optionally used by relay agents when booting via a relay agent.

                      客户端设为0，当通过中继代理引导时由中继代理选择使用

xid             4    Transaction ID, a random number chosen by the client, used by the client and server to associate messages and responses between a client and a server.

处理ID，客户端选择的随机数字，客户端和服务器用来将客户端和服务器之间的消息和应答联系起来。

secs            2    Filled in by client, seconds elapsed since client began address acquisition or renewal process. flags 2 Flags (see figure 2).

由客户端填写，自从客户端开始地址获取和续租过程开始已经过去的以秒为单位的时间。

ciaddr          4    Client IP address; only filled in if client is in BOUND, RENEW or REBINDING state and can respond to ARP requests.

客户端IP地址，只在客户端是在BOUND,RENEW或REBINDING状态下被填写，并且可以响应ARP请求。

yiaddr          4   ’your’ (client) IP address.

 “你的”（客户端）IP地址

siaddr          4    IP address of next server to use in bootstrap; returned in DHCPOFFER, DHCPACK by server.

用在引导的下一个服务器的IP地址；由服务器在DHCPOFFER,DHCPACK中返回。

giaddr          4    Relay agent IP address, used in booting via a relay agent.

  中继代理的IP地址，用在通过中继代理引导的时候

chaddr         16    Client hardware address.

  客户端硬件地址

sname          64    Optional server host name, null terminated string.

  可选的服务器主机名，

file          128    Boot file name, null terminated string; "generic" name or null in DHCPDISCOVER, fully qualified directory-path name in DHCPOFFER.

引导文件名；在DHCPDISCOVER中是“普通的”名字或空值，在DHCPOFFER中是完整有效的目录路径名

options      var    Optional parameters field. See the options documents for a list of defined options.

可选的参数域。

Table 1: Description of fields in a DHCP message

现在“options”域的长度是可变的。DHCP客户端必须准备接收“options”域的长度至少是312字节的DHCP消息。这个需求意味着DHCP客户端必须准备接收相当于576字节的消息，IP主机必须准备接收的最小的IP报文大小。DHCP客户端可能通过“maximum DHCPmessage size”选项协商使用更大的DHCP消息。选项域可能进一步扩展到“file”和“sname”域。

The ’options’ field is now variable length. A DHCP client must be prepared to receive DHCP messages with an ’options’ field of at least length 312 octets. This requirement implies that a DHCP client must be prepared to receive a message of up to 576 octets, the minimum IP datagram size an IP host must be prepared to accept [3]. DHCP clients may negotiate the use of larger DHCP messages through the ’maximum DHCP message size’ option. The options field may be further extended into the ’file’ and ’sname’ fields.

在客户端使用DHCP做初始化配置的情况下（在客户端的TCP/IP软件被完全配置之前），DHCP要求客户端的TCP/IP软件创造性的使用和RFC1122的自由阐释。在IP地址被配置之前TCP/IP软件应该接收和转发任何传递到客户端的硬件地址的IP包到IP层；DHCP服务器和BOOTP中继代理可能不能够传递DHCP消息给在TCP/IP软件被配置之前不能接收硬件单播报文的客户端。

In the case of a client using DHCP for initial configuration (before the client’s TCP/IP software has been completely configured), DHCP requires creative use of the client’s TCP/IP software and liberal interpretation of RFC 1122. The TCP/IP software SHOULD accept and forward to the IP layer any IP packets delivered to the client’s hardware address before the IP address is configured; DHCP servers and BOOTP relay agents may not be able to deliver DHCP messages to clients that cannot accept hardware unicast datagrams before the TCP/IP software is configured.

为了绕过一些前一段讨论的在TCP/IP软件被配置之前不能接收IP单播报文的客户端，DHCP使用“flags”域。最左边的位被定义位广播标识。这个标识的语义在这个文档的4.1节讨论。标识域的剩余位被保留在将来使用。他们必须被客户端设置位0，并且被服务器和中继代理忽略。图2给出了“flags”域的格式。

To work around some clients that cannot accept IP unicast datagrams before the TCP/IP software is configured as discussed in the previous paragraph, DHCP uses the ’flags’ field [21]. The leftmost bit is defined as the BROADCAST (B) flag. The semantics of this flag are discussed in section 4.1 of this document. The remaining bits of the flags field are reserved for future use. They MUST be set to zero by clients and ignored by servers and relay agents. Figure 2 gives the format of the ’flags’ field.

Figure 3: Timeline diagram of messages exchanged between DHCP

client and servers when allocating a new network address

1. 客户端接收到一个或多个服务器发来的一个或多个DHCPOFFER消息。客户端可以选择等待多个应答。客户端从中选择一个服务器来请求配置参数，基于DHCPOFFER消息提供的配置参数。客户端广播DHCPREQUEST消息，这个消息必须包括“server identifier”选项，指明它已经选择的服务器，它还可以包含其它选项，指定想要的配置值。“requested IP address”选项必须设置成服务器的DHCPOFFER消息中的“yiaddr”域中的值。这个DHCPREQUEST消息被广播和通过DHCP/BOOTP中继代理被中继。为了帮助确保任何BOOTP中继代理把DHCPREQUEST消息转发到那些接收到最初的DHCPDISCOVER消息的DHCP服务器上，DHCPREQUEST消息必须在DHCP消息头的“secs”域中使用相同的值并被发送到和最初的DHCPDISCOVER消息相同的IP广播地址。如果没有接收到DHCPOFFER消息，客户端将超时并重传DHCPDISCOVER消息。

3. The client receives one or more DHCPOFFER messages from one or more servers. The client may choose to wait for multiple responses. The client chooses one server from which to request configuration parameters, based on the configuration parameters offered in the DHCPOFFER messages. The client broadcasts a DHCPREQUEST message that MUST include the ’server identifier’ option to indicate which server it has selected, and that MAY include other options specifying desired configuration values. The ’requested IP address’ option MUST be set to the value of ’yiaddr’ in the DHCPOFFER message from the server. This DHCPREQUEST message is broadcast and relayed through DHCP/BOOTP relay agents. To help ensure that any BOOTP relay agents forward the DHCPREQUEST message to the same set of DHCP servers that received the original DHCPDISCOVER message, the DHCPREQUEST message MUST use the same value in the DHCP message header’s ’secs’ field and be sent to the same IP broadcast address as the original DHCPDISCOVER message. The client times out and retransmits the DHCPDISCOVER message if the client receives no DHCPOFFER messages.

1. 服务器接收到客户端的DHCPREQUEST广播。那些没有被DHCPREQUEST消息选中的服务器把这条消息作为客户端拒绝了那个服务器的提供的通知。那个被DHCPREQUEST消息选中的服务器把客户端绑定到永久存储中，并应答一个包含请求客户端的配置参数的DHCPACK消息。“client identifier”或“chaddr”和分配的网络地址组成了客户端的租期唯一的标识符，并被客户端和服务器使用来识别任何DHCP消息中参照的租约。任何DHCPACK消息中的配置参数不应该和那些较早前给客户端响应的DHCPOFFER消息冲突。服务器不应该在这个时候检查提供的网络地址。DHCPACK消息中的“yiaddr”域被填上选择的网络地址。

4. The servers receive the DHCPREQUEST broadcast from the client. Those servers not selected by the DHCPREQUEST message use the message as notification that the client has declined that server’s offer. The server selected in the DHCPREQUEST message commits the binding for the client to persistent storage and responds with a DHCPACK message containing the configuration parameters for the requesting client. The combination of ’client identifier’ or ’chaddr’ and assigned network address constitute a unique identifier for the client’s lease and are used by both the client and server to identify a lease referred to in any DHCP messages. Any configuration parameters in the DHCPACK message SHOULD NOT conflict with those in the earlier DHCPOFFER message to which the client is responding. The server SHOULD NOT check the offered network address at this point. The ’yiaddr’ field in the DHCPACK messages is filled in with the selected network address.

如果选择的服务器不能满足DHCPREQUEST消息（比如，请求的网络地址已经被分配），服务器应该响应一个DHCPNAK消息。

If the selected server is unable to satisfy the DHCPREQUEST message (e.g., the requested network address has been allocated), the server SHOULD respond with a DHCPNAK message.

服务器可以选择在DHCPOFFER消息中将提供给客户端的地址标志为不可利用。如果服务器没有从那个客户端接收到DHCPREQUEST消息，服务器应该将提供给那个客户端的地址标志为可利用。

A server MAY choose to mark addresses offered to clients in DHCPOFFER messages as unavailable. The server SHOULD mark an address offered to a client in a DHCPOFFER message as available if the server receives no DHCPREQUEST message from that client.

1. 客户端接收到带有配置参数的DHCPACK消息。客户端应该对参数执行一个最终检查（例如，对分配的网络地址发ARP），并注意在DHCPACK消息中指定的租期。到这里，客户端就被配置了。如果客户端发现地址已经在使用（比如通过ARP），客户端必须发一个DHCPDECLINE消息给服务器并重新开始配置进程。在重新开始配置进程之前，客户端应该最少等待10秒钟以避免万一有环路时过多的网络流量。

5. The client receives the DHCPACK message with configuration parameters. The client SHOULD perform a final check on the parameters (e.g., ARP for allocated network address), and notes the duration of the lease specified in the DHCPACK message. At this point, the client is configured. If the client detects that the address is already in use (e.g., through the use of ARP), the client MUST send a DHCPDECLINE message to the server and restarts the configuration process. The client SHOULD wait a minimum of ten seconds before restarting the configuration process to avoid excessive network traffic in case of looping.

如果接收到DHCPNAK消息，客户端重新开始配置进程。

If the client receives a DHCPNAK message, the client restarts the configuration process.

如果即没有接收到DHCPACK消息，也没有收到DHCPNAK消息，客户端将超时并重传DHCPREQUEST消息。客户端根据4.1节讲述的重传算法重传DHCPREQUEST消息。在放弃以前，客户端应该选择足够多的重传DHCPREQUEST的次数，使得即不会使客户端等待过长的时间，有可以尽量取得和服务器联系的可能性；比如，4.1节描述的客户端重传可以重传DHCPREQUEST消息四次，在重新开始初始化过程之前，总的延迟是60秒。如果重传后，客户端还没有收到DHCPACK或DHCPNAK消息，客户端回到INIT状态，并重新开始初始化进程。客户端应该通知用户初始化进程已经失败，正重新开始。

The client times out and retransmits the DHCPREQUEST message if the client receives neither a DHCPACK or a DHCPNAK message. The client retransmits the DHCPREQUEST according to the retransmission algorithm in section 4.1. The client should choose to retransmit the DHCPREQUEST enough times to give adequate probability of contacting the server without causing the client (and the user of that client) to wait overly long before giving up; e.g., a client retransmitting as described in section 4.1 might retransmit the DHCPREQUEST message four times, for a total delay of 60 seconds, before restarting the initialization procedure. If the client receives neither a DHCPACK or a DHCPNAK message after employing the retransmission algorithm, the client reverts to INIT state and restarts the initialization process. The client SHOULD notify the user that the initialization process has failed and is restarting.

6. 通过发一个DHCPRELEASE消息给服务器，客户端可以选择放弃它的网络地址的租约。在DHCPRELEASE消息中，客户端用“client identifier”或“chaddr”和网络地址标识被释放的租约。如果客户端在获取租约的时候使用“client identifier”,它必须在DHCPRELEASE消息中使用相同的“client identifier”。

6. The client may choose to relinquish its lease on a network address by sending a DHCPRELEASE message to the server. The client identifies the lease to be released with its ’client identifier’, or ’chaddr’ and network address in the DHCPRELEASE message. If the client used a ’client identifier’ when it obtained the lease, it MUST use the same ’client identifier’ in the DHCPRELEASE message.

1. 1. Client-server interaction - reusing a previously allocated network address

如果客户端记得并希望重新利用先前分配的网络地址，客户端可以选择省略前一节中的一些步骤。图4中的时间线图显示了典型的为了客户端重新利用先前分配的网络地址的客户端－服务器相互作用的时间关系。

If a client remembers and wishes to reuse a previously allocated network address, a client may choose to omit some of the steps described in the previous section. The timeline diagram in figure 4 shows the timing relationships in a typical client-server interaction for a client reusing a previously allocated network address.

1. 客户端在它的局部子网广播一个DHCPREQUEST消息。在消息的“requested IP address”选项中包含客户端的网络地址。因为客户端还没有收到它的网络地址，它不可以填充它的“ciaddr”域。BOOTP中继代理将消息传送给不在同一个子网的DHCP服务器。如果客户端使用“client identifier”来获取它的地址，客户端必须在DHCPREQUEST消息中使用相同的“client identifier”。

1. The client broadcasts a DHCPREQUEST message on its local subnet. The message includes the client’s network address in the ’requested IP address’ option. As the client has not received its network address, it MUST NOT fill in the ’ciaddr’ field. BOOTP relay agents pass the message on to DHCP servers not on the same subnet. If the client used a ’client identifier’ to obtain its address, the client MUST use the same ’client identifier’ in the DHCPREQUEST message.

1. 知道客户端的配置参数的服务器回应一个DHCPACK消息给客户端。服务器不应该检查客户端的网络地址是否已经在使用；在这里客户端可能响应ICMP请求消息。

2. Servers with knowledge of the client’s configuration parameters respond with a DHCPACK message to the client. Servers SHOULD NOT check that the client’s network address is already in use; the client may respond to ICMP Echo Request messages at this point.

如果客户端的请求是无效的（比如，客户端已经移到一个新的子网），服务器应该响应一个DHCPNAK消息给客户端。如果他们的信息不被保证是准确的，服务器不应该响应。例如，如果一个服务器鉴别到请求是属于另一个服务器的过期的绑定，它不应该响应DHCPNAK，除非服务器使用明确的机制维持服务器间的相干性。

If the client’s request is invalid (e.g., the client has moved to a new subnet), servers SHOULD respond with a DHCPNAK message to the client. Servers SHOULD NOT respond if their information is not guaranteed to be accurate. For example, a server that identifies a request for an expired binding that is owned by another server SHOULD NOT respond with a DHCPNAK unless the servers are using an explicit mechanism to maintain coherency among the servers.

如果DHCPREQUEST消息的“giaddr”是0x0，客户端和服务器在同一个子网。服务器必须向0xffffffff广播地址广播DHCPNAK消息因为客户端可能没有正确的网络地址或子网掩码，而且客户端可能不应答ARP请求。否则，服务器必须将DHCPNAK消息发送给记录在“giaddr”中的BOOTP中继代理的IP地址。反过来，中继代理将把消息直接转发给客户端的硬件地址，这样，即使客户端已经移到一个新的网络，DHCPNAK也可以被传递到。

If ’giaddr’ is 0x0 in the DHCPREQUEST message, the client is on the same subnet as the server. The server MUST broadcast the DHCPNAK message to the 0xffffffff broadcast address because the client may not have a correct network address or subnet mask, and the client may not be answering ARP requests. Otherwise, the server MUST send the DHCPNAK message to the IP address of the BOOTP relay agent, as recorded in ’giaddr’. The relay agent will, in turn, forward the message directly to the client’s hardware address, so that the DHCPNAK can be delivered even if the client has moved to a new network.

Figure 4: Timeline diagram of messages exchanged between DHCP

client and servers when reusing a previously allocated

network address

1. 客户端接收到关于配置参数的DHCPACK消息。客户端对参数执行一次最终检查（和3.1节中的一样），并注意到DHCPAK消息中指定的租约的时间。“client identifier”或“chaddr”和网络地址隐含的标识了特定的租约。到这里，客户端就被配置了。

3. The client receives the DHCPACK message with configuration parameters. The client performs a final check on the parameters (as in section 3.1), and notes the duration of the lease specified in the DHCPACK message. The specific lease is implicitly identified by the ’client identifier’ or ’chaddr’ and the network address. At this point, the client is configured.

如果客户端发现DHCPACK消息中的IP地址已经被使用，客户端必须发一个DHCPDECLINE消息给服务器并通过请求一个新的网络地址来重新开始配置过程。这个动作和客户端移到4.4节中描述的DHCP状态图中的INIT状态相对应。

If the client detects that the IP address in the DHCPACK message is already in use, the client MUST send a DHCPDECLINE message to the server and restarts the configuration process by requesting a new network address. This action corresponds to the client moving to the INIT state in the DHCP state diagram, which is described in section 4.4.

如果客户端收到DHCPNAK消息，它不可以重新使用它记得的网络地址。它必须重新开始配置过程，请求一个新的地址，这一次使用3.1节中描述的（非简短的）过程。这个动作也和客户端移到DHCP状态图中的INIT状态相对应。

If the client receives a DHCPNAK message, it cannot reuse its remembered network address. It must instead request a new address by restarting the configuration process, this time using the (non-abbreviated) procedure described in section 3.1. This action also corresponds to the client moving to the INIT state in the DHCP state diagram.

如果客户端没有收到DHCPACK或DHCPNAK消息，客户端将超时并重传DHCPREQUEST消息。客户端根据4.1节讲述的重传算法重传DHCPREQUEST消息。在放弃以前，客户端应该选择足够多的重传DHCPREQUEST的次数，使得即不会使客户端等待过长的时间，有可以尽量取得和服务器联系的可能性；比如，4.1节描述的客户端重传可以重传DHCPREQUEST消息四次，在重新开始初始化过程之前，总的延迟是60秒。如果重传后客户端还没有收到DHCPACK或DHCPNAK消息，客户端可以选择在剩下的没有到期的租约中使用先前分配的网络地址和配置参数。这个与移到图5中显示的客户端状态转换图中的BOUND状态对应。

The client times out and retransmits the DHCPREQUEST message if the client receives neither a DHCPACK nor a DHCPNAK message. The client retransmits the DHCPREQUEST according to the retransmission algorithm in section 4.1. The client should choose to retransmit the DHCPREQUEST enough times to give adequate probability of contacting the server without causing the client (and the user of that client) to wait overly long before giving up; e.g., a client retransmitting as described in section 4.1 might retransmit the DHCPREQUEST message four times, for a total delay of 60 seconds, before restarting the initialization procedure. If the client receives neither a DHCPACK or a DHCPNAK message after employing the retransmission algorithm, the client MAY choose to use the previously allocated network address and configuration parameters for the remainder of the unexpired lease. This corresponds to moving to BOUND state in the client state transition diagram shown in figure 5.

1. 通过发一个DHCPRELEASE消息给服务器，客户端可以选择放弃它的网络地址的租约。在DHCPRELEASE消息中，客户端用“client identifier”或“chaddr”和网络地址标识被释放的租约。

4. The client may choose to relinquish its lease on a network address by sending a DHCPRELEASE message to the server. The client identifies the lease to be released with its ’client identifier’, or ’chaddr’ and network address in the DHCPRELEASE message.

注意在这种情况下，客户端在本地保留它的网络地址，通常客户端在正确关机的时候不会放弃它的租约。只有在客户端明确需要放弃它的租约的情况下，比如，客户端将要移到不同的子网，客户端将发送DHCPRELEASE消息。

Note that in this case, where the client retains its network address locally, the client will not normally relinquish its lease during a graceful shutdown. Only in the case where the client explicitly needs to relinquish its lease, e.g., the client is about to be moved to a different subnet, will the client send a DHCPRELEASE message.

1. 1. Interpretation and representation of time values

客户端获得一个网络地址在一个固定时间内（可以是无限的）的租约。贯穿整个协议，时间以秒为单位来表示。0xffffffff的时间值保留来表示“无限”。

A client acquires a lease for a network address for a fixed period of time (which may be infinite). Throughout the protocol, times are to be represented in units of seconds. The time value of 0xffffffff is reserved to represent "infinity".

由于客户端和服务器可能没有同步的时钟，DHCP消息中表示的时间是相对时间，根据客户端本地时钟来解释。在一个无符号的32位的字中以秒为单位表示相对时间给出了一个从0到大约100年的相对时间的范围，这已经足够给DHCP来测量相对时间。

As clients and servers may not have synchronized clocks, times are represented in DHCP messages as relative times, to be interpreted with respect to the client’s local clock. Representing relative times in units of seconds in an unsigned 32 bit word gives a range of relative times from 0 to approximately 100 years, which is sufficient for the relative times to be measured using DHCP.

前一节阐述的租期的算法假设相对于彼此的时钟，客户端和服务器的时钟是稳定的。如果两个时钟之间有漂移，在客户端的租约到期之前，服务器可能认为租约已经到期。为了补偿，服务器可以给客户端返回一个比服务器提交给它的客户端信息本地数据库短的租期。

The algorithm for lease duration interpretation given in the previous paragraph assumes that client and server clocks are stable relative to each other. If there is drift between the two clocks, the server may consider the lease expired before the client does. To compensate, the server may return a shorter lease duration to the client than the server commits to its local database of client information.

1. 1. Obtaining parameters with externally configured network address

如果客户端已经通过其它方式获取了网络地址（比如手动配置），它可以使用DHCPINFORM请求消息获取其它局部配置参数。接收到DHCPINFORM消息的服务器构造一个关于适合客户端的所有本地配置参数的DHCPACK消息，但不：分配新地址，检查现有的绑定，填充“yiaddr”或包含租期参数。服务器应该单播DHCPACK应答给DHCPINFORM消息中的“ciaddr”域中给出的地址。

If a client has obtained a network address through some other means (e.g., manual configuration), it may use a DHCPINFORM request message to obtain other local configuration parameters. Servers receiving a DHCPINFORM message construct a DHCPACK message with any local configuration parameters appropriate for the client without: allocating a new address, checking for an existing binding, filling in ’yiaddr’ or including lease time parameters. The servers SHOULD unicast the DHCPACK reply to the address given in the ’ciaddr’ field of the DHCPINFORM message.

为了一致，服务器应该检查DHCPINFORM消息中网络地址，但不可以检查现有的租约。对于发出请求的客户端，服务器构造一个包含配置参数的DHCPACK消息并将DHCPACK消息直接发给客户端。

The server SHOULD check the network address in a DHCPINFORM message for consistency, but MUST NOT check for an existing lease. The server forms a DHCPACK message containing the configuration parameters for the requesting client and sends the DHCPACK message directly to the client.

1. 1. Client parameters in DHCP

表示所有的客户端都要求将附录A中列出的所有参数初始化。两个方法用来减少传输从服务器到客户端的参数的数量。第一，很多参数在Host Requirements RFCs中定义了默认值；如果客户端没有从服务器接收的覆盖默认值的参数，客户端使用那些默认值。第二，在它的初始化的DHCPDISCOVER或DHCPREQUEST消息中，客户端可以给服务器提供一个它感兴趣的指定参数的列表。如果客户端在DHCPDISCOVER消息中包含了参数列表，他必须在所有的后继的DHCPREQUEST消息中包含那个列表。

Not all clients require initialization of all parameters listed in Appendix A. Two techniques are used to reduce the number of parameters transmitted from the server to the client. First, most of the parameters have defaults defined in the Host Requirements RFCs; if the client receives no parameters from the server that override the defaults, a client uses those default values. Second, in its initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the server with a list of specific parameters the client is interested in. If the client includes a list of parameters in a DHCPDISCOVER message, it MUST include that list in any subsequent DHCPREQUEST messages.

客户端应该包含“maximum DHCP message size”选项让服务器知道可以构造多大的DHCP消息。返回给客户端的参数可能仍旧超过了DHCP消息分配给选项的空间。在这种情况下，两个选项标志（必须出现在消息的“options”域中）指出“file”和“sname”域将用于选项。

The client SHOULD include the ’maximum DHCP message size’ option to let the server know how large the server may make its DHCP messages. The parameters returned to a client may still exceed the space allocated to options in a DHCP message. In this case, two additional options flags (which must appear in the ’options’ field of the message) indicate that the ’file’ and ’sname’ fields are to be used for options.

通过包括“parameter request list”选项，客户端可以告诉服务器哪些配置参数是客户端感兴趣的。这个选项的数据部分明确列出了标签数字请求的选项。

The client can inform the server which configuration parameters the client is interested in by including the ’parameter request list’ option. The data portion of this option explicitly lists the options requested by tag number.

另外，客户端可以在DHCPDISCOVER消息中建议网络地址和租期。客户端可以包括“requested IP address”选项来建议分配特定的IP地址，也可以包括“IP address lease time”选项来建议它想要的租期。在DHCPDISCOVER和DHCPREQUEST消息中也允许其它在配置参数表示“线索”选项。然而，附加的选项可能被服务器忽略，而且，对于一些选项，多重的服务器可以不返回相同的值。当客户端在检验先前获取的网络参数时，“requested IP address”选项只在DHCPREQUEST消息中被填充。客户端只在在BOUND,RENEWING或者REBINDING状态正确配置了IP地址的时候填充“ciaddr”域。

In addition, the client may suggest values for the network address and lease time in the DHCPDISCOVER message. The client may include the ’requested IP address’ option to suggest that a particular IP address be assigned, and may include the ’IP address lease time’ option to suggest the lease time it would like. Other options representing "hints" at configuration parameters are allowed in a DHCPDISCOVER or DHCPREQUEST message. However, additional options may be ignored by servers, and multiple servers may, therefore, not return identical values for some options. The ’requested IP address’ option is to be filled in only in a DHCPREQUEST message when the client is verifying network parameters obtained previously. The client fills in the ’ciaddr’ field only when correctly configured with an IP address in BOUND, RENEWING or REBINDING state.

如果服务器接收到带有无效的“requested IP address”的DHCPREQUEST消息，服务器应该回应DHCPNAK消息给客户端，并可以选择将问题报告给系统管理员。服务器可以在“message”选项包含一个错误消息。

If a server receives a DHCPREQUEST message with an invalid ’requested IP address’, the server SHOULD respond to the client with a DHCPNAK message and may choose to report the problem to the system administrator. The server may include an error message in the ’message’ option.

1. 1. Use of DHCP in clients with multiple interfaces

有多个网络接口的客户端必须给那些单独的接口通过每个接口单独的使用DHCP获取配置信息参数。

A client with multiple network interfaces must use DHCP through each interface independently to obtain configuration information parameters for those separate interfaces.

1. 1. When clients should use DHCP

无论何时当地网络参数可能已经改变，客户端应该用DHCP重新获取和验证它的IP地址和网络参数；比如，在系统启动的时间或从当地网络断开之后，因为本地网络配置可能在客户端或用户不知道的时候发生了变化。

A client SHOULD use DHCP to reacquire or verify its IP address and network parameters whenever the local network parameters may have changed; e.g., at system boot time or after a disconnection from the local network, as the local network configuration may change without the client’s or user’s knowledge.

如果客户端知道先前的网络地址，并且不能和当地的DHCP服务器联系，客户端可以继续使用先前的网络地址直到那个地址的租约到期。如果租约到期的使用客户端还不能和DHCP服务器联系，客户端必须立即停止使用前一个网络地址并可以将这个问题通知本地用户。

If a client has knowledge of a previous network address and is unable to contact a local DHCP server, the client may continue to use the previous network address until the lease for that address expires. If the lease expires before the client can contact a DHCP server, the client must immediately discontinue use of the previous network address and may inform local users of the problem.

1. Specification of the DHCP client-server protocol

在这一节，我们假设DHCP服务器中断了网络地址，不能满足对新地址的请求。每个服务器也在本地永久存储器维持一个分配地址和租约的数据库。

In this section, we assume that a DHCP server has a block of network addresses from which it can satisfy requests for new addresses. Each server also maintains a database of allocated addresses and leases in local permanent storage.

1. 1. Constructing and sending DHCP messages

DHCP客户端和服务器都通过在消息的固定格式部分填充域和在可变长度选项区附加带标签的数据项目构造DHCP消息。选项区首先包括一个四字节的“magic cookie”（3节中描述），接着是选项。最后的选项必须总是“end”选项。

DHCP clients and servers both construct DHCP messages by filling in fields in the fixed format section of the message and appending tagged data items in the variable length option area. The options area includes first a four-octet ’magic cookie’ (which was described in section 3), followed by the options. The last option must always be the ’end’ option.

DHCP用UDP作为它的传输协议。从客户端到服务器的DHCP消息被送到“DHCP server”端口（67），从服务器到客户端的DHCP消息被送到“DHCP client”端口（68）。有多个网络地址的服务器可以在外出的DHCP消息中使用任意一个它的网络地址。

DHCP uses UDP as its transport protocol. DHCP messages from a client to a server are sent to the ’DHCP server’ port (67), and DHCP messages from a server to a client are sent to the ’DHCP client’ port (68). A server with multiple network address (e.g., a multi-homed host) MAY use any of its network addresses in outgoing DHCP messages.

DHCP消息中的“server identifier”域即用来标识DHCP服务器，也作为客户端到服务器的目的地址。有多个网络地址的服务器必须准备接收在DHCP消息中当做标识那个服务器的任意一个它的网络地址。为了适应潜在的不完整的网络连通性，服务器必须选择一个客户端可以到达的服务器知道的地址作为“server identifier”。例如，如果DHCP服务器和客户端都连在同一个子网上（即，从客户端来的消息的“giaddr”域是0），服务器应该选择服务器用来在那个子网通信的IP地址作为“server identifier”。如果服务器在那个子网上使用多个IP地址，任意一个这样的地址都可以使用。如果服务器接收到DHCP中继代理的消息，服务器应该选择接收到这条消息的接口的地址作为“server identifier”（除非服务器有其它更好的信息来作出选择）。DHCP客户端必须使用“server identifier”选项提供的IP地址来单播请求给DHCP服务器。

The ’server identifier’ field is used both to identify a DHCP server in a DHCP message and as a destination address from clients to servers. A server with multiple network addresses MUST be prepared to to accept any of its network addresses as identifying that server in a DHCP message. To accommodate potentially incomplete network connectivity, a server MUST choose an address as a ’server identifier’ that, to the best of the server’s knowledge, is reachable from the client. For example, if the DHCP server and the DHCP client are connected to the same subnet (i.e., the ’giaddr’ field in the message from the client is zero), the server SHOULD select the IP address the server is using for communication on that subnet as the ’server identifier’. If the server is using multiple IP addresses on that subnet, any such address may be used. If the server has received a message through a DHCP relay agent, the server SHOULD choose an address from the interface on which the message was recieved as the ’server identifier’ (unless the server has other, better information on which to make its choice). DHCP clients MUST use the IP address provided in the ’server identifier’ option for any unicast requests to the DHCP server.

在客户端获取它的IP地址之前广播的DHCP消息必须在IP头中将源地址域设为0。

DHCP messages broadcast by a client prior to that client obtaining its IP address must have the source address field in the IP header set to 0.

如果从客户端来的DHCP消息的“giaddr”域不是0，服务器发送所有返回消息给地址出现在“giaddr”中BOOTP中继代理上的“DHCP server”端口。如果“giaddr”域是0并且“ciaddr”域不是0，服务器单播DHCPOFFER和DHCPACK消息给“ciaddr”中的地址。如果“giaddr”域是0，“ciaddr”域也是0，并且广播位被设置，服务器广播DHCPOFFER和DHCPACK消息给0xffffffff。如果广播位没有被设置，而且“giaddr”域和“ciaddr”域是0，那么服务器单播DHCPOFFER和DHCPACK消息给客户端的硬件地址和“yiaddr”地址。在所有情况下，当“giaddr”域是0时，服务器广播所有DHCPNAK消息给0xffffffff。

If the ’giaddr’ field in a DHCP message from a client is non-zero, the server sends any return messages to the ’DHCP server’ port on the BOOTP relay agent whose address appears in ’giaddr’. If the ’giaddr’ field is zero and the ’ciaddr’ field is nonzero, then the server unicasts DHCPOFFER and DHCPACK messages to the address in ’ciaddr’. If ’giaddr’ is zero and ’ciaddr’ is zero, and the broadcast bit is set, then the server broadcasts DHCPOFFER and DHCPACK messages to 0xffffffff. If the broadcast bit is not set and ’giaddr’ is zero and ’ciaddr’ is zero, then the server unicasts DHCPOFFER and DHCPACK messages to the client’s hardware address and ’yiaddr’ address. In all cases, when ’giaddr’ is zero, the server broadcasts any DHCPNAK messages to 0xffffffff.

如果DHCP消息的选项扩展到“sname”和“file”域，“option overload”选项必须出现在“options”域，与RFC1533定义的一样，值是1，2和3。如果“option overload”选项必须出现在“options”域，“options”域中的选项必须由“end”选项终结，并且可以包含一个或多个“pad”选项来填充选项域。“sname”和“file”域中的选项（如果和“option overload”选项指出的一样使用）必须以这个域的第一个字节开始，以“end”选项结束，而且必须用“pad”选项来填充剩余的域。所有“options”，“sname”和“file”域中的单独的选项必须整个被包含在那个域中。“options”域中的选项必须首先被解释，因此所有“option overload”选项才可以被解释。“file”域必须下一个被解释（如果“option overload”选项指出“file”域包含DHCP选项），接着是“sname”域。

If the options in a DHCP message extend into the ’sname’ and ’file’ fields, the ’option overload’ option MUST appear in the ’options’ field, with value 1, 2 or 3, as specified in RFC 1533. If the ’option overload’ option is present in the ’options’ field, the options in the ’options’ field MUST be terminated by an ’end’ option, and MAY contain one or more ’pad’ options to fill the options field. The options in the ’sname’ and ’file’ fields (if in use as indicated by the ’options overload’ option) MUST begin with the first octet of the field, MUST be terminated by an ’end’ option, and MUST be followed by ’pad’ options to fill the remainder of the field. Any individual option in the ’options’, ’sname’ and ’file’ fields MUST be entirely contained in that field. The options in the ’options’ field MUST be interpreted first, so that any ’option overload’ options may be interpreted. The ’file’ field MUST be interpreted next (if the ’option overload’ option indicates that the ’file’ field contains DHCP options), followed by the ’sname’ field.

在“options”标签中被传递的值可能太长而不能放进一个选项提供的255个字节中（例如，“router”选项中的路由器列表）。选项可能只出现一次，除非另外在选项文档中指明。客户端将同一个选项的多个实例的值连接成一个配置的参数列表。

The values to be passed in an ’option’ tag may be too long to fit in the 255 octets available to a single option (e.g., a list of routers in a ’router’ option [21]). Options may appear only once, unless otherwise specified in the options document. The client concatenates the values of multiple instances of the same option into a single parameter list for configuration.

DHCP客户端对所有消息的重传负责。客户端必须采用一个混合随机指数补偿算法的重传策略来决定重传之间的延迟。重传之间的延迟应该根据客户端和服务器之间的因特网络的特点选择为允许足够的时间来将应答从服务器传递出去。例如，在10Mb/sec的以太网网络中，第一次重传以前的被从－1到1的范围内选择的统一的随机数字的值随机化的延迟应该是4秒。时钟的分辨率的粒度小于1秒的客户端可以选择非整数的随机化的值。下一次重传之前的被从－1到1的范围内选择的统一的随机数字的值随机化的延迟应该是8秒。重传延迟应该是后继的重传的两倍，直到最大值64秒。客户端可以给用户提供一个重传尝试的指示作为配置过程的过程的指示。

DHCP clients are responsible for all message retransmission. The client MUST adopt a retransmission strategy that incorporates a randomized exponential backoff algorithm to determine the delay between retransmissions. The delay between retransmissions SHOULD be chosen to allow sufficient time for replies from the server to be delivered based on the characteristics of the internetwork between the client and the server. For example, in a 10Mb/sec Ethernet internetwork, the delay before the first retransmission SHOULD be 4 seconds randomized by the value of a uniform random number chosen from the range -1 to +1. Clients with clocks that provide resolution granularity of less than one second may choose a non-integer randomization value. The delay before the next retransmission SHOULD be 8 seconds randomized by the value of a uniform number chosen from the range -1 to +1. The retransmission delay SHOULD be doubled with subsequent retransmissions up to a maximum of 64 seconds. The client MAY provide an indication of retransmission attempts to the user as an indication of the progress of the configuration process.

“xid”域被客户端用来和进来的有关挂起的请求的DHCP消息匹配。DHCP客户端必须这样选择“xid”以减少和另一个客户端使用相同的“xid”的机会。例如，每次重新启动的时候，客户端可以选择一个不同的，随机的初始“xid”，并且随后使用连续的“xid”直到下一次重启。为每次重传选择新的“xid”是实现的决定。客户端可以选择重新利用相同的“xid”或为每次的重传消息选择一个新的“xid”。

The ’xid’ field is used by the client to match incoming DHCP messages with pending requests. A DHCP client MUST choose ’xid’s in such a way as to minimize the chance of using an ’xid’ identical to one used by another client. For example, a client may choose a different, random initial ’xid’ each time the client is rebooted, and subsequently use sequential ’xid’s until the next reboot. Selecting a new ’xid’ for each retransmission is an implementation decision. A client may choose to reuse the same ’xid’ or select a new ’xid’ for each retransmitted message.

通常，DHCP服务器和BOOTP中继代理努力用单播直接将DHCPOFFER,DHCPACK和DHCPNAK消息传递给客户端。IP目的地址（在IP头中）设置为DHCP“yiaddr”地址，链路层目的地址设置为DHCP“chaddr”地址。不幸的是，一些客户端实现不能够接收这样的单播IP报文，直到实现配置了有效的IP地址（导致客户端的IP地址不能被传递的死锁，直到客户端被配置了IP地址）。

Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using uicast delivery. The IP destination address (in the IP header) is set to the DHCP ’yiaddr’ address and the link-layer destination address is set to the DHCP ’chaddr’ address. Unfortunately, some client implementations are unable to receive such unicast IP datagrams until the implementation has been configured with a valid IP address (leading to a deadlock in which the client’s IP address cannot be delivered until the client has been configured with an IP address).

在它的协议软件配置了IP地址以前不能接收单播IP报文的客户端应该在所有客户端发送的DHCPDISCOVER或DHCPREQUEST消息的“flags”域中将BROADCAST位设置为1。BROADCAST位将给DHCP服务器和BOOTP中继代理提供线索在客户端的子网内广播所有消息给客户端。在它的协议软件配置之前可以接收单播IP报文的客户端应该将BROADCAST位清除为0。BOOTP说明文档讨论了使用BROADCAST位的区别。

A client that cannot receive unicast IP datagrams until its protocol software has been configured with an IP address SHOULD set the BROADCAST bit in the ’flags’ field to 1 in any DHCPDISCOVER or DHCPREQUEST messages that client sends. The BROADCAST bit will provide a hint to the DHCP server and BOOTP relay agent to broadcast any messages to the client on the client’s subnet. A client that can receive unicast IP datagrams before its protocol software has been configured SHOULD clear the BROADCAST bit to 0. The BOOTP clarifications document discusses the ramifications of the use of the BROADCAST bit [21].

直接将DHCP消息发送或中继给DHCP客户端（不是给“giaddr”域中指定的中继代理）的服务器或中继代理应该检查“flags”域中的BROADCAST位。如果这一位被设为1，DHCP消息应该作为IP广播被发送，使用IP广播地址（最好是0xffffffff）作为IP目的地址，链路层广播地址作为链路层目的地址。如果BROADCAST位是0，消息应该作为IP单播被发送到“yiaddr”域中指定的IP地址和“chaddr”域中指定的链路层地址。如果不可能单播，消息可以作为IP广播被发送，使用IP广播地址（最好是0xffffffff）作为IP目的地址，链路层广播地址作为链路层目的地址。

A server or relay agent sending or relaying a DHCP message directly to a DHCP client (i.e., not to a relay agent specified in the ’giaddr’ field) SHOULD examine the BROADCAST bit in the ’flags’ field. If this bit is set to 1, the DHCP message SHOULD be sent as an IP broadcast using an IP broadcast address (preferably 0xffffffff) as the IP destination address and the link-layer broadcast address as the link-layer destination address. If the BROADCAST bit is cleared to 0, the message SHOULD be sent as an IP unicast to the IP address specified in the ’yiaddr’ field and the link-layer address specified in the ’chaddr’ field. If unicasting is not possible, the message MAY be sent as an IP broadcast using an IP broadcast address (preferably 0xffffffff) as the IP destination address and the link- layer broadcast address as the link-layer destination address.

1. 1. DHCP server administrative controls

DHCP服务器不被要求回应它们接收的每个DHCPDISCOVER和DHCPREQUEST消息。例如，为了保持对连接在网络上的客户端进行严格的控制，网络管理员可以选择配置DHCP服务器只响应那些先前已经通过某些外部方式注册过的客户端。DHCP规格只描述当客户端和服务器选择交互的时候客户端和服务器之间的交互作用；描述所有系统管理员可能想使用的管理控制不在DHCP规格的范围内。特定的DHCP服务器实现可以合并一些网络管理员想要的控制或政策。

DHCP servers are not required to respond to every DHCPDISCOVER and DHCPREQUEST message they receive. For example, a network administrator, to retain stringent control over the clients attached to the network, may choose to configure DHCP servers to respond only to clients that have been previously registered through some external mechanism. The DHCP specification describes only the interactions between clients and servers when the clients and servers choose to interact; it is beyond the scope of the DHCP specification to describe all of the administrative controls that system administrators might want to use. Specific DHCP server implementations may incorporate any controls or policies desired by a network administrator.

在一些环境下，当为特别的客户端决定正确的参数时，DHCP服务器将不得不考虑包含在DHCPDISCOVER或DHCPREQUEST消息中的厂商类别选项的值。

In some environments, a DHCP server will have to consider the values of the vendor class options included in DHCPDISCOVER or DHCPREQUEST messages when determining the correct parameters for a particular client.

DHCP服务器需要利用一些唯一的标识符来将客户端和它的租约联系起来。客户端可以选择在“client identifier”选项中明确的提供标识符。如果客户端提供了“client identifier”，客户端必须在所有后继的消息中使用相同的“client identifier”，并且服务器必须使用那个标识符来识别客户端。如果客户端没有提供“client identifier”选项，服务器必须使用“chaddr”域中的内容来识别客户端。DHCP客户端在“client identifier”选项中使用的标识符是与它连接的子网中唯一的，这一点很重要。使用“chaddr”作为客户端的唯一的标识符可能引起想不到的结果，因为那个标识符可能和硬件接口关联，它可以被移到新的客户端上。有些地方可能选择使用制造商的序列号作为“client identifier”，以避免由于计算机中硬件接口的转移产生的客户端网络地址的不可预料的变化。有些地方可能也选择DNS名字作为“client identifier”，使得地址租约和DNS名字联系起来而不是特定的硬件盒。

A DHCP server needs to use some unique identifier to associate a client with its lease. 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. It is crucial for a DHCP client to use an identifier unique within the subnet to which the client is attached in the ’client identifier’ option. 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 clients 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.

客户端自由的使用任何策略从它接收到的DHCPOFFER消息中选择DHCP服务器。DHCP的客户端实现应该提供一种方式给用户，使得他们可以直接选择“vendor class identifier”的值。

DHCP clients are free to use any strategy in selecting a DHCP server among those from which the client receives a DHCPOFFER message. The client implementation of DHCP SHOULD provide a mechanism for the user to select directly the ’vendor class identifier’ values.

1. 1. DHCP server behavior

DHCP服务器根据那个客户端绑定的当前状态来处理从这个客户端来的DHCP消息。DHCP服务器可以接收从客户端来的以下消息：

A DHCP server processes incoming DHCP messages from a client based on the current state of the binding for that client. A DHCP server can receive the following messages from a client:

1. DHCPDISCOVER
2. DHCPREQUEST
3. DHCPDECLINE
4. DHCPRELEASE
5. DHCPINFORM

表3给出了服务器的DHCP消息中使用的域和选项。这一节的剩余部分描述了DHCP服务器对于每个可能进来的消息的动作。

Table 3 gives the use of the fields and options in a DHCP message by a server. The remainder of this section describes the action of the DHCP server for each possible incoming message.

1. 1. 1. DHCPDISCOVER message

当服务器接收到从客户端来的DHCPDISCOVER消息时，服务器为请求的客户端选择一个网络地址。如果没有地址可利用，服务器可以选择将问题报告给系统管理员。如果地址可利用，应该按下面选择新地址：

When a server receives a DHCPDISCOVER message from a client, the server chooses a network address for the requesting client. If no address is available, the server may choose to report the problem to the system administrator. If an address is available, the new address SHOULD be chosen as follows:

1. 客户端的当前地址与记录在客户端的当前绑定中的一样，或者

o The client’s current address as recorded in the client’s current binding, ELSE

1. 客户端先前的地址与记录在客户端（现在已经到期或者释放）的绑定中的一样，如果那个地址在服务器的可利用的地址池中并且还没有被分配，或者

o The client’s previous address as recorded in the client’s (now expired or released) binding, if that address is in the server’s pool of available addresses and not already allocated, ELSE

1. 在“Requested IP Address”选项中请求的地址，如果那个地址是有效的而且还没有被分配，或者

o The address requested in the ’Requested IP Address’ option, if that address is valid and not already allocated, ELSE

1. 从服务器可利用的地址池中分配的新地址；根据接收消息（如果“giaddr是0）”的子网或者转发消息的中继代理（“giaddr不是0）的地址选择的地址。

o A new address allocated from the server’s pool of available adresses; the address is selected based on the subnet from which the message was received (if ’giaddr’ is 0) or on the address of the relay agent that forwarded the message (’giaddr’ when not 0).

和4.2节描述的一样，由于管理的原因，服务器可以分配请求以外的地址或者拒绝给某个客户端分配地址，即使有空闲的地址可利用。

As described in section 4.2, a server MAY, for administrative reasons, assign an address other than the one requested, or may refuse to allocate an address to a particular client even though free addresses are available.

注意到，在某些网络结构中（比如，分配了一个以上的IP子网给一个物理网段的因特网），可以有这样的情况，应该分配一个不同子网的地址给DHCP客户端而不是“giaddr”中记录的地址。这样，DHCP不要求从“giaddr”中的子网分配分配地址给客户端。服务器可以自由的选择一些别的子网，描述怎样选择IP地址的方式不在DHCP规格的范围内。

Note that, in some network architectures (e.g., internets with more than one IP subnet assigned to a physical network segment), it may be the case that the DHCP client should be assigned an address from a different subnet than the address recorded in ’giaddr’. Thus, DHCP does not require that the client be assigned as address from the subnet in ’giaddr’. A server is free to choose some other subnet, and it is beyond the scope of the DHCP specification to describe ways in which the assigned IP address might be chosen.

当不要求DHCP的正确操作的时候，在客户端回应服务器的DHCPOFFER消息之前，服务器不应该重新利用选择的网络地址。服务器可以选择将地址记录为提供给客户端。

While not required for correct operation of DHCP, the server SHOULD NOT reuse the selected network address before the client responds to the server’s DHCPOFFER message. The server may choose to record the address as offered to the client.

服务器还必须选择租约的到期时间，如下：

The server must also choose an expiration time for the lease, as follows:

1. 如果客户端没有在DHCPDISCOVER消息中请求指定租约，并且客户端已经有一个分配的网络地址，服务器返回先前分配的那个地址的租约到期时间（注意客户端必须明确的请求指定的租约来延长先前分配的地址的到期时间），或者

o IF the client has not requested a specific lease in the DHCPDISCOVER message and the client already has an assigned network address, the server returns the lease expiration time previously assigned to that address (note that the client must explicitly request a specific lease to extend the expiration time on a previously assigned address), ELSE

1. 如果客户端没有在DHCPDISCOVER消息中请求指定的租约，而且客户端也没有分配的网络地址，服务器分配一个本地配置的默认的租期，或者

o IF the client has not requested a specific lease in the DHCPDISCOVER message and the client does not have an assigned network address, the server assigns a locally configured default lease time, ELSE

1. 如果客户端在DHCPDISCOVER消息中请求指定的租约（不管客户端是否有分配的网络地址），服务器可以选择要么返回请求的租约（如果租约可被本地政策接受），要么选择另一个租约。

o IF the client has requested a specific lease in the DHCPDISCOVER message (regardless of whether the client has an assigned network address), the server may choose either to return the requested lease (if the lease is acceptable to local policy) or select another lease.

  

Table 3: Fields and options used by DHCP servers

一旦网络地址和租约已经决定，服务器用提供的配置参数构造DHCPOFFER消息。所有DHCP服务器返回相同的参数（连同新分配的网络地址的可能的例外），确保客户端行为的可预见性，不管客户端选择了哪个服务器，这一点很重要。必须按照下面给出的顺序应用以下的规则选择配置参数。网络管理员对配置多个DHCP服务器以确保从那些服务器发出相同的回应负责。服务器必须返回给客户端：

Once the network address and lease have been determined, the server constructs a DHCPOFFER message with the offered configuration parameters. It is important for all DHCP servers to return the same parameters (with the possible exception of a newly allocated network address) to ensure predictable client behavior regardless of which server the client selects. The configuration parameters MUST be selected by applying the following rules in the order given below. The network administrator is responsible for configuring multiple DHCP servers to ensure uniform responses from those servers. The server MUST return to the client:

1. 客户端的网络地址，与这一节中前面给出的规则决定的一样。

o The client’s network address, as determined by the rules given earlier in this section,

1. 客户端租约的到期时间，与这一节中前面给出的规则决定的一样。

o The expiration time for the client’s lease, as determined by the rules given earlier in this section,

1. 客户端请求的参数，根据以下的规则：

o Parameters requested by the client, according to the following rules:

-- 如果服务器已经明确的给参数配置了默认值，服务器必须将那个值包含在“option”域中合适的选项中，或者

-- IF the server has been explicitly configured with a default value for the parameter, the server MUST include that value in an appropriate option in the ’option’ field, ELSE 

-- 如果服务器认出这个参数域Host Requirements Document中定义的参数一样，服务器必须在“option”域中合适的选项中包含那个参数在Host Requirements Document中给出的默认值，或者

-- IF the server recognizes the parameter as a parameter defined in the Host Requirements Document, the server MUST include the default value for that parameter as given in the Host Requirements Document in an appropriate option in the ’option’ field, ELSE

-- 服务器不可以返回那个参数的值，服务器必须尽可能多的提供请求的参数，但必须省略那些它不能提供的参数。对于每个请求的参数，服务器只能包含一次，除非在DHCP选项和BOOTP制造商扩展文件中明确允许。

-- The server MUST NOT return a value for that parameter, The server MUST supply as many of the requested parameters as possible and MUST omit any parameters it cannot provide. The server MUST include each requested parameter only once unless explicitly allowed in the DHCP Options and BOOTP Vendor Extensions document.

1. 任何当前绑定的参数都和Host Requirements Document默认的不同，

o Any parameters from the existing binding that differ from the Host Requirements Document defaults,

1. 所有的参数指定给这个客户端（和DHCPDISCOVER或DHCPREQUEST消息中“chaddr”或“client identifer”的内容识别的一样），例如，和网络管理员配置的一样，

o Any parameters specific to this client (as identified by the contents of ’chaddr’ or ’client identifier’ in the DHCPDISCOVER or DHCPREQUEST message), e.g., as configured by the network administrator,

1. 所有的参数指定给这个客户端的种类（和DHCPDISCOVER或DHCPREQUEST消息中“vendor class identifier”选项的内容识别的一样），例如，和网络管理员配置的一样；参数必须被客户端的制造商种类标识符和服务器识别的客户端种类之间的准确匹配识别。

o Any parameters specific to this client’s class (as identified by the contents of the ’vendor class identifier’ option in the DHCPDISCOVER or DHCPREQUEST message), e.g., as configured by the network administrator; the parameters MUST be identified by an exact match between the client’s vendor class identifiers and the client’s classes identified in the server,

1. 参数在客户端子网中有非默认的值。

o Parameters with non-default values on the client’s subnet.

服务器可以选择返回用来决定DHCPOFFER消息中的参数的“vendor class identifier”来帮助客户端选择接受哪个DHCPOFFER。服务器将DHCPDISCOVER消息中的“xid”域插入到DHCPOFFER消息的“xid”域中并发送DHCPOFFER消息给请求的客户端。

The server MAY choose to return the ’vendor class identifier’ used to determine the parameters in the DHCPOFFER message to assist the client in selecting which DHCPOFFER to accept. The server inserts the ’xid’ field from the DHCPDISCOVER message into the ’xid’ field of the DHCPOFFER message and sends the DHCPOFFER message to the requesting client.

1. 1. 1. DHCPREQUEST message

DHCPREQUEST消息可以是来自客户端对来自服务器的DHCPOFFER消息的回应，也可以是客户端验证先前分配的IP地址或者客户端延长网络地址的租约。如果DHCPREQUEST消息中包含了“server identifier”选项，消息是DHCPOFFER消息的回应。否则，这个消息是请求验证或者延长当前的租约。如果客户端在DHCPREQUEST消息中使用了“client identifier”，它必须在后继所有的消息中使用相同的“client identifier”。如果客户端在DHCPDISCOVER消息中包含了一个请求参数的列表，它必须在所有后继的消息中包含这个列表。

A DHCPREQUEST message may come from a client responding to a DHCPOFFER message from a server, from a client verifying a previously allocated IP address or from a client extending the lease on a network address. If the DHCPREQUEST message contains a ’server identifier’ option, the message is in response to a DHCPOFFER message. Otherwise, the message is a request to verify or extend an existing lease. If the client uses a ’client identifier’ in a DHCPREQUEST message, it MUST use that same ’client identifier’ in all subsequent messages. If the client included a list of requested parameters in a DHCPDISCOVER message, it MUST include that list in all subsequent messages.

任何在DHCPACK消息中的配置参数不应该和那些客户端回应的先前的DHCPOFFER消息中的冲突。客户端应该使用DHCPACK消息中的参数来配置。

Any configuration parameters in the DHCPACK message SHOULD NOT conflict with those in the earlier DHCPOFFER message to which the client is responding. The client SHOULD use the parameters in the DHCPACK message for configuration.

客户端按以下来发送DHCPREQUEST消息：

Clients send DHCPREQUEST messages as follows:

1. 在SELECTING状态下生成的DHCPREQUEST：

o DHCPREQUEST generated during SELECTING state:

客户端在“server identifer”中插入选择的服务器的地址，“ciaddr”必须是0，“requested IP address”必须填充为选中的DHCPOFFER中的yiaddr值。注意客户端可以选择收集几个DHCPOFFER消息，然后选择“最好的”提议。客户端通过在DHCPREQUEST消息中标识提供的服务器来指出它的选择。如果客户端没有收到可接受的提议，客户端可以选择尝试另一个DHCPDISCOVER消息。因此，服务器可能不能收到特定的DHCPREQUEST，从中它们可以决定客户端是否接受了它的提议。因为在DHCPOFFER的基础上服务器没有执行任何网络地址的分配，服务器可以重新利用提议的网络地址来想要后继的请求。由于实现的细节，服务器不应该重新利用提议的地址，并且可以使用具体于实现的超时方式来决定什么时候重新利用提议的地址。

Client inserts the address of the selected server in ’server identifier’, ’ciaddr’ MUST be zero, ’requested IP address’ MUST be filled in with the yiaddr value from the chosen DHCPOFFER. Note that the client may choose to collect several DHCPOFFER messages and select the "best" offer. The client indicates its selection by identifying the offering server in the DHCPREQUEST message. If the client receives no acceptable offers, the client may choose to try another DHCPDISCOVER message. Therefore, the servers may not receive a specific DHCPREQUEST from which they can decide whether or not the client has accepted the offer. Because the servers have not committed any network address assignments on the basis of a DHCPOFFER, servers are free to reuse offered network addresses in response to subsequent requests. As an implementation detail, servers SHOULD NOT reuse offered addresses and may use an implementation-specific timeout mechanism to decide when to reuse an offered address.

1. 在INIT-REBOOT状态下生成的DHCPREQUEST：

o DHCPREQUEST generated during INIT-REBOOT state:

“server identifier”不可以被填充，“requested IP address”必须用客户端主张的它先前的地址填充。“ciaddr”必须是0。客户端在寻求验证先前分配，存储的配置。如果“requested IP address”是不正确的，或者在错误的网络，服务器应该发送DHCPNAK消息给客户端。通过检查“giaddr”，“requested IP address”选项的内容和查找数据库来决定在INIT-REBOOT状态的客户端是否在正确的网络。如果DHCP服务器发现客户端在错误的网络上（即，给“requested IP address”选项值申请的本地子网掩码或远端的子网掩码的结果（如果“giaddr”不是0）和现实不匹配），服务器应该给客户端发DHCPNAK消息。

’server identifier’ MUST NOT be filled in, ’requested IP address’ option MUST be filled in with client’s notion of its previously assigned address. ’ciaddr’ MUST be zero. The client is seeking to verify a previously allocated, cached configuration. Server SHOULD send a DHCPNAK message to the client if the ’requested IP address’ is incorrect, or is on the wrong network. Determining whether a client in the INIT-REBOOT state is on the correct network is done by examining the contents of ’giaddr’, the ’requested IP address’ option, and a database lookup. If the DHCP server detects that the client is on the wrong net (i.e., the result of applying the local subnet mask or remote subnet mask (if ’giaddr’ is not zero) to ’requested IP address’ option value doesn’t match reality), then the server SHOULD send a DHCPNAK message to the client.

如果网络是正确的，那么DHCP服务器应该检查客户端主张的IP地址是否正确。如果不正确，服务器应该给客户端发DHCPNAK消息。如果DHCP服务器没有这个客户端的记录，那么它必须保持安静，并且可以给网络管理员发出一个警告。这个行为对于保持在相同的线上的不通信的DHCP服务器和平共存是必要的。

If the network is correct, then the DHCP server should check if the client’s notion of its IP address is correct. If not, then the server SHOULD send a DHCPNAK message to the client. If the DHCP server has no record of this client, then it MUST remain silent, and MAY output a warning to the network administrator. This behavior is necessary for peaceful coexistence of non- communicating DHCP servers on the same wire.

如果DHCPREQUEST消息的“giaddr”是0x0，客户端和服务器是在相同的子网上。服务器必须广播DHCPNAK消息给0xffffffff广播地址因为客户端可能没有正确的网络地址或者子网掩码，而且客户端可能不能回答ARP请求。

If ’giaddr’ is 0x0 in the DHCPREQUEST message, the client is on the same subnet as the server. The server MUST broadcast the DHCPNAK message to the 0xffffffff broadcast address because the client may not have a correct network address or subnet mask, and the client may not be answering ARP requests.

如果DHCPREQUEST小的“giaddr”被设置，客户端在不同的子网。服务器必须在DHCPNAK中设置广播位，以便中继代理将DHCPNAK广播给客户端，因为客户端可能没有正确的网络地址或者子网掩码，而且客户端可能不能回答ARP请求。

If ’giaddr’ is set in the DHCPREQUEST message, the client is on a different subnet. The server MUST set the broadcast bit in the DHCPNAK, so that the relay agent will broadcast the DHCPNAK to the client, because the client may not have a correct network address or subnet mask, and the client may not be answering ARP requests.

1. 在RENEWING状态生成的DHCPREQUEST

o DHCPREQUEST generated during RENEWING state:

不可以填充“server identifier”，不可以填充“requested IP address”选项，“ciaddr”必须用客户端的IP地址填充。在这种情况下，客户端完全的被配置，并且试图延长它的租约。这个消息将被单播，所有在它的传输中没有中继代理参与。因为“giaddr”没有被填充，DHCP服务器将信任“ciaddr”中的值，并在回复客户端的时候使用它。客户端可以选择在T1之前重新申请或者延长它的租约。服务器可以选择不延长租约（由于网络管理员的政策决定），但不管怎样应该返回DHCPACK消息。

’server identifier’ MUST NOT be filled in, ’requested IP address’ option MUST NOT be filled in, ’ciaddr’ MUST be filled in with client’s IP address. In this situation, the client is completely configured, and is trying to extend its lease. This message will be unicast, so no relay agents will be involved in its transmission. Because ’giaddr’ is therefore not filled in, the DHCP server will trust the value in ’ciaddr’, and use it when replying to the client. A client MAY choose to renew or extend its lease prior to T1. The server may choose not to extend the lease (as a policy decision by the network administrator), but should return a DHCPACK message regardless.

1. 在REBINDING状态生成的DHCPREQUEST

o DHCPREQUEST generated during REBINDING state:

“server identifier”不可以填充，“requested IP address”选项不可以填充，“ciaddr”必须用客户端的IP地址填充。在这种情况下，客户端被完整的配置，并试图延长它的租约。这个消息必须广播到0xffffffff的IP广播地址。在回复DHCPREQUEST之前，DHCP服务器必须检查“ciaddr”的正确性。

’server identifier’ MUST NOT be filled in, ’requested IP address’ option MUST NOT be filled in, ’ciaddr’ MUST be filled in with client’s IP address. In this situation, the client is completely configured, and is trying to extend its lease. This message MUST be broadcast to the 0xffffffff IP broadcast address. The DHCP server SHOULD check ’ciaddr’ for correctness before replying to the DHCPREQUEST.

来自REBINDING客户端的DHCPREQUEST意味着调节有多个DHCP服务器的现场和维持多个服务器控制的租约之间的一致性的方式。只有在本地管理授权的情况下，DHCP服务器才可以延长客户端的租约。

The DHCPREQUEST from a REBINDING client is intended to accommodate sites that have multiple DHCP servers and a mechanism for maintaining consistency among leases managed by multiple servers. A DHCP server MAY extend a client’s lease only if it has local administrative authority to do so.

1. 1. 1. DHCPDECLINE message

如果服务器接收到DHCPDECLINE消息，客户端通过其它方式发现建议的网络地址已经被使用。服务器必须将这个网络地址标志为不可利用并且应该将可能的配置问题通知本地系统管理员。

If the server receives a DHCPDECLINE message, the client has discovered through some other means that the suggested network address is already in use. The server MUST mark the network address as not available and SHOULD notify the local system administrator of a possible configuration problem.

1. 1. 1. DHCPRELEASE message

接收到DHCPRELEASE消息的时候，服务器将这个网络地址标志为没有被分配。为了在响应来自客户端的后继的请求中重新利用，服务器应该保留客户端的初始化参数的记录。

Upon receipt of a DHCPRELEASE message, the server marks the network address as not allocated. The server SHOULD retain a record of the client’s initialization parameters for possible reuse in response to subsequent requests from the client.

1. 1. 1. DHCPINFORM message

服务器通过直接发送DHCPACK消息给DHCPINFORM消息的“ciaddr”域中给出的地址来响应DHCPINFORM消息。服务器不可以发送租约到期时间给客户端，并且不应该填充“yiaddr”。服务器在DHCPACK中包括4.3.1节定义的其它参数。

The server responds to a DHCPINFORM message by sending a DHCPACK message directly to the address given in the ’ciaddr’ field of the DHCPINFORM message. The server MUST NOT send a lease expiration time to the client and SHOULD NOT fill in ’yiaddr’. The server includes other parameters in the DHCPACK message as defined in section 4.3.1.

1. 1. 1. Client messages

表4详细描述了各种状态下来自客户端的消息之间的区别。

Table 4 details the differences between messages from clients in various states.

Table 4: Client messages from different states

1. 1. DHCP client behavior

图5给出了DHCP客户端的状态转换图。客户端可以接收来自服务器的下列消息：

Figure 5 gives a state-transition diagram for a DHCP client. A client can receive the following messages from a server:

1. DHCPOFFER
2. DHCPACK
3. DHCPNAK

DHCPINFORM消息没有在图5中显示。客户端只是发送DHCPINFORM并等待DHCPACK消息。一旦客户端已经选择了它的参数，它已经完成了配置过程。

The DHCPINFORM message is not shown in figure 5. A client simply sends the DHCPINFORM and waits for DHCPACK messages. Once the client has selected its parameters, it has completed the configuration process.

表5给出了DHCP消息中客户端使用的域和选项。这一节的剩余部分描述DHCP客户端对每个可能进来的消息的动作。下面部分的描述域先前3.1节描述的完整配置过程对应，后面部分的正文和3.2节描述的简短配置过程对应。

Table 5 gives the use of the fields and options in a DHCP message by a client. The remainder of this section describes the action of the DHCP client for each possible incoming message. The description in the following section corresponds to the full configuration procedure previously described in section 3.1, and the text in the subsequent section corresponds to the abbreviated configuration procedure described in section 3.2.

Figure 5: State-transition diagram for DHCP clients

1. 1. 1. Initialization and allocation of network address

客户端从INIT状态开始并构造DHCPDISCOVER消息。客户端应该等待1到10秒之间的随机时间，使客户端在启动时去同步DHCP的使用。客户端设置“ciaddr”为0x00000000。通过包括“parameter request list”选项，客户端可以请求特定的参数。通过包括“requested IP address”和“IP address lease time”选项，客户端可以建议网络地址和/或者租期。客户端必须在“chaddr”域中包括它的硬件地址，如果对于DHCP回复消息的传递是必须的。客户端可以在“client identifier”选项中包括不同的唯一的标识符，象4.2节中讨论的。如果客户端在DHCPDISCOVER消息中包括了请求参数的列表，它必须在所有后继的消息中包括那个列表。

The client begins in INIT state and forms a DHCPDISCOVER message. The client SHOULD wait a random time between one and ten seconds to desynchronize the use of DHCP at startup. The client sets ’ciaddr’ to 0x00000000. The client MAY request specific parameters by including the ’parameter request list’ option. The client MAY suggest a network address and/or lease time by including the ’requested IP address’ and ’IP address lease time’ options. The client MUST include its hardware address in the ’chaddr’ field, if necessary for delivery of DHCP reply messages. The client MAY include a different unique identifier in the ’client identifier’ option, as discussed in section 4.2. If the client included a list of requested parameters in a DHCPDISCOVER message, it MUST include that list in all subsequent messages.

客户端产生并记录随机的处理标识符并将这个标识符插入到“xid”域中。客户端记录它的本地时间作为以后计算租约到期使用。然后客户端在本地硬件广播地址上广播DHCPDISCOVER到0xffffffff的IP广播地址和“DHCP server”的UDP端口。

The client generates and records a random transaction identifier and inserts that identifier into the ’xid’ field. The client records its own local time for later use in computing the lease expiration. The client then broadcasts the DHCPDISCOVER on the local hardware broadcast address to the 0xffffffff IP broadcast address and ’DHCP server’ UDP port.

如果到达的DHCPOFFER消息的“xid”和最近的DHCPDISCOVER消息不匹配，DHCPOFFER消息必须被安静的丢弃。任何到达的DHCPACK消息必须被安静的丢弃。

If the ’xid’ of an arriving DHCPOFFER message does not match the ’xid’ of the most recent DHCPDISCOVER message, the DHCPOFFER message must be silently discarded. Any arriving DHCPACK messages must be silently discarded.

客户端在一段时间内收集DHCPOFFER消息，从到来的（可能很多）DHCPOFFER消息中选择一个DHCPOFFER消息（例如，第一个DHCPOFFER消息或者先前使用的服务器的DHCPOFFER消息），然后从DHCPOFFER消息的“server identifier”选项中抽取服务器的地址。客户端收集消息的时间和选择DHCPOFFER的方式取决于实现。

The client collects DHCPOFFER messages over a period of time, selects one DHCPOFFER message from the (possibly many) incoming DHCPOFFER messages (e.g., the first DHCPOFFER message or the DHCPOFFER message from the previously used server) and extracts the server address from the ’server identifier’ option in the DHCPOFFER message. The time over which the client collects messages and the mechanism used to select one DHCPOFFER are implementation dependent.

Table 5: Fields and options used by DHCP clients

如果参数可接受，客户端记录提供来自“server identifier”域的参数的服务器的地址并给“server identifier”域中的地址发送DHCPREQUEST广播消息。一旦从服务器来的DHCPACK消息到达了，客户端被初始化了并移到BOUND状态。DHCPREQUEST消息包含和DHCPOFFER消息一样的“xid”。客户端将最初的请求发出的时间和来自DHCPACK消息的租约的持续时间的和记录为租约到期的时间。客户端应该对建议的地址执行一次检查，以确保那个地址不在使用。例如，如果客户端所在的网络支持ARP，客户端可以对建议的请求发一个ARP请求。当对建议的地址广播ARP请求的时候，客户端必须将它自己的硬件地址填充为发送者的硬件地址，和0作为发送者的IP地址，以避免使相同子网上的其它主机的ARP存储器混乱。如果网络地址在使用，客户端必须发送一个DHCPDECLINE消息给服务器。客户端应该广播一个ARP应答来宣布客户端的新IP地址，并清除客户端子网上的主机中过时的ARP存储器条目。

If the parameters are acceptable, the client records the address of the server that supplied the parameters from the ’server identifier’ field and sends that address in the ’server identifier’ field of a DHCPREQUEST broadcast message. Once the DHCPACK message from the server arrives, the client is initialized and moves to BOUND state. The DHCPREQUEST message contains the same ’xid’ as the DHCPOFFER message. The client records the lease expiration time as the sum of the time at which the original request was sent and the duration of the lease from the DHCPACK message. The client SHOULD perform a check on the suggested address to ensure that the address is not already in use. For example, if the client is on a network that supports ARP, the client may issue an ARP request for the suggested request. When broadcasting an ARP request for the suggested address, the client must fill in its own hardware address as the sender’s hardware address, and 0 as the sender’s IP address, to avoid confusing ARP caches in other hosts on the same subnet. If the network address appears to be in use, the client MUST send a DHCPDECLINE message to the server. The client SHOULD broadcast an ARP reply to announce the client’s new IP address and clear any outdated ARP cache entries in hosts on the client’s subnet.

1. 1. 1. Initialization with known network address

客户端从INIT-REBOOT状态开始并发送DHCPREQUEST消息。客户端必须在DHCPREQUEST消息的“requested IP address”选项中插入它知道的网络地址。通过包括“parameter request list”选项，客户端可以请求特定的配置参数。客户端产生并记录随机的处理标识符，并将那个标识符插入到“xid”域中。客户端记录它自己的本地时间，作为将来计算租约到期使用。客户端不可以在DHCPREQUEST消息中包含“server identifier”。然后客户端在本地硬件广播地址上广播DHCPREQUEST给“DHCP server”的UDP端口。

The client begins in INIT-REBOOT state and sends a DHCPREQUEST message. The client MUST insert its known network address as a ’requested IP address’ option in the DHCPREQUEST message. The client may request specific configuration parameters by including the ’parameter request list’ option. The client generates and records a random transaction identifier and inserts that identifier into the ’xid’ field. The client records its own local time for later use in computing the lease expiration. The client MUST NOT include a ’server identifier’ in the DHCPREQUEST message. The client then broadcasts the DHCPREQUEST on the local hardware broadcast address to the ’DHCP server’ UDP port.

一旦从任何服务器到来的DHCPACK消息的“xid”域与客户端DHCPREQUEST消息中的匹配，客户端被初始化并移到BOUND状态。客户端将DHCPREQUEST请求发出的时间和来自DHCPACK消息的租约的持续时间的和记录为租约到期的时间。

Once a DHCPACK message with an ’xid’ field matching that in the client’s DHCPREQUEST message arrives from any server, the client is initialized and moves to BOUND state. The client records the lease expiration time as the sum of the time at which the DHCPREQUEST message was sent and the duration of the lease from the DHCPACK message.

1. 1. 1. Initialization with an externally assigned network address

客户端发送DHCPINFORM消息。通过包括“parameter request list”选项，客户端可以请求特定的配置参数。客户端产生并记录随机的处理标识符，并将那个标识符插入到“xid”域中。客户端将它自己的网络地址放在“ciaddr”域中。客户端不应该请求租约时间参数。

The client sends a DHCPINFORM message. The client may request specific configuration parameters by including the ’parameter request list’ option. The client generates and records a random transaction identifier and inserts that identifier into the ’xid’ field. The client places its own network address in the ’ciaddr’ field. The client SHOULD NOT request lease time parameters.

如果它知道服务器的地址，客户端单播DHCPINFORM给DHCP服务器，否则它广播消息给有限的（全1）广播地址。DHCPINFORM消息必须被引导到“DHCP server”的UDP端口。

The client then unicasts the DHCPINFORM to the DHCP server if it knows the server’s address, otherwise it broadcasts the message to the limited (all 1s) broadcast address. DHCPINFORM messages MUST be directed to the ’DHCP server’ UDP port.

一旦从任何服务器到达的DHCPACK消息的“xid”域与客户端的DHCPINFORM消息中的匹配，客户端被初始化。

Once a DHCPACK message with an ’xid’ field matching that in the client’s DHCPINFORM message arrives from any server, the client is initialized.

如果在一段合理的时间内（如果使用4.1节中的超时，60秒和4次尝试）客户端没有收到DHCPACK，那么它应该显示一条消息将问题通知用户，并应该按照附录A使用合适的默认开始网络进程。

If the client does not receive a DHCPACK within a reasonable period of time (60 seconds or 4 tries if using timeout suggested in section 4.1), then it SHOULD display a message informing the user of the problem, and then SHOULD begin network processing using suitable defaults as per Appendix A.

1. 1. 1. Use of broadcast and unicast

DHCP客户端广播DHCPDISCOVER, DHCPREQUEST和DHCPINFORM消息，除非客户端知道DHCP服务器的地址。客户端单播DHCPRELEASE消息给服务器。因为客户端是拒绝使用服务器提供的IP地址，客户端广播DHCPDECLINE消息。

The DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and DHCPINFORM messages, unless the client knows the address of a DHCP server. The client unicasts DHCPRELEASE messages to the server. Because the client is declining the use of the IP address supplied by the server, the client broadcasts DHCPDECLINE messages.

当DHCP客户端在INIT或者REBOOTING状态的时候知道DHCP服务器的地址，客户端可以在DHCPDISCOVER或者DHCPREQUEST中使用那个地址，而不是IP广播地址。客户端也可以使用单播发送DHCPINFORM消息给知道的DHCP服务器。如果客户端没有收到发送给已知DHCP服务器的DHCP消息的应答，DHCP客户端反过来使用IP广播地址。

When the DHCP client knows the address of a DHCP server, in either INIT or REBOOTING state, the client may use that address in the DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address. The client may also use unicast to send DHCPINFORM messages to a known DHCP server. If the client receives no response to DHCP messages sent to the IP address of a known DHCP server, the DHCP client reverts to using the IP broadcast address.

1. 1. 1. Reacquisition and expiration

客户端维持两个时间，T1和T2，说明了客户端尝试延长它的网络地址的租约的时间。T1是客户端进入RENEWING状态和联系最初发布客户端的网络地址的服务器的时间。T2是客户端进入REBINDING状态和尝试联系任何服务器的时间。T1必须比T2早，反过来，必须比客户端租约到期的时间早。

The client maintains two times, T1 and T2, that specify the times at which the client tries to extend its lease on its network address. T1 is the time at which the client enters the RENEWING state and attempts to contact the server that originally issued the client’s network address. T2 is the time at which the client enters the REBINDING state and attempts to contact any server. T1 MUST be earlier than T2, which, in turn, MUST be earlier than the time at which the client’s lease will expire.

为了避免同步时钟的需要，T1和T2在选项中表示为相对时间。

To avoid the need for synchronized clocks, T1 and T2 are expressed in options as relative times [2].

在T1的时候客户端一旦RENEWING状态并发送（通过单播）DHCPREQUEST消息给服务器要求延长它的租约。客户端将DHCPREQUEST中的“ciaddr”域设置为它当前的网络地址。为了计算租约的到期时间，客户端在发送的DHCPREQUEST消息中记录本地时间。客户端不可以在DHCPREQUEST消息中包括“server identifier”。

At time T1 the client moves to RENEWING state and sends (via unicast) a DHCPREQUEST message to the server to extend its lease. The client sets the ’ciaddr’ field in the DHCPREQUEST to its current network address. The client records the local time at which the DHCPREQUEST message is sent for computation of the lease expiration time. The client MUST NOT include a ’server identifier’ in the DHCPREQUEST message.

任何到达的不和客户端的DHCPREQUEST消息的“xid”匹配的DHCPACK消息被安静的丢弃。当客户端收到来自服务器的DHCPACK，客户端将DHCPREQUEST请求发出的时间和来自DHCPACK消息的租约的持续时间的和计算为租约到期的时间。客户端已经成功的重新获取了它的网络地址，返回BOUND状态并可以继续网络进程。

Any DHCPACK messages that arrive with an ’xid’ that does not match the ’xid’ of the client’s DHCPREQUEST message are silently discarded. When the client receives a DHCPACK from the server, the client computes the lease expiration time as the sum of the time at which the client sent the DHCPREQUEST message and the duration of the lease in the DHCPACK message. The client has successfully reacquired its network address, returns to BOUND state and may continue network processing.

如果在时间T2之前没有DHCPACK到达，客户端移到REBINDING状态并发送（通过广播）DHCPREQUEST消息来延长它的租约。客户端在DHCPREQUEST中设置“ciaddr”为它当前的网络地址。客户端不可以在DHCPREQUEST消息中包括“server identifier”。

If no DHCPACK arrives before time T2, the client moves to REBINDING state and sends (via broadcast) a DHCPREQUEST message to extend its lease. The client sets the ’ciaddr’ field in the DHCPREQUEST to its current network address. The client MUST NOT include a ’server identifier’ in the DHCPREQUEST message.

服务器通过选项可以配置时间T1和T2。T1的默认值是（0.5×租期）。T2的默认值是（0.875×租期）。时间T1和T2应该选择为一个固定值周围的随机值，以避免和客户端重新取得同步。

Times T1 and T2 are configurable by the server through options. T1 defaults to (0.5 * duration_of_lease). T2 defaults to (0.875 * duration_of_lease). Times T1 and T2 SHOULD be chosen with some random "fuzz" around a fixed value, to avoid synchronization of client reacquisition.

客户端可以在T1之前重新获取或者延长它的租约。服务器可以根据网络管理员设定的政策选择延长客户端的租约。服务器应该返回T1和T2，并且考虑到剩余的租约，应该调整它们的初始值。

A client MAY choose to renew or extend its lease prior to T1. The serve r MAY choose to extend the client’s lease according to policy set by the network administrator. The server SHOULD return T1 and T2, and their values SHOULD be adjusted from their original values to take account of the time remaining on the lease.

在RENEWING和REBINDING状态，如果客户端没有接收到它的DHCPREQUEST消息的回应，在重新转发DHCPREQUEST消息之前，客户端应该等待二分之一的剩余时间直到T2（在RENEWING状态）或者剩余租期的二分之一时间（在REBINDING状态）,直到60秒的最小值。

In both RENEWING and REBINDING states, if the client receives no response to its DHCPREQUEST message, the client SHOULD wait one-half of the remaining time until T2 (in RENEWING state) and one-half of the remaining lease time (in REBINDING state), down to a minimum of 60 seconds, before retransmitting the DHCPREQUEST message.

如果在客户端收到DHCPACK之前租约到期了，客户端移到INIT状态，必须立即停止任何其它的网络进程并请求网络初始化参数，如果客户端没有被初始化。如果客户端收到它先前的网络地址的DHCPACK分配，客户端应该继续网络进程。如果客户端被给予了新的网络地址，它不可以继续使用先前的网络地址，并应该将问题通知给本地用户。

If the lease expires before the client receives a DHCPACK, the client moves to INIT state, MUST immediately stop any other network processing and requests network initialization parameters as if the client were uninitialized. If the client then receives a DHCPACK allocating that client its previous network address, the client SHOULD continue network processing. If the client is given a new network address, it MUST NOT continue using the previous network address and SHOULD notify the local users of the problem.

1. 1. 1. DHCPRELEASE

如果客户端不再要求使用分配给它的网络地址（例如，客户端正常关机了），客户端发送DHCPRELEASE消息给服务器。注意DHCP的正确操作不依赖于DHCPRELEASE消息的传输。

If the client no longer requires use of its assigned network address (e.g., the client is gracefully shut down), the client sends a DHCPRELEASE message to the server. Note that the correct operation of DHCP does not depend on the transmission of DHCPRELEASE messages.

1. Acknowledgments

1. References

1. Security Considerations