DHCP协议报文

 

DICP协议采用客户端-服务器方式进行交互，其报文格式共有8种，由报文中“ DHCP message
0pe”字段的值来确定，后面括号中的值即为相应类型的值，具体含义如下
1、 DHCP Discover报文，是客户端开始DHCP过程的第一个报文。
2. DHCP Ofer报文，是服务器对DHCP_ Discover报文的响应
3. DHCP Request报文，是客户端开始DHCP过程中对服务器的 DHCP Ofer报文的回应，
或者是客户端续延P地址租期时发出的报文
4. DHCP Decline报文，是当客户端发现服务器分配给他的IP地址无法使用，如P地址冲
突时，将发出此报文，通知服务器禁止使用P地址
5. DHCP Ack报文，是服务器对客户端的 DHCP Request报文的确认响应报文，客户端收
到此报文后，才真正获得了IP地址和相关的配置信息
6. DHCP Nack报文，是服务器对客户端的 DHCP Request报文的拒绝响应报文，客户端收
到此报文后，一般会重新开始新的DHCP过程
7. DHCP Release报文，是客户端主动释放服务器分配给他的1P地址的报文，当服务器收
到此报文后，就可以回收这个IP地址，能够分配给其他的客户端。
8. DHCP Inform报文，是客户端已经获得了IP地址，发送此报文，只是为了从DHCP服
务器处获取其他的一些网络配置信息，如DNS等，这种报文的应用报文非常少见
由于DHCP协议是初始化协议，简单的说，就是让终端获取P地址的协议。既然终端连IP
地址都没有，何以能够发出IP报文呢?服务器给客户端回送的报文该怎么封装呢?为了解决
这个问题，DHCP报文的封装采取了如下措施
1.首先链路层的封装必须是广播形式，既让在同一物理子网中的所有主机都能够收到这个
报文。在以太网中，就是目的MAC为全1
2.由于终端没有IP地址，IP头中的源P规定填为0.0.0.0
3.当终端发出DHCP请求报文，它并不知道DHCP服务器的IP地址，因此IP头中的目的
IP填为子网广播1P--255.255255255，以保证DHCP服务器不丢弃这个报文。
4.上面的措施保证了DHCP服务器能够收到终端的请求报文，但仅凭链路层和P层信息，
DHCP服务器无法区分出DHCP报文，因此终端发出的DHCP请求报文的UDP层中源
端口为68，目的端口为67。即DHCP服务器通过知名端口号67来判断一个报文是否是
DHCP报文。

5.DHCP服务器发给终端的响应报文将会根据DHCP报文中的内容决定是厂广播还是单播，
般都是广播形式。广播封装时，链路层的封装必须是广播形式，在以太网中，就是目
的MAC为全1，IP头中的目的IP为广播1P--25525255:255
单播封装时，链路层
的封装时单播形式，在以太网中，就是目的MAC为终端的网卡MAC地址。P头中的
目的P填为有限的子网广播P-2552525255或者是即将分配给用户的P地址(当
终端能够接收这样的IP报文时)。两种封装方式中UDP层都是相同的，源端口为67，
目的端口为68。终端通过知名端口号68来判断一个报文是否是DHCP服务器的响应报
文