DHCP动态主机配置协议rfc2131翻译

https://tools.ietf.org/html/rfc2131
动态主机配置协议
本备忘录的状态
      本文档为以下内容指定了Internet标准跟踪协议：互联网社区，并要求讨论和提出建议改进。请参考最新版的“互联网标准化状态的官方协议标准”（STD1）协议的状态。该备忘录的分发是无限的。
摘要
      动态主机配置协议（DHCP）提供了一个框架,用于将配置信息传递到TCPIP网络上的主机。DHCP基于引导协议（BOOTP），添加了自动分配可重用网络地址的功能以及其他配置选项。DHCP捕获行为BOOTP中继代理，和DHCP参与者可以互操作与BOOTP参与者。
1.简介
       动态主机配置协议（DHCP）向Internet主机提供配置参数。DHCP由两个部分组成：一种用于将特定主机的配置参数从DHCP服务器传送到主机的协议，以及一种将网络地址分配给主机的机制。
       dhcp建立在客户机-服务器模型上，在该模型中，指定的dhcp服务器主机分配网络地址并将配置参数传递给动态配置的主机。在本文档的其余部分中，“服务器”一词是指通过dhcp提供初始化参数的主机，“客户端”一词是指从dhcp服务器请求初始化参数的主机。
       除非由系统管理员明确配置，否则主机不应充当DHCP服务器。如果允许随机主机响应dhcp请求，将妨碍本网络中不同的硬件和协议实现可靠的操作。例如，IP需要在协议实现（工具）软件中设置许多参数。因为IP可以在许多不同类型的网络硬件上使用，所以不能猜测或假设这些参数的值具有正确的默认值。此外，已分配地址分配方案依赖于轮询/防御机制来发现已使用的地址。IP主机并不总能保护其网络地址，因此像这一个已分配地址，发布机无法保证避免分配重复的网络地址。
       DHCP支持三种IP地址分配机制：在“自动分配”中，dhcp为客户端分配一个永久ip地址；在“动态分配”中，dhcp在一段有限的时间内为客户端分配一个ip地址（或直到客户端明确放弃地址）；在“手动分配”中，客户端的IP地址由网络管理员分配，而DHCP仅用于将分配的地址传递给客户端。根据网络管理员的策略，特定网络将使用这些机制中的一个或多个。
         动态分配是三种机制中唯一允许自动重用被分配地址的客户端不再需要的地址的机制。因此，动态分配对于将地址分配给仅暂时连接到网络的客户机或对于在不需要永久ip地址的客户机组之间共享有限的ip地址池特别有用。动态分配也可以是将ip地址分配给永久连接到ip地址足够稀少的网络的新客户机的好选择，当旧客户机退役时，回收它们非常重要。手动分配允许使用dhcp来消除在需要在dhcp机制之外管理ip地址分配的环境中（无论出于何种原因）使用ip地址手动配置主机的易出错过程。
         动态分配是三种机制中唯一允许自动重用被分配地址的客户端不再需要的地址的机制。因此，动态分配对于将地址分配给仅暂时连接到网络的客户机或对于在不需要永久ip地址的客户机组之间共享有限的ip地址池特别有用。动态分配也可以是将ip地址分配给永久连接到ip地址少量的网络的新客户机的好选择，当旧客户机退出网络时，回收它们非常重要。在管理ip地址分配的环境中（无论出于何种原因）手动分配允许使用dhcp来消除在需要在dhcp机制之外，手动配置ip地址主机的容易出错过程。
         dhcp消息的格式基于bootp消息的格式，以捕获bootp规范中描述的bootp中继代理行为，并允许现有bootp客户端与dhcp服务器的互操作性。使用bootp中继代理可以有效消除在每个物理网络上都有dhcp服务器。
         对于新初始化的客户端，并非所有这些参数都是必需的。客户机和服务器可以协商只传输客户机要求的或特定于特定子网的参数。
         dhcp允许但不要求配置与ip协议不直接相关的客户端参数。DHCP也不处理新配置的客户端在域中的注册
         DHCP不用于配置路由器。
         在本文件中，用于定义特定需求重要性的词语均加粗。这些话是：
            “必须”
            该词或形容词“必需”是指该项目是本规范的绝对要求。
            “不得”
            这句话的意思是这个项目是绝对禁止本规范。
            “应该”
            这个词或形容词“推荐”的意思是，在特定情况下有正当理由可以忽略这一项，但在选择不同的情景之前，应理解其全部含义并仔细权衡情景。
            “不应该”
            这句话的意思是，当所列行为是可接受的，甚至是有用的，在特定情况下可能存在正当理由，但是，在实现用这个标签描述的任何行为之前，应该理解其全部含义并仔细权衡案例。
            “可以”
            这个词或形容词“可选”意味着这个项目是真正可选的。 

         本文件使用以下术语：
            "DHCP client"
            DHCP客户端是使用DHCP获取配置参数（如网络地址）的Internet主机。
            "DHCP server"
            DHCP服务器是向DHCP客户端返回配置参数的Internet主机。
            BOOTP relay agent
            bootp中继代理或中继代理是在dhcp客户端和dhcp服务器之间传递dhcp消息的internet主机或路由器。dhcp被设计为使用bootp协议规范中指定的相同中继代理行为。
            binding
            绑定是配置参数的集合，至少包括与DHCP客户端关联或“绑定到”DHCP客户端的IP地址。绑定由DHCP服务器管理。
         给出了dhcp的一般设计目标。         
            dhcp应该是一种机制，而不是策略。DHCP必须允许本地系统管理员在需要时控制配置参数；例如，本地系统管理员应该能够在需要时强制执行有关分配和访问本地资源的本地策略。
            客户端不需要手动配置。每个客户机都应该能够在不需要用户干预的情况下发现适当的本地配置参数，并将这些参数合并到自己的配置中。
            网络中不需要为单个客户端进行手动配置。在正常情况下，网络管理员不必输入任何单一客户端配置参数。
            DHCP不需要在每个子网上的都有服务器。为了实现规模和经济性，dhcp必须跨路由器或通过bootp中继代理进行干预。
            DHCP客户端必须准备好接收对配置参数请求的多个响应。一些安装可能包括多个重叠的dhcp服务器，以提高可靠性和性能。
            dhcp必须与静态配置的非参与主机和现有的网络协议实现共存。
            dhcp必须与rfc 951和rfc 1542所描述的bootp中继代理行为互操作
            DHCP必须为现有的BOOTP客户端提供服务。
         给出了特定于网络层参数传输的设计目标。DHCP必须：
            保证任何特定的网络地址不会被多个dhcp客户端使用
            在dhcp客户端重新启动时保留dhcp客户端配置。在可能的情况下，dhcp客户端响应每个请求应该使用 被分配相同的配置参数（例如，网络地址）
            在服务器重新启动时保留dhcp客户端配置，并且在可能的情况下，尽管dhcp机制重新启动，仍应为dhcp客户端分配相同的配置参数 
            允许自动将配置参数分配给新客户机，以避免手动配置新客户机
            支持将配置参数固定或永久分配给特定客户端。
2。协议摘要
         从客户端的角度来看，dhcp是bootp机制的扩展。此行为允许现有的bootp客户端与dhcp服务器互操作，不需要对客户端的初始化软件进行任何更改。RFC1542[2]详细说明了BOOTP与DHCP客户端和服务器之间的交互[9]。有一些新的可选事务优化了dhcp客户端和服务器之间的交互，如第3节所述，图1给出了dhcp消息的格式，表1描述了dhcp消息中的每个字段。括号中的数字表示每个字段的大小（八位字节）。图中给出的字段的名称将在整个文档中用于引用dhcp消息中的字段。
         dhcp和bootp有两个主要区别。首先，dhcp定义了一些机制，通过这些机制可以为客户端分配一个有限租约的网络地址，从而允许将网络地址串行重新分配给不同的客户端。其次，dhcp为客户端提供了一种机制，使其能够获取运行所需的所有ip配置参数。 
         dhcp在术语上引入了一个小的变化，旨在澄清其中一个字段的含义。bootp中的“vendor extensions”字段被重新命名为dhcp中的“options”字段。类似地，在bootp“vendor extensions”字段中使用的标记数据项（以前称为“vendor extensions”）现在只被称为“options”。
 

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     op (1)    |   htype (1)   |   hlen (1)    |   hops (1)    |
   |报文的操作类型 |客的MAC地址类型|客的MAC地址长度|报文经中继数目 |
   +---------------+---------------+---------------+---------------+
   |                            xid (4)                            |
   |客户端通过DHCP Discover报文发起一次IP地址请求时选择的随机数        |
   +-------------------------------+-------------------------------+
   |           secs (2)            |           flags (2)           |
   |续约过程开始到现在所消耗的时间 |标识DHCP服务器应答报文是采用单播还是广播发送
   +-------------------------------+-------------------------------+
   |                          ciaddr  (4)                          |
   |                       DHCP客户端的IP地址                       |
   +---------------------------------------------------------------+
   |                          yiaddr  (4)                          |
   |                  DHCP服务器分配给客户端的IP地址                 |
   +---------------------------------------------------------------+
   |                          siaddr  (4)                          |
   |      下一个为DHCP客户端分配IP地址等信息的DHCP服务器IP地址         |
   +---------------------------------------------------------------+
   |                          giaddr  (4)                          |
   |      DHCP客户端发出请求报文后经过的第一个DHCP中继的IP地址         |
   +---------------------------------------------------------------+
   |                          chaddr  (16)                         |
   |                       DHCP客户端的MAC地址                      |
   +---------------------------------------------------------------+
   |                          sname   (64)                         |
   |             为DHCP客户端分配IP地址的DHCP服务器名称               |
   +---------------------------------------------------------------+
   |                          file    (128)                        |
   |     DHCP服务器为DHCP客户端指定的启动配置文件名称及路径信息        |
   +---------------------------------------------------------------+
   |                          options (variable)                   |
   +---------------------------------------------------------------+

                                                           图 1:  DHCP消息的格式

                       

Field      DHCPOFFER            DHCPACK             DHCPNAK
-----      ---------            -------             -------
'op'       BOOTREPLY            BOOTREPLY           BOOTREPLY
'htype'    (From "Assigned Numbers" RFC)
'hlen'     (Hardware address length in octets)
'hops'     0                    0                   0
'xid'      'xid' from client    'xid' from client   'xid' from client
           DHCPDISCOVER         DHCPREQUEST         DHCPREQUEST
           message              message             message
'secs'     0                    0                   0
'ciaddr'   0                    'ciaddr' from       0
                                DHCPREQUEST or 0
'yiaddr'   IP address offered   IP address          0
           to client            assigned to client
'siaddr'   IP address of next   IP address of next  0
           bootstrap server     bootstrap server
'flags'    'flags' from         'flags' from        'flags' from
           client DHCPDISCOVER  client DHCPREQUEST  client DHCPREQUEST
           message              message             message
'giaddr'   'giaddr' from        'giaddr' from       'giaddr' from
           client DHCPDISCOVER  client DHCPREQUEST  client DHCPREQUEST
           message              message             message
'chaddr'   'chaddr' from        'chaddr' from       'chaddr' from
           client DHCPDISCOVER  client DHCPREQUEST  client DHCPREQUEST
           message              message             message
'sname'    Server host name     Server host name    (unused)
           or options           or options
'file'     Client boot file     Client boot file    (unused)
           name or options      name or options
'options'  options              options

Option                    DHCPOFFER    DHCPACK            DHCPNAK
------                    ---------    -------            -------
Requested IP address      MUST NOT     MUST NOT           MUST NOT
IP address lease time     MUST         MUST (DHCPREQUEST) MUST NOT
                                       MUST NOT (DHCPINFORM)
Use 'file'/'sname' fields MAY          MAY                MUST NOT
DHCP message type         DHCPOFFER    DHCPACK            DHCPNAK
Parameter request list    MUST NOT     MUST NOT           MUST NOT
Message                   SHOULD       SHOULD             SHOULD
Client identifier         MUST NOT     MUST NOT           MAY
Vendor class identifier   MAY          MAY                MAY
Server identifier         MUST         MUST               MUST
Maximum message size      MUST NOT     MUST NOT           MUST NOT
All others                MAY          MAY                MUST NOT

           Table 3:  Fields and options used by DHCP servers
           
 --------                               -------
|        | +-------------------------->|       |<-------------------+
| INIT-  | |     +-------------------->| INIT  |                    |
| REBOOT |DHCPNAK/         +---------->|       |<---+               |
|        |Restart|         |            -------     |               |
 --------  |  DHCPNAK/     |               |                        |
    |      Discard offer   |      -/Send DHCPDISCOVER               |
-/Send DHCPREQUEST         |               |                        |
    |      |     |      DHCPACK            v        |               |
 -----------     |   (not accept.)/   -----------   |               |
|           |    |  Send DHCPDECLINE |           |                  |
| REBOOTING |    |         |         | SELECTING |<----+            |
|           |    |        /          |           |     |DHCPOFFER/  |
 -----------     |       /            -----------   |  |Collect     |
    |            |      /                  |   |       |  replies   |
DHCPACK/         |     /  +----------------+   +-------+            |
Record lease, set|    |   v   Select offer/                         |
timers T1, T2   ------------  send DHCPREQUEST      |               |
    |   +----->|            |             DHCPNAK, Lease expired/   |
    |   |      | REQUESTING |                  Halt network         |
    DHCPOFFER/ |            |                       |               |
    Discard     ------------                        |               |
    |   |        |        |                   -----------           |
    |   +--------+     DHCPACK/              |           |          |
    |              Record lease, set    -----| REBINDING |          |
    |                timers T1, T2     /     |           |          |
    |                     |        DHCPACK/   -----------           |
    |                     v     Record lease, set   ^               |
    +----------------> -------      /timers T1,T2   |               |
               +----->|       |<---+                |               |
               |      | BOUND |<---+                |               |
  DHCPOFFER, DHCPACK, |       |    |            T2 expires/   DHCPNAK/
   DHCPNAK/Discard     -------     |             Broadcast  Halt network
               |       | |         |            DHCPREQUEST         |
               +-------+ |        DHCPACK/          |               |
                    T1 expires/   Record lease, set |               |
                 Send DHCPREQUEST timers T1, T2     |               |
                 to leasing server |                |               |
                         |   ----------             |               |
                         |  |          |------------+               |
                         +->| RENEWING |                            |
                            |          |----------------------------+
                             ----------
          Figure 5:  State-transition diagram for DHCP clients

         DHCP定义了一个新的“客户端标识符”选项，用于将已明确的客户端标识符传递给DHCP服务器。此更改消除了bootp消息中“chaddr”字段的重载，其中“chaddr”既用作发送bootp回复消息的硬件地址，也用作客户端标识符。“客户端标识符”是一个不透明的密钥，不能由服务器解释；例如，“客户端标识符”可以包含与“chaddr”字段内容相同的硬件地址，也可以包含其他类型的标识符，例如dns名称。DHCP客户端选择的“客户端标识符”必须是该客户端所连接的子网中唯一的。如果客户端在一条消息中使用“客户端标识符”，则它必须在所有后续消息中使用相同的标识符，以确保所有服务器都正确地标识该客户端。
         dhcp将“siaddr”字段解释为在下一步客户端引导进程的中使用的服务器地址。如果DHCP服务器准备提供下一个引导服务（例如，传递操作系统可执行映像），则它可以在“siaddr”字段中返回自己的地址。DHCP服务器总是在“服务器标识符”选项中返回自己的地址。
  字段       字节            描述
 -----      ------       -----------
  op           1          消息操作代码/消息类型。 1=引导请求，2=引导回复
 htype         1          硬件地址类型，见“分配号码”RFC中的ARP部分；例如，“1”=10MB以太网。
 hlen          1          硬件地址长度（例如，“6”为10MB以太网）。
 hops          1          客户端设置为零，中继代理在通过中继代理时可以选择使用。
 xid           4          业务ID，由客户端选择的一个随机数，客户端和服务器使用它在客户端和服务器之间关联消息和响应。
 secs          2          由客户端填写，自客户端开始地址获取或续订过程以来经过的秒数。
 flags         2          标志（见图2）。
 ciaddr        4          客户端IP地址；仅当客户端处于绑定、续订或重新绑定状态并且可以响应ARP请求时填写。
 yiaddr        4          “你的”（客户端）IP地址。
 siaddr        4          引导中使用的下一个服务器的IP地址；            在dhcpoffer、dhcpack由服务器返回。
 giaddr        4           中继代理IP地址，用于引导通过中继代理。
 chaddr       16           客户端硬件地址。
 sname        64           选择的服务器主机名, null terminated string最后一个字节用0x00填充
 options     var           可选参数字段。有关已定义选项的列表，请参见选项文档。
------------------------------------------------------------------------------------------
          表1:DHCP消息中字段的描述

         “选项”字段现在是可变长度。DHCP客户端必须接收“选项”字段长度至少为312个字节的DHCP消息。此要求意味着DHCP客户端必须准备好接收多达576个字节的消息，IP主机必须准备好接受的最小IP数据报大小[3]。DHCP客户端可以通过“最大DHCP消息大小”选项协商使用较大的DHCP消息。选项字段可以进一步扩展到“file ”和“sname”字段。
         对于使用dhcp进行初始配置的客户机（在客户机的tcp/ip软件完全配置之前），dhcp要求创造性地使用客户机的tcp/ip软件和自由解释rfc 1122。在配置IP地址之前，TCP/IP软件应接受并转发到IP层传送到客户端硬件地址的任何IP数据包；在配置TCP/IP软件之前，DHCP服务器和BOOTP中继代理可能无法将DHCP消息传送到无法接受硬件单播数据报的客户端。
         为了在配置TCP/IP软件之前解决某些无法接受IP单播数据报的客户端，DHCP使用'flags'字段[21]。最左边的位被定义为广播（b）标志。本文件第4.1节讨论了该标志的语义。标记字段的剩余位保留供将来使用。客户端必须将它们设置为零，服务器和中继代理必须忽略它们。图2给出了“flags”字段的格式。           

                                    1 1 1 1 1 1
                0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |B|             MBZ             |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                B:  BROADCAST flag

                MBZ:  必须为零（保留供将来使用）

                     图2：“flags”字段的格式

         配置参数存储库
              dhcp提供的第一个服务是为网络客户端提供网络参数的持久存储。dhcp持久存储的模型是，dhcp服务为每个客户端存储一个密钥值条目，其中密钥是一些唯一的标识符（例如，ip子网号和子网内的唯一标识符），并且该值包含客户端的配置参数。
              例如，密钥可能是对（IP子网号，硬件地址）（注意桥接网络中，“硬件地址”应该按硬件类型键入，以适应混合介质中位排序问题可能导致的硬件地址重复）允许在不同子网上串行或并发地重用硬件地址，以及可能不是全局唯一的硬件地址。另外，密钥可能是对（IP子网号、主机名），允许服务器智能地将参数分配给已移动到其他子网或已更改硬件地址的DHCP客户端（可能是因为网络接口失败并被替换）。协议定义密钥为（IP子网号、硬件地址），除非客户端使用“客户端标识符”选项显式提供标识符。客户端可以查询DHCP服务以检索其配置参数。配置参数存储库的客户机接口由请求配置参数的协议消息和承载配置参数的服务器的响应组成。

         网络地址的动态分配
              dhcp提供的第二个服务是将临时或永久网络（ip）地址分配给客户端。动态分配网络地址的基本机制很简单：客户端请求在一段时间内使用地址。分配机制（dhcp服务器的集合）保证在请求的时间内不重新分配该地址，并在每次客户端请求地址时尝试返回相同的网络地址。在本文档中，将网络地址分配给客户端的时间段称为“租约”[11]。客户可以通过后续请求延长其租约。当客户机不再需要地址时，客户机可能会发出消息将地址释放回服务器。客户可以通过要求无限期租赁来要求永久性转让。即使在分配“永久”地址时，服务器也可以选择发出长而非无限的租约，以允许检测客户机已退出的事实。
              在某些环境中，由于可用地址用尽，需要重新分配网络地址。在这种环境中，分配机制将重用租约已过期的地址。服务器应该使用配置信息存储库中可用的任何信息来选择要重用的地址。例如，服务器可以选择最近分配的最少地址。作为一致性检查，分配服务器应在分配地址（例如，使用icmp echo请求）之前探测重用的地址，而客户端应探测新接收的地址（例如，使用arp）。
3客户机-服务器协议
         dhcp使用rfc 951中定义的bootp消息格式，如表1和图1所示。从客户端发送到服务器的每个dhcp消息的“op”字段都包含bootrequest。bootpreply用于从服务器发送到客户端的每个dhcp消息的“op”字段。
         dhcp使用rfc 951中定义的bootp消息格式，如表1和图1所示。从客户端发送到服务器的每个dhcp消息的“op”字段都包含bootrequest。bootpreply用于从服务器发送到客户端的每个dhcp消息的“op”字段。
         dhcp消息的“options”字段的前四个字节分别包含（十进制）值99、130、83和99（这是rfc 1497[17]中定义的相同的magic cookie[与BOOTP兼容,]）。“options”字段的其余部分由一个名为“options”的标记参数列表组成。RFC1497中列出的所有“供应商扩展”也是DHCP选项。rfc 1533给出了定义用于dhcp的完整选项集。
         到目前为止，已经定义了几个选项。每个dhcp消息中都必须包含一个特定的选项-dhcp消息类型“选项。此选项定义DHCP消息的“类型”。根据DHCP消息类型，可能允许、需要或不允许其他选项。
         在本文档中，包含“dhcp消息类型”选项的dhcp消息将按消息类型引用；例如，具有“dhcp消息类型”选项类型1的dhcp消息将被称为“dhcpdiscover”消息。
         客户机服务器交互-------分配网络地址
              客户机和服务器之间的协议交换的以下摘要涉及表2中描述的dhcp消息。图3中的时间线图显示了典型的客户机-服务器交互中的时间关系。如果客户机已经知道其地址，则可以省略一些步骤；这种简化的交互在第3.2节中进行了描述。
                  1。客户端在其本地物理子网上广播dhcpdiscover消息。dhcpdiscover消息可能包含建议网络地址和租用期限值的选项。BOOTP中继代理可以将消息传递到不在同一物理子网上的DHCP服务器。
                  2。每个服务器都可以用dhcpoffer消息进行响应，该消息在“yiaddr”字段中包含一个可用的网络地址（以及dhcp选项中的其他配置参数）。服务器无需保留提供的网络地址，但如果服务器避免将提供的网络地址分配给另一个客户端，则协议将更有效地工作。在分配新地址时，服务器应检查所提供的网络地址是否尚未使用；例如，服务器可以使用ICMP回送请求探测所提供的地址。应实现服务器，以便网络管理员可以选择禁用新分配地址的探测。服务器将dhcpoffer消息传输到客户端，必要时使用bootp中继代理。

   Message         Use
   -------                 ---

   DHCPDISCOVER -  客户端广播以定位可用服务器。

   DHCPOFFER    -  服务器到客户端响应dhcpdiscover并提供配置参数。

   DHCPREQUEST  -  客户机消息向服务器（a）请求来自一个服务器的提供的参数，并绝对拒绝来自所有其他服务器，（b）确认以前分配的地址在系统重新启动后的正确性（c）在特定的网络地址上扩展租约。
   DHCPACK      -  服务器到客户端的配置参数，包括提交的网络地址。

   DHCPNAK      -  服务器到客户端指示客户端的网络地址概念不正确（例如，客户端已移动到新的子网）或客户端的租约已过期

   DHCPDECLINE  -  表示网络地址已在使用的客户端到服务器。

   DHCPRELEASE  -  客户端到服务器放弃网络地址并取消剩余租约。

   DHCPINFORM   - 客户端到服务器，只请求本地配置参数；客户端已经具有外部配置的网络地址。

                          表2:DHCP消息

         

                服务器          客户机          服务器
               (未找到)                         (存在)

                  v               v               v
                  |               |               |
                  |           开始初始化           |
                  |               |               |
                  | _____________/|\____________  |
                  |/DHCPDISCOVER | DHCPDISCOVER  \|    
                  |               |               |
              确定配置            |          确定配置
                  |               |               |
                  |               |               |
                  |\              |  ____________/|
                  | \________     | /DHCPOFFER    |  
                  | DHCPOFFER\    |/              |
                  |           \   |               |
                  |            收集回应            |
                  |             \ |               |
                  |            选择配置            |
                  |               |               |
                  | _____________/|\____________  |
                  |/ DHCPREQUEST  |  DHCPREQUEST\ |
                  |               |               |
                  |               |            提交配置
                  |               |               |
                  |               | _____________/|
                  |               |/ DHCPACK      |
                  |               |               |
                  |           初始化完成           |
                  |               |               |
                  .               .               .
                  .               .               .
                  |               |               |
                  |            正常关机            |
                  |               |               |
                  |               |\ ____________ |
                  |               | DHCPRELEASE  \|
                  |               |               |
                  |               |            放弃租赁
                  |               |               |
                  v               v               v

         图3：分配新网络地址时DHCP客户端和服务器之间交换消息的时间线图

                  3。客户端从一个或多个服务器接收一个或多个dhcpoffer消息。客户端可以选择等待多个响应。客户机根据dhcpoffer消息中提供的配置参数选择一个服务器，从中请求配置参数。客户端广播dhcprequest消息，该消息必须包含“服务器标识符”选项，以指示它选择了哪个服务器，并且可能包含指定所需配置值的其他选项。“请求的IP地址”选项必须设置为来自服务器的dhcpoffer消息中的“yiaddr”值。dhcprequest消息通过dhcp/bootp中继代理进行广播和中继。为了帮助确保任何bootp中继代理将dhcprequest消息转发到接收原始dhcpdiscover消息的同一组dhcp服务器，dhcprequest消息必须在dhcp消息头的“secs”字段中使用相同的值，并发送到与原始dhcpdiscover消息相同的ip广播地址。如果客户端没有收到dhcpoffer消息，则客户端超时并重新传输dhcpdiscover消息。
                  4。服务器从客户端接收dhcprequest广播。dhcprequest消息未选择的服务器使用该消息作为客户端已拒绝该服务器提供的通知。dhcprequest消息中选择的服务器将客户端的绑定提交到持久性存储，并用包含请求客户端的配置参数的dhcpack消息进行响应。“客户端标识符”或“chaddr”与分配的网络地址的组合构成客户端租约的唯一标识符，客户端和服务器都使用它来标识任何dhcp消息中引用的租约。dhcpack消息中的任何配置参数都不应与客户端正在响应的早期dhcpoffer消息中的配置参数冲突。此时服务器不应检查提供的网络地址。dhcpack消息中的“yiaddr”字段用已选定的网络地址填充。
                  如果所选服务器无法满足dhcprequest消息（例如，已分配请求的网络地址），则服务器应使用dhcpnak消息响应。
                  服务器可以选择将dhcpoffer消息中提供给客户端的地址标记为不可用。如果服务器未从该客户端接收到dhcprequest消息，则服务器应将dhcpoffer消息中提供给客户端的地址标记为可用。
                  5。客户端接收带有配置参数的dhcpack消息。客户端应该对参数（例如，分配的网络地址的arp）执行最终检查，并注意dhcpack消息中指定的租用期限。此时，客户端已配置。如果客户端检测到地址已在使用中（例如，通过使用arp），则客户端必须向服务器发送dhcpdreen消息并重新启动配置过程。客户端应在重新启动配置进程之前至少等待10秒，以避免在循环情况下出现过多的网络流量。
                  如果客户端收到dhcpnak消息，则客户端重新启动配置过程。
                  如果客户端既没有收到dhcpack消息，也没有收到dhcpnak消息，则客户端将超时并重新传输dhcprequest消息。客户端根据第4.1节中的重传算法重传dhcprequest。客户端应该选择重新传输dhcprequest足够的时间，以提供足够的概率来联系服务器，而不会导致客户端（和该客户端的用户）在放弃之前等待太长时间；例如，如第4.1节所述的客户机重传可以在重新启动初始化过程之前重传4次dhcprequest消息，总延迟为60秒。如果客户端在采用重传算法后既没有收到dhcpack消息，也没有收到dhcpnak消息，则客户端将恢复到init状态并重新启动初始化过程。客户端应通知用户初始化过程已失败并正在重新启动。
                  6。客户端可以选择通过向服务器发送dhcprelease消息来放弃对网络地址的租用。客户端使用dhcprelease消息中的“客户端标识符”或“chaddr”和网络地址标识要释放的租约。如果客户端在获得租约时使用了“客户端标识符”，则它必须在DHCPRORYLY消息中使用相同的“客户端标识符”。
         客户机-服务器交互-重用以前分配的网络地址
            如果客户机记住并希望重用先前分配的网络地址，则客户机可以选择省略上一节中描述的一些步骤。图4中的时间线图显示了客户机重用先前分配的网络地址的典型客户机-服务器交互中的时间关系。
                  1。客户端在其本地子网上广播dhcprequest消息。消息在“请求的IP地址”选项中包含客户端的网络地址。由于客户端尚未收到其网络地址，因此不能填写“ciaddr”字段。BOOTP中继代理将消息传递到不在同一子网上的DHCP服务器。如果客户端使用“客户端标识符”获取其地址，则客户端必须在dhcprequest消息中使用相同的“客户端标识符”。
                  2。了解客户机配置参数的服务器用dhcpack消息响应客户机。服务器不应检查客户端的网络地址是否已在使用中；此时客户端可能会响应ICMP回显请求消息。
              

                Server          Client          Server

                  v                v               v
                  |                |               |
                  |            开始初始化           |
                  |                |               |
                  |               /|\              |
                  |   ___________/ | \___________  |
                  | /DHCP REQUEST  |  DHCPREQUEST\ |
                  |/               |              \|
                  |                |               |
               定位配置            |            定位配置
                  |                |               |
                  |\               |              /|
                  | \              |  ___________/ |
                  |  \             | /  DHCPACK    |
                  |   \ _______    |/              |
                  |     DHCPACK\   |               |
                  |            初始化完成           |
                  |               \|               |
                  |                |               |
                  |         忽略后续dhcp包          | 
                  |                |               |
                  |                |               |
                  v                v               v

           图4：重用以前分配的网络地址时DHCP客户端和服务器之间交换的消息的时间线图

                  如果客户机的请求无效（例如，客户机已移动到新的子网），服务器应使用dhcpnak消息响应客户机。如果不能保证服务器的信息是准确的，则服务器不应响应。例如，标识由另一台服务器拥有的过期绑定请求的服务器不应使用dhcpnak响应，除非服务器使用明确的机制来保持服务器之间的一致性。
                  客户端使用其“客户端标识符”标识要释放的租约，或dhcprelease消息中的“chaddr”和网络地址。如果客户端在获取租约时使用了“客户端标识符”，则必须在dhcprelease消息中使用相同的“客户端标识符”。
                  3。客户端接收具有配置参数的DHCPACK消息。客户端对参数进行最终检查（如第3.1节），并记录DHCPACK消息中指定的租约的持续时间。特定租约由“客户端标识符”或“chaddr”和网络地址隐式标识。此时，客户端已配置。
                  如果客户端检测到dhcpack消息中的IP地址已在使用中，则客户端必须向服务器发送dhcpdecline消息，并通过请求新的网络地址重新启动配置过程。此操作对应于客户端移动到DHCP状态图中的init状态，如4.4节所述。
                  如果客户端接收到dhcpnak消息，则无法重用其记住的网络地址。相反，它必须通过重新启动配置过程来请求新地址，这次使用第3.1节中描述的（非缩写）过程。此操作还对应于客户端移动到dhcp状态图中的init状态。
                  如果客户端既没有收到dhcpack消息，也没有收到dhcpnak消息，则客户端将超时并重新传输dhcprequest消息。客户端根据第4.1节中的重传算法重传dhcprequest。客户端应该选择重新传输dhcprequest足够的时间，以提供足够的概率来联系服务器，而不会导致客户端（和该客户端的用户）在放弃之前等待太长时间；例如，如第4.1节所述的客户机重传可以在重新启动初始化过程之前重传4次dhcprequest消息，总延迟为60秒。如果客户端在采用重传算法之后既没有收到dhcpack消息，也没有收到dhcpnak消息，则客户端可以选择在剩余的未到期租约中使用先前分配的网络地址和配置参数。这对应于在图5所示的客户机状态转换图中移动到绑定状态。
                  4。客户端可以通过向服务器发送DHCPRORYLY消息来选择在网络地址上放弃其租约。客户端使用dhcprelease消息中的“客户端标识符”或“chaddr”和网络地址标识要释放的租约。
                  注意，在这种情况下，客户端在本地保留其网络地址，在正常关机期间，客户端通常不会放弃其租约。只有在客户端明确地需要放弃其租约的情况下，例如，客户端将被移动到不同的子网时，客户端才会发送DHCPRORYLY消息。

客户端在固定的时间段（可能是无限的）获取网络地址的租约。在整个协议中，时间以秒为单位来表示。0xFFFFFFF的时间值被保留为表示“无穷大”。
由于客户端和服务器可能没有同步时钟，所以在DHCP消息中以相对时间来表示时间，以相对于客户端的本地时钟进行解释。在无符号32位字中以秒为单位表示相对时间，给出了从0到大约100年的相对时间范围，这对于用DHCP测量相对时间是足够的。
在前一段中给出的租期解释的算法假定客户机和服务器时钟相对彼此稳定。如果两个时钟之间有漂移，则服务器可以考虑在客户端之前终止租约。为了补偿，服务器可能会向客户端返回比服务器提交给其本地客户端数据库更短的租用期限
利用外部配置的网络地址获取参数
如果客户端已经通过一些其他手段（例如，手动配置）获得网络地址，则它可以使用DHCpFILM请求消息来获得其他本地配置参数。接收DHCPNFLATH消息的服务器构造一个DHCPACK消息，该DHCPACE消息具有适合于客户端的任何本地配置参数，而无需分配新地址、检查现有绑定、填写“yiaddr”或包含租约时间参数。服务器应将dhcpack回复单播到dhcpinfo消息的“ciaddr”字段中给定的地址。
服务器应该检查DHCPNFLASH消息中的网络地址的一致性，但不能检查现有的租约。服务器形成包含请求客户端的配置参数的DHCPACK消息，并将DHCPACK消息直接发送给客户端。
DHCP中的客户端参数
使用两种技术来减少从服务器发送到客户端的参数的数量。首先，大多数参数在主机要求RFCS中定义了默认值；如果客户端从覆盖默认值的服务器接收不到任何参数，则客户端使用这些默认值。其次，在其初始DHCPDISCOVER 或DHCPRQuest消息中，客户端可以向服务器提供客户端感兴趣的特定参数列表。如果客户端包含DHCPDISCOVER 消息中的参数列表，则它必须在任何后续的DHCPRESQuess消息中包含该列表。

客户端应该包括“最大DHCP消息大小”选项，服务器可能生成其dhcp消息的大小。返回到客户端的参数可能仍然超过分配给DHCP消息中选项的空间。在这种情况下，两个附加的选项标志（必须出现在消息的“options”字段中）指示“file”和“sname”字段将用于选项。
另外，客户机可以建议网络地址和DHCPOR消息中的租赁时间。
客户端可以包括“请求的IP地址”选项，建议指定一个特定的IP地址，并且可以包括“IP地址租借时间”选项来建议它希望租用的时间。在DHCPDISCOVER或DHCPREQUEST消息中允许其他表示配置参数的“提示”选项。但是，服务器可能会忽略其他选项，因此，多个服务器可能不会为某些选项返回相同的值。当客户端验证先前获得的网络参数时，只在DDHCPREQUEST消息中填写所请求的IP地址选项。只有正确配置IP地址处于绑定、续订或重新绑定状态时，客户端才会填写“ciaddr”字段。
3.6在具有多个接口的客户端中使用dhcp
具有多个网络接口的客户端必须独立地通过每个接口使用dhcp来获取这些独立接口的配置信息参数。
3.7客户端何时应使用DHCP
当本地网络参数可能发生变化时，客户端应使用dhcp重新获取或验证其ip地址和网络参数；例如，在系统启动时或与本地网络断开连接后，因为本地网络配置可能在客户端或用户不知情的情况下发生变化。
如果客户端知道以前的网络地址，并且无法联系本地DHCP服务器，则客户端可以继续使用以前的网络地址，直到该地址的租约到期。如果租约在客户端可以联系DHCP服务器之前过期，客户端必须立即停止使用以前的网络地址，并可能将问题通知本地用户。
四。dhcp客户机服务器协议规范
在本节中，我们假设dhcp服务器有一个网络地址块，它可以从中满足对新地址的请求。每个服务器还维护一个数据库，其中包含分配的地址和本地永久存储器中的租约。
4.1构造和发送DHCP消息
dhcp客户端和服务器都通过在消息的固定格式部分填充字段并在可变长度选项区域中附加标记的数据项来构造dhcp消息。选项区域首先包括一个四个字节的“magic cookie”（在第3节中有描述），然后是选项。最后一个选项必须始终是“结束”选项。
dhcp使用udp作为其传输协议。从客户端到服务器的DHCP消息发送到“DHCP服务器”端口（67），从服务器到客户端的DHCP消息发送到“DHCP客户端”端口（68）。具有多个网络地址（例如，多宿主主机）的服务器可以在传出的dhcp消息中使用其任何网络地址。
“服务器标识符”字段既用于在DHCP消息中标识DHCP服务器，也用作从客户端到服务器的目标地址。具有多个网络地址的服务器必须准备好接受其任何网络地址，以在DHCP消息中标识该服务器。为了适应可能不完全的网络连接，服务器必须选择一个地址作为“服务器标识符”，据服务器所知，该地址可以从客户端访问。例如，如果DHCP服务器和DHCP客户端连接到同一子网（来自客户端的消息中的“giaddr”字段为零），则服务器应选择服务器在该子网上用于通信的IP地址作为“服务器标识符”。如果服务器在该子网上使用多个IP地址，则可以使用任何此类地址。如果服务器已通过DHCP中继代理接收到消息，则服务器应从消息所在的接口中选择一个地址作为“服务器标识符”接收（除非服务器有其他更好的信息可供选择）。对于任何到DHCP服务器的单播请求，DHCP客户端必须使用“服务器标识符”选项中提供的IP地址。
客户端在获取其IP地址之前广播的DHCP消息必须将IP头中的“源地址”字段设置为0。
如果来自客户端的DHCP消息中的“giaddr”字段为非零，则服务器会将任何返回消息发送到bootp中继代理上的“dhcp server”端口，其地址显示在“giaddr”中。
如果“giaddr”字段为零，“ciaddr”字段为非零，则服务器将dhcpoffer和dhcpack消息单播到“ciaddr”中的地址。
如果“giaddr”为零，“ciaddr”为零，并且设置了广播位，则服务器将dhcpoffer和dhcpack消息广播到0xffffff。
如果未设置广播位，“giaddr”为零，“ciaddr”为零，则服务器将dhcpoffer和dhcpack消息单播到客户端的硬件地址和“yiaddr”地址。
在所有情况下，当“giaddr”为零时，服务器会将任何dhcpnak消息广播到0xffffff。
如果来自客户端的DHCP消息中的“giaddr”字段为非零，则服务器会将任何返回消息发送到bootp中继代理上的“dhcp server”端口，其地址显示在“giaddr”中。如果“giaddr”字段为零，“ciaddr”字段为非零，则服务器将dhcpoffer和dhcpack消息单播到“ciaddr”中的地址。如果“giaddr”为零，“ciaddr”为零，并且设置了广播位，则服务器将dhcpoffer和dhcpack消息广播到0xffffff。如果未设置广播位，“giaddr”为零，“ciaddr”为零，则服务器将dhcpoffer和dhcpack消息单播到客户端的硬件地址和“yiaddr”地址。在所有情况下，当“giaddr”为零时，服务器会将任何dhcpnak消息广播到0xffffff。
如果DHCP消息中的选项扩展到“sname”和“file”字段，则“option overload”选项必须出现在“options”字段中，其值为1、2或3，如RFC 1533中所指定。如果“选项”字段中存在“选项重载”选项，“option”字段中的选项必须由“end”选项终止，并且可以包含一个或多个“pad”选项来填充选项字段。“sname”和“file”字段中的选项（如果按“options overload”选项指示使用）必须以字段的第一个字节开头，必须以“end”选项结尾，并且必须后跟“pad”选项才能填充字段的其余部分。“options”、“sname”和“file”字段中的任何单个选项都必须完全包含在该字段中。必须首先解释“options”字段中的选项，以便可以解释任何“option overload”选项。接下来必须解释“file”字段（如果“option overload”选项指示“file”字段包含dhcp选项），然后是“sname”字段。
DHCP客户端负责所有消息的重新传输。客户端必须采用一种重传策略，该策略采用随机指数退避算法来确定重传之间的延迟。应选择重传之间的延迟，以便根据客户机和服务器之间的互连网的特性，从服务器传送足够的时间来回复。例如，在10MB/秒的以太网网络中，第一次重新传输前的延迟应为4秒，由从-1到+1范围内选择的均匀随机数的值随机化。具有提供小于一秒的分辨率粒度的时钟的客户端可以选择非整数随机化值。下一次重新传输前的延迟应为8秒，由从-1到+1范围内选择的统一数字的值随机化。重传延迟应该加倍，随后的重传达到最大64秒。客户端可以向用户提供重传尝试的指示，作为配置过程的进展的指示。
客户端使用“xid”字段将传入的dhcp消息与挂起的请求相匹配。DHCP客户端必须选择“xid”，这样才能最大限度地减少使用与另一个客户端使用的xid相同的xid的机会。例如，每次重新启动客户机时，客户机可以选择不同的随机初始“xid”，然后使用顺序“xid”，直到下次重新启动。为每次重新传输选择一个新的“xid”是一个实现决策。客户端可以选择重复使用相同的“xid”或为每个重新传输的消息选择新的“xid”。
通常，DHCP服务器和BOOTP中继代理尝试使用UICAST递送直接向客户端递送DHCPOFFER、DHCPACK和DHCPNAK消息。IP目的地址（在IP报头中）是设置为DHCP“YAdDR”地址，链路层目标地址设置为DHCP“CHADDR”地址。不幸的是，一些客户端实现无法接收这样的单播IP数据报，直到实现了具有有效IP地址的配置（导致在客户端配置IP地址之前无法传送客户端IP地址的死锁）。
如果客户端在其协议软件配置了IP地址之前无法接收单播IP数据报，则应在客户端发送的任何DHCPdiscover或DHCPrequest消息中，将“标志”字段中的广播位设置为1。广播位将向dhcp服务器和bootp中继代理提供一个提示，以便向客户端子网上的客户端广播任何消息。可以在配置协议软件之前接收单播IP数据报的客户端应将广播位清除为0。BOOTP澄清文件讨论了使用广播位的影响
服务器或中继代理直接向DHCP客户端发送或转发DHCP消息（即，不是在“GiADDR”字段中指定的中继代理）应检查“标志”字段中的广播位。如果该比特被设置为1，则DHCP消息应当作为IP广播地址（最好是0xFFFFFFFF）作为IP目的地址和链路层广播地址作为链路层目的地地址作为IP广播来发送。如果广播位被清除为0，则该消息应作为IP单播发送到“YAdDR”字段中指定的IP地址和“CHADDR”字段中指定的链路层地址。如果单播是不可能的，消息可以作为IP广播地址（最好是0xFFFFFFFF）作为IP目的地址和链路层广播地址作为链路层目的地地址来发送。
4.2 DHCP服务器管理控制
dhcp服务器不需要响应它们接收到的每个dhcpdiscover和dhcprequest消息。例如，网络管理员对连接到网络的客户端保持严格的控制，可以选择配置DHCP服务器只响应已经通过某些外部机制注册的客户端。当客户机和服务器选择交互时，dhcp规范仅描述客户机和服务器之间的交互；描述系统管理员可能要使用的所有管理控件超出了dhcp规范的范围。特定的DHCP服务器实现可以包含网络管理员期望的任何控件或策略。
在某些环境中，当确定特定客户机的校正参数时，DHCP服务器将不得不考虑DHCP Debug或DHCPRQuestEnter消息中包含的供应商类选项的值。
DHCP服务器需要使用某个唯一标识符将客户端与其租约关联起来。客户端可以选择通过“客户端标识符”选项显式提供标识符。如果客户机提供了“客户标识符”，则客户机必须在所有后续消息中使用相同的“客户标识符”，服务器必须使用该标识符来标识客户机。如果客户端不提供“客户端标识符”选项，则服务器必须使用“CHADDR”字段的内容来标识客户端。对于DHCP客户端来说，在“客户端标识符”选项中客户端附加到的子网中使用唯一的标识符是至关重要的。使用“chaddr”作为客户端的唯一标识符可能会导致意外结果，因为该标识符可能与可以移动到新客户端的硬件接口相关联。一些站点可能选择使用制造商的序列号作为“客户端标识符”，以避免由于计算机之间的硬件接口传输而导致客户端网络地址发生意外更改。网站也可以选择使用作为“客户端标识符”的DNS名称，导致地址租约与DNS名称关联，而不是与特定硬件框关联。
DHCP客户端可以自由地使用任何策略来选择DHCP服务器，其中客户端接收DHCCPFARE消息。DHCP的客户端实现应该为用户提供一种直接选择“供应商类别标识符”值的机制。

当服务器从客户端接收DHCP发现消息时，服务器为请求客户端选择网络地址。如果没有可用的地址，服务器可以选择向系统管理员报告问题。如果有地址可用，则应按如下方式选择新地址：
o客户当前绑定中记录的客户当前地址，否则

o客户机绑定（现在已过期或已释放）中记录的客户机以前的地址，如果该地址位于服务器的可用地址池中且尚未分配，则为
o在“请求的IP地址”选项中请求的地址，如果该地址有效且尚未分配，则为
o从服务器可用地址池中分配的新地址；根据从中选择地址的子网
已收到消息（如果“giaddr”为0），或位于转发消息的中继代理的地址（如果不是0，则为“giaddr”）
o从服务器可用地址池中分配的新地址；基于接收消息的子网（如果‘GiADDR’是0）或转发消息的中继代理的地址（“GiADDR”，而不是0）选择地址。
如第4.2节所述，出于管理原因，服务器可以分配所请求的地址以外的地址，或者可以拒绝分配地址给特定的客户端，即使有可用的空闲地址。
注意，在某些网络体系结构中（例如，具有分配给物理网段的多个IP子网的Internet），可能是DHCP客户机应该分配给一个不同于“giaddr”中记录的地址的子网地址。因此，dhcp不要求将客户端作为地址从“giaddr”中的子网分配。服务器可以自由选择其他子网，并且它超出了dhcp规范的范围，无法描述选择分配的ip地址的方式。
虽然不需要正确操作dhcp，但在客户端响应服务器的dhcpoffer消息之前，服务器不应重用选定的网络地址。服务器可以选择记录提供给客户端的地址。