DHCP协议 动态主机配置协议
动态主机配置协议(Dynamic Host Configuration Protocol，DHCP)在TCP/IP网络上使客户机获得配置信息的协议，它是基于BOOTP协议，并在BOOTP协议的基础上添加了自动分配可用网络地址等功能。这两个协议可以通过一些机制互操作。
DHCP向网络主机提供配置参数，它由两个基本部分组成：一部分是向网络主机传送专用的配置信息，另一部分是给主机分配网络地址。DHCP是基于客户/服务器模式的，这种模式下，专门指定的主机分配网络地址，传送网络配置参数给需要的网络主机，被指定的主机称为服务器。我们以后将提供DHCP服务的主机称为服务器，把接收信息的主机称为客户。不能随便谁都可以成为DHCP服务器，这需要管理员进行人为指定。由于网络中硬件和软件的多样性，使得任何一台主机随便响应DHCP请求的问题得到了解决，如果有一台机器可以随便响应的话，它也无法给用户提供正确的配置参数，而配置TCP/IP协议的参数又那么多，因此使得这种任意的响应成了不可能的事情。而分布式地分配网络地址要使用一些机制来防止地址重用，但是由于是分布式分配，有时真是防不胜防，无法从根本上杜绝网络地址冲突的问题。
DHCP支持三种IP地址分配方法。第一种是自动分配，DHCP给用户分配一个永久的IP地址。第二种是动态分配，在这种情况下，用户可以取得一个IP地址，但是是有时间限制的。第三种是手工分配，在这种方法下，用户的IP地址是由管理员手工指定的，这种情况下，DHCP服务器只需要将这个指定的IP地址传送给用户即可。至于用什么样的分配方法，不同的网络各不相同。
动态分配是唯一一种允许自动重用地址的机制。因此，这种方法对于有临时上网用户，而且网络的IP地址资源又不是多得没法用的时候特别有用。而手工指定对于管理不希望使用动态IP地址的用户十分方便，不会因为手工指定而和DHCP冲突或和别的已经分配的地址冲突。这里的关键希望大家能够理解，DHCP是一种相对集中式的管理方式。
DHCP信息包的格式是基于BOOTP包格式的，这使得BOOTP客户可以访问DHCP服务器。DHCP中使用了BOOTP的转发代理，这样就避免了在每个物理网段都设一个DHCP服务器的情况。
有许多协议与DHCP的功能相似，也同时为DHCP提供服务。反向地址解析协议（Reverse Address Resolution Protocol，RARP）用于发现网络地址和自动IP地址分配。小文件传输协议（Trivial File Transfer Protocol，TFTP）用于从启动服务器传送启动镜象。Internet控制信息协议（Internet Control Message Protocol，ICMP）用于向主机发送有关附加路由器信息。ICMP还被用于传送子网掩码信息和其它信息。主机也可能通过ICMP的路由寻找功能定位路由器 。BOOTP是用于传送配置信息的方法，它是可扩展的，正式的扩展在一些配置参数中定义。麻省理工学院的Athena工程中使用的网络信息协议（Network Information Protocol，NIP）采用分布式动态IP地址分配。资源定位协议（Resource Location Protocol，RLP）提供了高层服务定位。由于Sun公司不喜欢工作站在启动时的漫长过程，所以使用了RARP，TFTP和远程过程调用（RPC）机制，并称之为"bootparams"，这种机制是用来为无硬盘主机传送配置信息和操作系统代码。一些Sun网络也在使用动态RARP（DRARP）和自动安装机制使新加入的主机自动配置。
在其它一些相关的工作中，路径最小传输单元（MTU）寻找算法使得寻找MTU的大小成为了可能。地址解析协议（Address Resolution Protocol，ARP）也被用于一种传输协议进行资源和定位和选择。
DHCP是用于向客户传送配置信息的，客户从DHCP服务器那里获得配置信息后应该可以和Internet上任何一台主机通信。TCP/IP协议栈参数请在本文后面寻找。在初始化一台主机时并不需要配置所有这些参数，客户和服务器可以通过一种商讨机制决定传送哪些参数。DHCP允许（不要求）客户参数配置不直接与IP协议相关，而且它也不将最加入的主机加入域名系统（DNS）中。
有一些名词需要解释一下，DHCP客户和DHCP服务器已经在前面说过了，这里就不再说明了。BOOTP转发代理或转发代理是一台Internet主机或路由器，它用于在DHCP客户和DHCP服务器间传送配置信息。绑定是一些配置参数，它至少应该包括IP地址，绑定由DHCP服务器管理。
DHCP的设计目标如下：
1．DHCP应该是一种机制而不是策略，它必须允许本地系统管理员控制配置参数，本地系统管理员应该能够对所希望管理的资源管理进行有效地管理。
2．客户不需要进行手工配置，客户应该在不参与的情况下发现合适于本地机的配置参数，并利用这些参数加以配置。
3．不需要对单个客户配置网络。在通常情况下，网络管理员没有必须输入任何预先设计好的用户配置参数。
4．DHCP不需要在每个子网上要一个服务器，为了经济的原因，它DHCP服务器必须可以和路由器和BOOTP转发代理一起工作。
5．DHCP客户必须可能对多个DHCP服务器提供的服务作出响应。出于网络稳定与安全的考虑，有时需要为网络加入多个DHCP服务器。
6.DHCP必须静态配置，而且必须以现存的网络协议实现。
7．DHCP必须能够和BOOTP转发代理互操作。
8．DHCP必须能够为现有的BOOTP客户提供服务。
下面几个设计目标是对于网络层参数的设计而言的，在网络层参数上，DHCP必须可以做到以下几点：
9．不允许有几个客户同时使用一个网络地址。
10．在DHCP客户重新启动后仍然能够保留它原先的配置参数，如果可能，客户应该被指定为相同的配置参数。
11．在DHCP服务器重新启动后仍然能够保留客户的配置参数，如果可能，即使DHCP机制重新启动，也应该能够为客户分配原有的配置参数。
12．能够为新加入的客户自动提供配置参数。
13．支持对特定客户永久固定分配网络地址。
在下面我们看一下DHCP的具体问题。从客户的观点来看，DHCP不过是BOOTP的扩展。这样就可以使现有的BOOTP用户在不进行任何改动的情况下使用DHCP。图一和表一描述了DHCP信息包的格式和信息包内每个字段的意义。请注意括号内的数字，它表示此字段的大小。我们老是提到BOOTP，它和DHCP的主要区别有两点，一点是DHCP对客户分配网络地址时不是无限期的，第二点是DHCP在提供网络地址时还提供了其它配置参数。熟悉BOOTP协议的可以对比一下两个协议的不同点。下图定义了DHCP消息格式：
DHCP定义了一个新的“客户标识”选项，它是用来显式地将客户标识传送给DHCP服务器的。这个改变是针对BOOTP信息包中'chaddr'域即作为BOOTP转发信息的硬件地址又作为用户信息的情况而进行的。这个标记对于DHCP服务器来说没有什么意义，它可以是硬件地址，也可以是什么别的东西，反正只要是对于这个DHCP服务器管理的每个子网段内的客户是唯一的就可以了。客户一旦在一个信息包中使用了这个选项，以后的信息包内的这个选项必须和第一次使用时一致，这样DHCP服务器才可以正确地辨识客户。
| 域 |
字节 |
描述 |
| op |
1 |
消息op代码/消息类型1 = BOOTREQUEST, 2 = BOOTREPLY |
| htype |
1 |
硬件地址类型 |
| hlen |
1 |
硬件地址长度 |
| hops |
1 |
客户需要将这一项设置为零，当通过转发代理启动时可以供转发代理使用。 |
| xid |
4 |
操作ID，这是一个随机数，用于客户和服务器之间同步消息和消息的响应。 |
| secs |
2 |
由客户指定的时间，指的是开始地址获取和更新进行后的时间。 |
| flags |
2 |
请参阅图2。 |
| ciaddr |
4 |
用户IP地址，此字段仅当用户处于BOUND,RENEW或REBINDING状态和能够响应ARP请求时使用。 |
| yiaddr |
4 |
客户IP地址 |
| siaddr |
4 |
用于bootstrap过程中的IP地址 |
| giaddr |
4 |
转发代理IP地址 |
| chaddr |
16 |
客户硬件地址 |
| sname |
64 |
可选的服务器主机名 |
| file |
128 |
启动文件名 |
| options |
不定 |
可选的参数字段 |
options字段的长度不定，DHCP客户可能会从服务器那里接收到长度大于576字节的包。DHCP客户也可以使用最大DHCP包长度字段要求服务器传送的包长度在一定限度之内。在客户使用DHCP进行配置的时候，DHCP需要使用TCP/IP软件，在配置好IP地址之前，TCP/IP软件应该能够接收并转发发送到客户硬件地址上的IP包；DHCP服务器和BOOTP转发代理在TCP/IP软件未配置好之前不能向未接收硬件单播报文的客户传送DHCP消息。如果客户在TCP/IP软件未能配置好之前实在不能接收IP单播报文，DHCP可以使用“标记”域进行工作。请注意下图中的那个B，它代表广播标记。至于这个标记的具体内容，我们在文章的后面几节内讨论。至于其它各位，它们是保留的，它们的值只能由客户设置为0。服务器和转发代理不会理会这一字段的内容。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| 全为0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B: 广播标记位
上图表示了标记位的格式。前面已经提到过了，DHCP的一个重要功能就是能够向客户提供网络配置参数，这种存储模型实际上就是DHCP服务为每个客户保存了一个关键字，这个关键字中保存了保存了用户特有的标记和客户的配置参数。关键字可能是一个二元组（IP子网号，硬件地址），这种设计考虑到不同子网内的硬件地址可能是一样的，所以要加入一个子网号加以区别。当然关键字也可以是（IP子网号，主机名），这是为了照顾客户机会经常在不同子网间转换，或者经常改变物理地址的情况。在协议规定是，关键字需要是（IP子网号，物理地址），当然了，如果客户在信息包中显式地应用了“客户标记”这一字段的话就不这样使用了。客户可以通过查询DHCP服务器取得配置信息。
DHCP的另外一个重要特点就是能够动态地分配网络地址，这种动态分配的机制是很简单的：客户会要求使用某一网络地址一段时间，服务器就对客户说：“好的，在这一段时间内，这个地址我不给别人。”当客户使用完这一地址后再次申请时，服务器总是优先将它使用过的地址再次分配给它。我们把这种分配称为一种“租用”。说到租用，当然了，客户也可以要求增加租用期，当客户不再使用这一地址时，它就把它还给服务器。客户也可以要求永久租用，这个永久对可不是永远，当服务器觉得客户机可能已经不存在时，它可以再次把这一地址分配给别的机器使用。当网络内地址不够用的时候，永久的分配就不可能了，当地址不够用的时候，由客户归还的地址还要被继续使用，这几乎是人人都可以想得到的，服务器可以使用配置信息库内的信息帮助它决定分配哪一个地址，比如说它可以选择最近最少使用的地址进行分配。为了安全起见，服务器应该在分配前使用ICMP协议进行探测，保证这个地址没有机器使用，客户也应该能够使用一些协议（如ARP）探测新接收的地址是不是被人使用。
下面我们来说一下服务器客户协议的内容。DHCP使用BOOTP消息格式，这种格式请见表1和图1。在每个由客户发送到服务器消息的'op'字段中包括了一个BOOTREQUEST，而在服务器发送到客户消息内的'op'字段则包括了一个BOOTREPLY。DHCP信息包内'options'字段包含了十进制数99，130，83和99，这几个值。其余的地方是称为“选项”的标记参数。有几个参数定义也没几天，大家应该注意其中的一个重要的选项“DHCP消息类型”选项，这一项必须在每个DHCP信息包中存在，其它的选项有的是必须的，有的不是必须的，有的根本就是可有可无。在下文中，消息格式就以这一选项的内容决定。
在下面的表2和图3中描述了DHCP协议包中信息的意义以及DHCP客户与服务器交换信息的流程图。下面我们就过程简述如下：
1. 客户会首先进行广播，它要地址当然是它先开口，它在本子网段内广播一个DHCPDISCOVER消息，这个消息内可能包括了它希望租用的网络地方和租用时间。BOOTP转发代理可以将这个消息传送到不在这个网段内的DHCP服务器上。
2. 每个有空闲地址的DHCP服务器都响应这个消息，在响应消息中包括了可用的地址，这个地址在消息的'yiaddr'字段中，其它的配置参数在DHCP选项中。服务器无需要保留已经分配的地址，虽然这样可能想起来更有效率。在分配时，因为未保留已经分配的地址，服务器必须想办法知道这个地址未被别的客户使用，服务器可以使用ICMP协议的回应请求进行。在分配地址时，服务器有时候可能需要使用BOOTP转发代理，这一点要在实现上给予支持。下表是各种消息及其应用：
消息 功能
------- ---
DHCPDISCOVER - 客户进行广播以确定本地可用的服务器。
DHCPOFFER - 服务器给客户的应答，在其中包括了配置参数。
DHCPREQUEST - 此消息是客户发送给服务器的，作用有三个：客户从一台服务器上请求配置信息（在这个时候客户也就拒绝了其它服务器发来的地址，客户就用这个地址了）；在系统重新启动后，客户利用这个消息确认原来分配的网络地址仍然有效；客户还可以腹这个地址对特定的网络地址租用时间要求延期。
DHCPACK - 服务器发向用户的消息，包括了配置参数和网络地址。
DHCPNAK - 服务器发向用户的消息，告知客户当前使用的网络地址无效或租期已满。
DHCPDECLINE - 客户发向服务器的消息，告知服务器此地址已被使用。
DHCPRELEASE - 客户发向服务器的消息，告知服务器此地址不再使用。
DHCPINFORM - 客户发向服务器的消息，要求服务器发送本地配置信息，客户已经配置好了网络地址，不需要再发送网络地址了。
3. 客户将会接收到一个或多个服务器发来的地址和配置参数。客户可以不用那么急于回应哪一个地址，它也可以挑的。当选择好了以后，客户广播DHCPREQUEST消息，在这个消息中的“服务器标记”字段中必须包括选定的服务器的标记，此消息中也可以包括希望获得的网络配置参数，而“请求IP地址”选项则要填写服务器发来信息包中'yiaddr'的内容，也就是服务器给客户提供的IP地址。DHCPREQUEST消息在本网段广播，并通过DHCP/BOOTP转发代理向不同网段转发。如果客户在规定时间内没有收到任何服务器的回应，它会再次发送DHCPDISCOVER。
4. 许多服务器会接收到DHCPREQUEST广播，那些没有被选择的服务器将DHCPREQUEST视为拒绝包。那个被选择的服务器会记录这个地址已经有人用了，并以包含配置参数的DHCPACK包返回给客户。“客户标记”字段和指定的网络地址用以唯一确定一个客户。服务器发送的DHCPACK包内的参数不应该和原来发送的DHCPOFFER包内的内容有冲突，服务器也不在这时再次检测提供的网络地址，在DHCPACK包内的'yiaddr'字段包括了选择的网络地址。如果被选的主机不能满足DHCPREQUEST包内的要求，它应该以DHCPNAK包回复。服务器可以将DHCPOFFER包内包括的地址设置为不可用，也可以不设置，但是如果服务器没有从客户那儿接收到DHCPREQUEST包，此地址一定要保证是可用的。
5. 客户接收到包括配置参数的DHCPACK包，它应该对此参数进行最后一次检查，不要和人家的冲突了，当没有发现冲突时客户才算真正配置好了。如果客户发现有人已经使用了这个地址，它需要向服务器发送DHCPDECLINE包，并重新开始配置过程，当然了，客户机必须等待一段时间后才能进行重要的配置过程，如果紧接着就进行会对网络造成巨大的压力。不但在地址冲突的时候要重新开始配置过程，在接收到DHCPNAK包时也要进行重要配置过程。如果超时而未接收到DHCPACK或DHCPNAK包，客户需要再次发送DHCPREQUEST。当然这个发送的过程要有一定的时间，不要人家服务器还没接收到呢，这边就放弃了。如果重新发送后还是没有收到DHCPACK或DHCPNAK包，客户要返回初始状态，并通用用户，初始化过程失败，正在重新开始。
6. 客户可以通过发送DHCPRELEASE包取消租用。客户在消息中放置“客户标记”或”chaddr”和网络地址。如果客户在租用的时候使用了“客户标记”，在取消租用的时候必须还使用这一标记项。
如果客户希望再次使用过去使用过的网络地址，客户就不需要进行上面说的一些步骤，对老客户的服务要方便一些吗。下面的时间图就能够帮助您理解这一过程。
1. 客户在自己的子网里广播一个DHCPREQUEST消息，在此消息的“请求IP地址”选项中包括了客户现在的网络地址。（这里要注意一点，如果客户目前没有网络地址，'ciaddr'域绝对不能填写）。BOOTP转发代理把这个消息发送到不在同一子网内的DHCP主机上。如果客户当时申请租用地址的时候使用了“客户标记”，这个新发的包内也必须使用相同的“客户标记”，说自己是老客户总要有证据。
2. 这个时候服务器已经知道客户是个老客户，也知道了它的配置参数，就返回一个DHCPACK消息。此时服务器不负责检查网络地址是否已经被使用，这个工作要客户自己完成。既然说自己是老客户了，那有些事情自己办了。
如果客户的请求无效（可以客户已经移到另外一个子网内了），服务器应该以DHCPNAK返回，如果服务器不能确认发送到的消息是否准确，它干脆什么都不返回。我们可以想象一个，如果一个服务器接收到一个应该属于别的服务器管理的网络地址，它就不要返回DHCPNAK包了，自己不知道的事情就不要说不。
如果包内的'giaddr'域为零说明客户和服务器处于同一子网内，服务器不会轻信这样的好事的，它会发向0xffffffff发送广播，它担心这个客户已经离开这个子网，或者它的子网掩码不正确，即使客户接收到了这个消息，也不需要发送ARP。如果服务器知道客户不在这个子网内，它只需要按照'giaddr'内记录的地址发送一个消息给BOOTP转发代理就是了，转发代理会将服务器发送的包发到客户手中，即使客户此时已经处于新的子网中了。
3. 客户接收了带配置参数的DHCPACK信息，客户最后对参数进行检查，标记了租用时间。指定的租用时间由包内的“客户标记”或'chaddr'字段确定，这时客户也就配置好了。如果客户检测到地址冲突，客户必须以DHCPDECLINE包通知服务器并重新开始请求网络地址。如果客户接收到DHCPNAK包，它不能再使用当前地址了，它必须重新开始配置过程以获得新的网络地址。如果客户既然没有收到DHCPACK或DHCPNAK，它必须重新发送DHCPREQUEST包以进行配置。客户应该在一定时间再次发送DHCPREQUEST请求。在地址没有过期的时候，如果客户既没有收到DHCPACK或DHCPNAK，客户可以继续使用这个地址及相应的参数。
4. 客户可能通过DHCPRELEASE包取消租用。在这个取消的包中包括了“客户标记”或'chaddr'和网络地址。
客户租用某一地址是有时间限制的，当然也可以是无期限限制的。在整个DHCP中，时间的单位是秒，而0xffffffff表示无限。在分布式系统中有一个重要的问题就是时间的同步，服务器和客户的时间可能是不同步的，为了实现时间的同步，要靠在一定时间内发送DHCP包以客户本地时间来表示。这个时间是由一个无符号的32位数表示，它可以表示0到100年，这对于现行的系统来说够用了。在上面的图中，我们假定时间是同步的，如果两者时间上有一点差别，服务器可以给客户发一个把租期稍微延长一点，这样就可以了。
如果客户通过别的手段获得了网络地址，它可以使用DHCPINFORM请求获得其它配置参数，服务器接收到DHCPINFORM包，并建立一个DHCPACK消息，在其中包括一些合适客户的配置参数，只是不包括分配网络地址，检查现有的绑定，在信息中不填充'yiaddr'字段或租用时间参数。服务器取得DHCPINFORM包内的'ciaddr'地址，而返回DHCPACK包。
并不是所有客户需要初始化所有在附表内的参数。有两种方法可以减少服务器到客户发送参数的数目。客户可以使用默认参数，如果服务器不发送任何参数，客户就使用默认参数。第二种方法是让客户在DHCPDISCOVER和DHCPREQUEST包内给服务器发送一个自己觉得合适的参数表，让服务器在这个表中选择，如果客户在DHCPDISCOVER内使用了这个表，在其后的DHCPREQUEST包内也要包括这个列表。客户应该包括“最大DHCP包大小”选项使服务器预先知道DHCP消息的大小。而返回客户的参数有可能超过给DHCP包分配的空间。在这种情况下，两个额外的选项标记指示'file'和'sname'域可以用做选项使用。客户在发送到服务器的包内指示自己希望得到哪一个参数项。当然客户也可以自己把希望得到网络地址和租用时间包括在包内发送到包内，这样就减少了服务器发向客户的数据量，这是因为服务器是中心结点，如果它的处理速度下降会影响到整个网络的性能。其它一些选项也可以在包内使用，但是服务器可能不理会这些消息，在多个服务器响应的时候，返回的值可能根本就不一样。当客户确认自己获得的网络地址时，“请求的IP地址”项可以仅在DHCPREQUEST包内包括。当客户处于BOUND，RENEWING或REBINDING状态而正确配置了IP地址时，客户可以填充'ciaddr'域。如果服务器接收到一个包括无效请求地址的“请求的IP地址”包时，服务器应该向客户返回DHCPNACK包，如果需要可以向管理员报告。如果客户有多个网络接口，各个接口必须独立地以DHCP方式获得自己的配置参数。
下面我们来介绍一下何时客户应该使用DHCP协议，客户在本地网络参数发生改变时应该使用DHCP，例如在系统重新启动时或在与网络失去联系一段时间之后，本地网的参数可以在用户不知情的情况下发生改变。如果客户（机）还记得住自己的IP地址而且无法联系本地的DHCP服务器，它可以继续使用这一地址，直到租期到期为止，如果在地址失效前客户（机）仍然不能联系到DHCP服务器，在租期过期时，它应该立即放弃对此网络地址的使用，并通过用户。
在下面，我们要具体介绍一下DHCP协议的客户/服务器协议内容，这里我们假设服务器有一些可供使用的地址，使用这些地址可以满足客户对地址的需求。每个服务器也支持一个分配的地址的数据库及租用情况。
而在建立和传送DHCP消息的问题上，DHCP客户和服务器都向消息中的特定字段填充来建立DHCP消息。选项区域包括头四个字节的'magic cookie'，在其后是选项，而最后的选项必须是'end'选项。DHCP使用UCP协议传送信息，服务器方接收此消息的端口是端口67，而客户在端口68接收服务器方面的消息。如果服务器有多个网络地址，它可以使用其中任何一个来传送DHCP消息。“服务器标记”字段用于DHCP服务器发送的DHCP消息，也用于客户来确定服务器。如果服务器有多个网络地址，那么多哪个地址来的请求它也不应该拒绝。为了照顾到网络使用的实际情况，服务器必须选择一个地址来专门接收客户发送来的请求。比如一个服务器和客户处于同一个子网，服务器应该使用这个子网内的地址作为“服务器标记”使客户便于发送请求。同样客户也应该使用提供的“服务器标记”向特定的服务器发送请求。如果客户还没有获得网络地址，在客户发向服务器的请求包中的IP地址一栏中应该被设备为0。
如果在DHCP消息中的'giaddr'域不为0，服务器就会向'giaddr'中指示的BOOTP转发代理发送。如果'giaddr'为0，而'ciaddr'不为0，服务器将DHCPOFFER和DHCPACK发向'ciaddr'中指示的地址。如果'giaddr'和'ciaddr'为0，而广播域被设置，应该将返回信息广播，也就是向0xffffffff发送。如果广播域也未被设置，那只好向客户的硬件地址发送了。无论发生何种情况，只要'giaddr'为0，服务器都应该广播DHCPNAK信息。
如果在DHCP信息中的选项扩展到了'sname'和'file'域，在“选项”域中必须有'option overload'选项。如果'option overload'在'options'中出现，那出现的选项必须以'end'选项结束，不足的地方以特定的填充字符填充。客户在接收到相应的选项，如果有相同的选项，客户将它们变为一个。
DHCP客户全权负责消息的再次传送。客户必须采用一种算法来决定采用何种算法来选择隔多长时间再次发送。这个时间要选择的合适，不要服务器的应答还没有来，客户就不烦麻而重新发送了，说起来容易，实际上还是很即使做到的，因为网络的结构与性能都是不好预测的。机器在重新发送前可以通知用户。
通常情况下，DHCP服务器和BOOTP转发代理试图把DHCPOFFER，DHCPACK和DHCPNAK直接传送给客户。IP目的地址被设备在DHCP 'yiaddr'域内，而数据链路层地址设置在'chaddr'域内。但是，请注意，如果客户还没有设置IP时，它不会接收这种传送的。这样的客户需要在发送给客户的包内将广播位设置为1，这样服务器和转发代理就会在客户所在子网内广播这个消息。如果能够直接接收，就不要为网络造成不必要的负担，不要采用广播的形式了。
如果客户要求广播，服务器和转发代理应该向IP广播地址发送这个包。如果客户未要求广播，则直接使用IP协议传送就是了，这时需要使用'yiaddr'域内的IP地址和'chaddr'域内的数据链路层地址。
DHCP服务器不必理会所有的请求，管理员可以对服务器采用严格的管理机制，只对这个网络中注册的客户响应。本文是讨论服务器理会的客户和服务器之间的关系。服务器在为客户服务时必须保留客户的唯一标记，客户可以直接在发送的请求包内设置“客户标记”域，这样服务器和客户的所有消息中都必须包括这个唯一的标记，也靠这个标记来识别客户。如果客户未使用这个域，服务器使用'chaddr'域来达到唯一标记的目的，但这样做可能会有意想不到的结果，因为这个域一般和网络适配器相关，是硬件地址，这个适配器却可以被别的客户使用，这时候事情就坏了。有时候可以选择DNS名和一个客户相关，这时候网络就是被分配给DNS域而不是一个硬件单元。而客户在识别服务器方面就没这么麻烦了，反正从谁那儿用都一样。
DHCP服务器的动作要视客户的响应而定，服务器可能从客户那儿接收如下几种包：
o DHCPDISCOVER
o DHCPREQUEST
o DHCPDECLINE
o DHCPRELEASE
o DHCPINFORM
下面我们就开始看一下服务器对各种消息的响应。
当服务器接到DHCPDISCOVER时，服务器为客户选择一个网络地址，如果没有可用的网络地址了，服务器需要把这个情况向管理员报告。如果有可用地址，新地址要么是客户现在使用的地址；要么是客户原来使用的，现在还未被分配给别的客户使用；要么是客户在“请求的IP地址”选项标记的地址，而且这个地址还未被分配给别的客户使用；要么这个地址是根据客户所在网段分配的，要么是根据转发代理进行分配的。那当然，有时候因为管理的原理，服务器即使有空闲的地址也不会分配给未经过授权的用户，或许还会为用户指定一个地址，即使这个客户未提出任何申请。在一些网络结构中，特别是是分网段的结构中，DHCP客户会得到一个不是本网段地址的网络地址，这是正常的。在没有接收到客户对DHCPOFFER的回应以前，服务器不得将这个地址给别的客户使用。
下面是服务器选择租用时间的规则：
o 如果客户未在DHCPDISCOVER内要求延长租用时间（或指定租用时间），服务器返回先前指定给此地址的最小的租用时间。（请注意：客户必须显式地要求对以前租用的地址租用时间延期），要不然的话
o 如果客户未在DHCPDISCOVER内要求租用时间，而且用户还未有网络地址，就返回本地配置的默认租用时间，要不然的话
o 如果用户在DHCPDISCOVER包内要求了租用时间（这时就不要管用户是不是已经分配网络地址了），服务器要么答应它，要么为它选择另外的租用时间。
| 域 |
DHCPOFFER |
DHCPACK |
DHCPNAK |
| 'op' |
BOOTREPLY |
BOOTREPLY |
BOOTREPLY |
| 'htype' |
请参阅其它资料，这里不做讨论 |
||
| 'hlen' |
硬件地址字节长度 |
||
| 'hops' |
0 |
0 |
0 |
| 'xid' |
同用户DHCPDISCOVER内的'xid' |
同用户DHCPDISCOVER内的'xid' |
同用户DHCPDISCOVER内的'xid' |
| 'secs' |
0 |
0 |
0 |
| 'ciaddr' |
0 |
0或同DHCPREQUST内的’ciaddr’ |
0 |
| 'yiaddr' |
提供给客户的IP地址 |
提供给客户的IP地址 |
0 |
| 'siaddr' |
下一个BOOTSTRAP服务器地址 |
下一个BOOTSTRAP服务器地址 |
0 |
| 'flags' |
同用户DHCPDISCOVER内的'flags' |
同用户DHCPDISCOVER内的'flags' |
同用户DHCPDISCOVER内的'flags' |
| 'giaddr' |
同用户DHCPDISCOVER内的'giaddr' |
同用户DHCPREQUEST内的'giaddr' |
同用户DHCPREQUEST内的'giaddr' |
| 'chaddr' |
同用户DHCPDISCOVER内的’chaddr’ |
同用户DHCPREQUEST内的’chaddr’ |
同用户DHCPREQUEST内的’chaddr’ |
| 'sname' |
服务器名或选项 |
服务器名或选项 |
未使用 |
| 'file' |
客户启动文件名或选项 |
客户启动文件名或选项 |
未使用 |
一旦决定了网络地址和租用时间，服务器要发出带有配置参数的DHCPOFFER。对于配置参数的考虑要取决于以下规则： 网络地址和租用时间的决定前面已经说过了，这里就不再哆嗦了。而其它配置参数要符合：
-- 如果服务器对某一选项已经有显式指定的值，必须使用这个值，如果没有显式指定这样的值
-- 如果服务器发现有“主机需求文档”中定义的参数，服务器返回的信息中必须包括这样的值，如果没有定义这样的数
-- 服务器不返回此参数的值
服务器必须提供尽可能多的配置参数，而且通常情况下一个参数只出现一次。
DHCPREQUEST消息可能来自客户对DHCPOFFER的响应。如果在DHCPREQUEST内包括“服务器标记”选项，此消息是对DHCPOFFER的响应；否则可是对延长租期的确认。在DHCPACK内的参数不得和DHCPOFFER内的参数冲突，客户也应该使用DHCPACK内的参数进行配置。
客户在下面几种情况下发送DHCPREQUEST。
o DHCPREQUEST在SELECTING状态产生：
客户将选择的服务器填充在“服务器标记”，而'ciaddr'必须为0，“请求的IP地址”必须和发送来的DHCPOFFER内的yiaddr值一致。一定要注意，客户在接收到多个DHCPOFFER之后会选择一个自己认为最合适的，客户需要在DHCPREQUEST中指出它选择了哪一个服务器。服务器有可能根本收不到响应，因此在DHCPOFFER时，服务器并未分配这个地址，它可以用这个地址响应其它用户的请求。
o DHCPREQUEST在INIT-REBOOT状态产生：
“服务器标记”不填，“请求的IP地址”填充原先指定的网络地址， 'ciaddr'必须为0。客户是为了确认原来获得的地址和参数，如果地址，或参数，或网络不对，服务器应该发送DHCPNAK。如果服务器内没有客户的资料，它就保持沉默，或给网络管理员发出警告。如果DHCPREQUEST内的'giaddr'是0x0，客户和服务器在同一子网，服务器必须广播DHCPNAK消息，因为客户可能没有正确的网络地址或子网掩码，客户可能无法响应ARP请求。如果'giaddr'不为0，客户和服务器不在同一子网，那么DHCPNAK中的广播选项必须设置，以让转发代理广播这一消息。
o DHCPREQUEST在RENEWING状态产生：
“服务器标记”不填，“请求的IP地址”不填，'ciaddr'内必须填写客户的IP地址。在这种情况下客户已经完成了配置，它不过是想延长租期而已。这个消息是单播的，不需要进行中转，因此'giaddr'没用。
o DHCPREQUEST在REBINDING状态产生：
“服务器标记”不填，“请求的IP地址”不填，'ciaddr'内必须填写客户的IP地址。在这种情况下客户已经完成了配置，它不过是想延长租期而已。这个消息是广播的，因此它应该发向0xffffffff。
如果服务器接收到DHCPDECLINE消息，客户已经通过别的方法知道此网络地址已经由别的计算机使用，服务器应该在此地址上打上标记，并将此情况通知网络管理员。在接收到DHCPRELEASE消息时，服务器将相应的网络地址标记为未分配，同时保留相应的配置参数，因为客户很有可能会在不久的将来重新申请这一网络地址和配置参数。服务器对DHCPINFORM消息的响应是DHCPACK，发送的地址在DHCPINFORM消息的'ciaddr'中包括。服务器对于租用期限和'yiaddr'不填。
下面我们说说客户那边的情况吧。客户能够从服务器接收到的消息也就是几种：DHCPNCK，DHCPACK，DHCPOFFER。
客户在所需要的参数和网络地址都已经在上面说过了，这里就不再重复了。客户在发送前产生并记录一个随机的操作标记，将这个标记插入'xid'，客户同时还记录了本地时间以便计算租期的过期时间。然后它广播DHCPDISCOVER消息。如果接收到的DHCPOFFER内的'xid'与最近记录的'xid'不符，这个包就会无回应地丢弃了。
| 域 |
DHCPDISCOVER DHCPINFORM |
DHCPREQUEST |
DHCPDECLINE DHCPRELEASE |
| 'op' |
BOOTREQUEST |
BOOTREQUEST |
BOOTREQUEST |
| 'htype' |
请参阅其它资料。 |
||
| 'hlen' |
以字节为单位的硬件地址长度。 |
||
| 'hops' |
0 |
0 |
0 |
| 'xid' |
由客户选择 |
由服务器发送来DHCPOFFER中的’xid’获得 |
由客户选择 |
| 'secs' |
0或从DHCP过程开始到现在的时间 |
0或从DHCP过程开始到现在的时间 |
0 |
| 'flags' |
如果客户要求广播响应，设置'BROADCAST' |
如果客户要求广播响应，设置'BROADCAST' |
0 |
| 'ciaddr' |
在DHCPDISCOVER时为0，在DHCPINFORM时为客户的网络地址 |
0或客户的网络地址 |
0或客户的网络地址 |
| 'yiaddr' |
0 |
0 |
0 |
| 'siaddr' |
0 |
0 |
0 |
| 'giaddr' |
0 |
0 |
0 |
| 'chaddr' |
客户的硬件地址 |
客户的硬件地址 |
客户的硬件地址 |
| 'sname' |
相应的选项或未使用 |
未使用 |
|
| 'file' |
相应的选项或未使用 |
未使用 |
|
| 'options' |
相应的选项 |
未使用 |
在用户接收到DHCPACK后，它将请求所使用的时间加上租用时间作为自己对这个网络地址的租用时间。这一点请注意。如果在INIT-REBOOT状态下发送DHCPREQUEST消息，客户必须要“请求的IP地址”内填上已知的IP地址。
客户在使用广播或者是单播的问题上有一个原则，尽量少使用广播，因为这会使网络负担加重，在知道服务器IP地址的情况下要使用单播，也就是直接向那个地址发送。如果单播不成功，再恢复为广播式发送。
客户记录两个时间T1和T2，T1是客户进入RENEWING状态试图联系分配给客户IP地址的服务器的时间，T2是客户进入REBINDING状态并试图联系服务器的时间。T1必须早于T2。这两个时间表示为相对时间，这是为了避免使用同步时钟。
在T1时间，客户进入RENEWING状态发送DHCPREQUEST要求延期，客户在DHCPREQUEST消息内设置'ciaddr'域为当前的网络地址，并同时记录发送时的本地时间。返回的DHCPACK包中的'xid'域如果和客户保留的'xid'域不同，此消息被丢弃。直到接收到两者一致的包。
DHCP的安全性不高，它在基于UDP和IP协议的，这两个协议的安全性就不好，而且在开始的时候DHCP协议主要用于无盘站，在这样的环境中实现密码十分困难，因此DHCP到现在也是不安全的。非法的服务器和非法的客户都可能会系统造成危害。
下面是主机配置参数：
IP-layer_parameters,_per_host:_
Be a router on/off HRC 3.1
Non-local source routing on/off HRC 3.3.5
Policy filters for
non-local source routing (list) HRC 3.3.5
Maximum reassembly size integer HRC 3.3.2
Default TTL integer HRC 3.2.1.7
PMTU aging timeout integer MTU 6.6
MTU plateau table (list) MTU 7
IP-layer_parameters,_per_interface:_
IP address (address) HRC 3.3.1.6
Subnet mask (address mask) HRC 3.3.1.6
MTU integer HRC 3.3.3
All-subnets-MTU on/off HRC 3.3.3
Broadcast address flavor 0x00000000/0xffffffff HRC 3.3.6
Perform mask discovery on/off HRC 3.2.2.9
Be a mask supplier on/off HRC 3.2.2.9
Perform router discovery on/off RD 5.1
Router solicitation address (address) RD 5.1
Default routers, list of:
router address (address) HRC 3.3.1.6
preference level integer HRC 3.3.1.6
Static routes, list of:
destination (host/subnet/net) HRC 3.3.1.2
destination mask (address mask) HRC 3.3.1.2
type-of-service integer HRC 3.3.1.2
first-hop router (address) HRC 3.3.1.2
ignore redirects on/off HRC 3.3.1.2
PMTU integer MTU 6.6
perform PMTU discovery on/off MTU 6.6
Link-layer_parameters,_per_interface:_
Trailers on/off HRC 2.3.1
ARP cache timeout integer HRC 2.3.2.1
Ethernet encapsulation (RFC 894/RFC 1042) HRC 2.3.3
TCP_parameters,_per_host:_
TTL integer HRC 4.2.2.19
Keep-alive interval integer HRC 4.2.3.6
Keep-alive data size 0/1 HRC 4.2.3.6
Key:
MTU = Path MTU Discovery (RFC 1191, Proposed Standard)
RD = Router Discovery (RFC 1256, Proposed Standard)