DHCPV4 VS DHCPV6

     为了给网络客户机自动分配IP地址以及生成所需的配置参数，IETF分别给IPV4和IPV6网络定义了相关的协议标准，即DHCP（RFC2131）和DHCPV6(RFC3315)，以及扩充的选项标准。本文主要阐述两个协议产生的背景、功能并比较二者之间的异同点。

一、背景

      DHCP协议的出现可以回推到无盘工作站的出现，人们希望工作站能够通过网络通信的方式从服务器中获得自己的IP地址、服务器的IP地址、启动映像名等信息，此时Bootstrap协议(简写为BOOTP)应运而生，它主要应用于相对静态的环境，每台主机都有一个永久的网络连接，管理人员只需要建立一个BOOTP配置文件，该文件定义了每台主机的一组BOOTP参数，由于配置通常保持不变，因此该文件也不会经常改变，但是随着网络规模的不断扩大，网络配置也变得越来越复杂，原来针对静态主机配置的BOOTP协议明显不能满足实际的需要，由此，为了用户能快速地接入和退出网络，提高IP地址资源的利用率，IETF在BOOTP的基础上制定了一种自动分配IP地址的机制，即DHCP协议，因此，我们DHCP协议可以看成是对BOOTP协议的升级(所以要想抓DHCP包，必须输入bootp才行)。为了BOOTP协议的兼容，DHCP协议允许三种分配地址的方式，即手工配置，自动配置以及完全动态分配，除此之外，DHCP在原来的基础上增加了对选项的支持，通过这种方式，可以获得更多来自于服务器的配置信息。后来，随着IPV6网络的出现，以及IPV6地址所表现出来的巨大差异，IETF在2003年重新制定了针对IPV6的DHCP协议，即DHCPV6，对比V4，它增加了一些特有的功能，如支持有状态和无状态地址分配服务，支持临时地址，非临时地址以及前缀地址的分配等，后面小节将会更加具体比较二者在选项、客户端与服务器行为、消息类型的差异。

二、DHCP VS DHCP6

   要比较两个协议，最直观的方式无非是通过比较二者有关的数据报，图1与图2分别对应的是正常情况下二者获取IP地址的过程示意图，从图1中可以看出，客户端首先利用0.0.0.0地址发送一个一个广播discover消息，接着多个服务器响应并发回了可供客户机使用的地址(参照offer消息)，然后客户机从中选择某台服务器并向其发送request消息，最后被选中的服务器返回ACK确认消息，这样就完成了对客户机的地址分配。对于图2，客户机利用本地链路地址发送一个solicit广播消息(广播地址是ff02::1:2), 之后一台服务器提供了advertise消息，并将IP地址以及客户机所需要的配置参数信息返回，然后客户机发送一个request消息，主要从服务器端索取自己所需要的请求参数信息，最后服务器响应请求。

                                                                                                            图1 DHCP获取IP地址过程

                                                                                                          图2 DHCP6获取IPV6地址过程

从上面这两个简单地过程，大体上了解了DHCP与DHCP6在获取IP地址时的一般过程，也明白了其中的一些差异，下面将从各个方面更加深入地介绍二者之间的差异。

1.   DHCP消息VS DHCP6消息

      附A显示了消息报的格式差异，DHCP消息报组成字段的长度及功能如表1所示，对比表2的DHCP6数据报，DHCP消息报字段显得十分庞大，但是这并不代表，DHCP所支持的功能更多，因为DHCP6的选项十分丰富，如DHCP中的ciaddr字段所表达的含义在DHCP6中的IA-NA或者IA-TA选项是对应的，类似的还有chaddr字段对应于Client Identifier，这些在后面的选项比较中都会讲到。

表1 DHCP数据报字段的长度与功能

字段	长度（字节为单位）	功能
op	1	定义DHCP消息类型，1为BOOTREQUEST,2为BOOTREPLY
htype	1	定义硬件类型，1代表ethernet
hlen	1	硬件地址长度，6代表10mb以太网
hops	1	路由条数，通常用于中继代理，
xid	4	由客户机生成的随机数，通常用于客户机和服务器之间同步消息
secs	2	由client填充，表示客户机经历地址获取或续约所经历的时间
flags	2	定义广播标志
ciaddr	4	客户机的IP地址
yiaddr	4	客户机的IP地址
siaddr	4	返回下一个使用BOOTP协议的服务器地址
giaddr	4	中继代理的IP地址
chaddr	16	客户机的硬件地址
sname	64	服务器的hostname
file	128	boot文件名
options	var	支持的选项

表2 DHCP6数据报字段长度及功能

字段	长度（字节为单位）	功能
msg-type	1	定义DHCP消息类型
transaction-id	3	由客户机生成的随机数，通常用于客户机和服务器之间同步消息
options	var	支持的选项

          另外，需要指出的是，DHCP6将许多参数信息存放在选项中，这样能够减少数据报的净长度，提高存储利用率。这是因为DHCP6的消息报头仅占4个字节，而将需要发送或者接收参数信息附在选项上，而DHCP消息报则是将大量的字段包含在报头中，而实际情况是在某些消息报中，许多字段未得到充分运用而导致存储浪费，如hops仅仅在支持中继代理时才使用，file字段则几乎被舍弃。

         前面已经从消息报字段的长度以及功能两个方面对DHCP与DHCP6做了比较，下面将着重阐述DHCP与DHCP6各自所包含的消息类型，以及消息的发方以及收方，消息产生的时间，client和server各自表现出怎样的行为等内容。

        值得注意的是，DHCP消息报利用”op”字段来表示消息的类型，即BOOTREQUEST和BOOTREPLY，前者表示消息报是从客户机发往服务器，而后者刚好相反，由此可以看到，op字段仅仅只是定义了该消息报的发送方向，而对该消息报的其他信息一无所知，基于此，RFC2131规定在DHCP消息报中一定要包含DHCP Messae Type选项，另外，还规定了常见的几种消息类型：DHCPDISCOVER，DHCPOFFER，DHCPREQUEST ，DHCPACK，DHCPNAK，DHCPDECLINE，DHCPRELEASE和DHCPINFORM。在DHCP6消息报中，消息类型是由字段msg-type指定的，同样定义了常见的几种消息类型：SOLICIT，ADVERTISE，REQUEST，CONFIRM，RENEW，REBIND，REPLY，RELEASE，DECLINE，RECONFIGURE，INFORMATION-REQUEST，RELAY-FORW和RELAY-REPL，另外还定义了对应的数字编码。下面将通过表格的形式对数据包内容做更详细的解释。

表3 DHCP消息报详细信息

Type	From	To	How and when to use	Client behavior	Server behavior	Relay agent
DHCPDISCOVER	客户机	本地服务器/中继代理	客户机向本地可得到的服务器发送广播消息，可能会包含选项内容(网络地址和租约时间), 注意：若目的地是中继代理，应该填充’giaddr’字段消息	发送广播消息，广播地址为255.255.255.255，自身地址为0.0.0.0	1.返回客户机DHCPOFFER消息，并在里面填充“yiaddr”字段 2.若没有可用的地址，则向管理员报告问题	给不与客户机在同一子网内的DHCP服务器传递消息报
DHCPOFFER	服务器/中继代理	客户机	回应来自于客户机发送的DHCPDISCOVER消息报	如果没收到OFFER消息报，则重传DISCOVER消息，否则选择一个REQUEST消息报给选中的服务器，注意要填充'server identifier' 字段	在OFFER消息中返回客户机DISCOVER消息中所需的参数信息	将来自于DHCP服务器的OFFER消息报转发给客户机
DHCPREQUEST	客户机	本地服务器/中继代理	满足以下情形时，客户端才发送请求包： 1.向选中的服务器发送请求需要的参数列表，同时拒绝未选中的服务器； 2.在客户机状态发生变化，如重启，链路改变等，向服务器确认之前分配的地址是否还能使用； 3.  请求延长租约	向服务器或中继代理发送请求消息报，广播地址依然为255.255.255.255，自身地址为0.0.0.0	1.   根据返回的’server identifier’字内容，服务器能判断自己是否选中； 2.被选中的服务器将客户机信息进行保存，并发送DHCPACK消息给客户机，注意，此时所提ACK消息中的内容应该与之前的OFFER消息一致。这与客户端第一种情形对应。 3.  若服务器不能满足客户机的请求(如地址已经被分配)，此时发送DHCPNAK消息给客户机，与第二、三种情形对应。 4. 对应租约到期的客户机，服务器没有收到它的续约请求，则将所分配地址标记为available	将客户机发送的请求包转发给DHCP 服务器
DHCPACK	服务器/中继代理	客户机	服务器收到来自于客户机的DHCPREQUEST消息。消息报中应该携带客户机所需要的配置信息。	1.若客户机接收到ACK消息报，则利用ARP协议判断报中的地址是否内使用，若不能使用，则发送DECLINE消息给服务器并重启配置过程，发送请求报； 2. 若客户机没收到ACK消息，或者NAK消息，首先客户机启动重传算法，若重传之后依然没有获得，则则客户机重启配置过程，发送请求报。	发送ACK消息给客户端	将来自于DHCP服务器的ACK消息报转发给客户机
DHCPNAK	服务器/中继代理	客户机	当服务器判断之前给客户机发送的地址已被使用或者租约期已到	重启配置过程并发送请求报	服务器发送NAK消息，并在`mseeage`选项中报告此问题	将来自于DHCP服务器的NAK消息报转发给客户机
DHCPDECLINE	客户机	服务器/中继代理	客户机通过ARP协议探测到服务器所分配的IP地址已经被本网络中其它主机占用	发送DECLINE消息报，并重启配置过程	服务器将该地址标记为`unavailable`,并向管理员通报	将客户机发送的DECLINE消息报转发给DHCP 服务器
DHCPRELEASE	客户机	服务器/中继代理	客户机向释放掉之前分配的IP地址	客户机在RELEASE消息报中填充`client identifier`, `chaddr`和网络地址，并将其发给服务器或者中继代理	服务器首先将客户机释放的地址标记为`available`,并将客户机的配置信息进行保存，已被后来重新使用	将客户机发送的RELEASE消息报转发给DHCP 服务器
DHCPINFORM	客户机	服务器/中继代理	客户机已经通过其他方式获得IP地址(如手动)，但是需要从服务器处获得本地配置信息	发送INFORM给服务器	构造出一个不包含“分配的IP地址，`yiaddr`字段和租约”信息的ACK消息报，但是包含客户机所要求的配置信息	将客户机发送的INFORM消息报转发给DHCP 服务器

上表详细描述了DHCP消息报的属性以及行为内容，有几个需要特别说明的地方是：

       ◆ 客户机所采取的重传机制是随机指数退避算法，具体思想可参考RFC2131文档；

       ◆ 客户机在发送DHCPDISCOVER消息报与DHCPREQUEST消息报时，广播地址与自身地址分别为：255.255.255.255,0.0.0.0.

       ◆ DHCP协议所运用的端口分别是：客户机-68，服务器-67.

       ◆ 在客户机释放掉IP地址后，服务器还将保存之前对客户机的配置信息，这样有助于相对稳定地分配IP地址，只要下次这个IP地址没有分给其它客户机，当前客户机在下           次发出配置地址请求时，服务器会将先前的配置信息赋给它。

       ◆ 注意发送DHCPREQUEST消息报的几种情形的区别（将状态的改变视为参考点）：第一种情况出现在Client收到DHCPOFFER并进入SELECTING状态    之后，Client向感兴趣的Server发送DHCPREQUEST报，此时的消息报需要填充Server identifier, Request ip address等选项内容，结合后面马上要讲到的DHCP选项内容，一定要注意Server identifier填充的是server的标识符，Request ip address填充的是服务器在发送的DHCP OFFER消息报中附带的IP地址信息；第二种情况是当客户机发生状态 改变，如重启时需要跟服务器确认之前分配的IP地址是否依然可用，此时Client    处于INIT-REBOOTING状态并发送DHCPREQUEST消息报，注意此时消息报中依然 需要填充Request ip address选项，但是填充的内容则是0.0.0.0(known network address), 并且此时也不需填充Server identifier选项；第三种情况则出现在Client正处于BOUND状态并需要延长租 约时，向Server发送DHCPREQUEST消息报，不过此时不应该含有Server identifier以及Request ip address选项内容信息，增加的则是client  ip address(ciaddr)信息。

     表3只是列出了DHCP消息报的属性及行为内容，但是对消息报中应该包括的字段或者选项内容却涉及很少，下面将按照消息报的类型，列出各自应该包括的内容。

表4 DHCP消息报填充字段与选项

Type	Client	Server
DHCPDISCOVER	必须包含的字段有：`xid`,`secs`,`flags`,`ciaddr`,`chaddr`,,其它字段可选；对于选项内容，不能包括的是`server identifer`,其它可选。	N/A
DHCPOFFER	N/A	必须包含的字段有：`xid`, `yiaddr`, `siaddr`, `flags`, `giaddr`, `chaddr`,其它可选；对于选项，必须包括:`ip address lease`, `server identifier`,不能包含的是`request ip address`, `parameter request list`以及`client identifier`,其他可选
DHCPREQUEST	必须包含`xid`,`secs`,`flags`,`ciaddr`,`chaddr`,`chadrr`等字段，而对于`sname`,`file`,`options`等字段是可选的。至于选项内容，`request ip address`必须包含，`server identifer`在仅仅当客户机请求处于第一种情形，必须包含。其他选项均是可选的。	N/A
DHCPACK	N/A	必须设置同之前发送给客户机OFFER消息报中相同的字段和选项内容，另外再加上客户机REQUEST消息报中所请求的参数内容消息
DHCPNAK	N/A	必须包含’client identifer’选项，或者错误报告选项
DHCPDECLINE	必须填充`xid`,`ciaddr`(0), ‘chaddr’等字段，同时必须包含`request ip address`选项，可能包含`client identifer`选项，不能包含的有：`IP address lease time`, `vendor classidentifer`, `parameter request list`等选项	N/A
DHCPRELEASE	同DHCPDECLINE，但是此时不能包括`request ip address`	N/A
DHCPINFORM	同DHCPDISCOVER，但是`request ip address` 和`ip address lease`布恩那个包含	N/A

上表详细列出了DHCP的消息报填充字段与选项信息，但有几点值得注意的是：

◆     各种消息报的`msg type`字段是一定包括的，在上表没有写出。

◆     DHCPREQUEST消息报中能否包含`server identifier`，主要跟客户机何时发出这种请求消息报有关，若是从初始状态开始发出请求报，则必须包含，  若是基于状态改变或者申请延长租约等因素发出请求报，则不能包含。

◆    在各种消息报中，若客户机与DHCP服务器不在同一网段，此时必须加上`giaddr`字段信息。

 下面主要阐述在DHCP6中各种消息报的属性、行为内容以及需要填充的字段与选项。

表5  DHCP6消息报详细信息

Type（registry code）	From	To	How and when to use	Client behavior	Server behavior
Solicit (1)	客户机	服务器/中继代理	客户机给服务器发送solicit消息，以便得到Ipv6地址，以及选项中所附带的配置参数	创建solicit消息报并将其发送给服务器	1. 首先验证solicit消息的有效性，若消息报中没有包含`client identifier`或者包含有`server identifier`选项，则该报无效并舍弃； 2. 根据管理策略来验证服务器是否允许接收该报; 3.若服务器拥有可以分配的地址，则回发Advertise消息报(状态码为成功)，否则回发状态码为` NoAddrsAvail `的Advertise消息报。 4. 若socilit消息报中包含有`rapid commit`选项，则返回一个Reply消息报.
Advertise (2)	服务器/中继代理	客户机	回应客户机发送的solicit消息报	1. 验证Advertise消息报的有效性: 若出现消息报中不含有`server identifier`字段和`client identifier`字段, `client identifier`字段中的DUID不匹配或者` transaction-id ``字段不匹配等情形，则该报无效并舍弃; 若包含状态码选项值为` NoAddrsAvail `,同样丢弃该报; 2. 基于某种策略（后面将有详细介绍）选取Advertise消息报;	给客户机发送advertise消息报，报中包含一些设置的字段与选项
Request (3)	客户机	服务器/中继代理	客户机请求更多的配置参数	创建并发送request消息报给服务器	1. 首先验证request消息的有效性：若消息中不包含`client identifier`选项`和server identifier`选项,，或者选项中的DUID内容与服务器不匹配，则该报无效并舍弃; 2.若无可用的地址分配，则返回一个状态码为` NoAddrsAvail `的Reply消息; 3.  若服务器发现在IA选项中的地址前缀与自身不匹配，则返回一个状态码为`NotOnLink`的Reply消息报; 4.创建一个Reply消息报，其中包括客户机所需要的地址以及其他参数配置信息。
Confirm (4)	客户机	服务器/中继代理	由于客户机的状态发生变化，发送confirm消息报去确认是否之前的配置是否还适合	当客户机出现以下情形时:重启，客户机改为有线连接，客户机改变了无线接入点。此时客户机需要发送confirm消息进行确认	1.        舍弃掉任何没有包含`server identifier`和`client identifier`选项的消息报; 2.        判断消息报中的IA选项中的地址是否与自己同属一个链路，若是，返回一个状态码表示为为成功的Reply消息报; 否则返回一个状态码为NotOnLink的消息报；
Renew (5)	客户机	服务器/中继代理	要求服务器延长之前分配的租约以及升级其它的参数	创建并发送Renew消息报	1.  舍弃掉任何没有包含`server identifier`和`client identifier`选项，或者`server identifier`选项中的DUID与服务器不匹配的消息报; 2.  验证消息保证中`IA`选项中地址是否与服务器中的存储信息吻合，若没找到对应信息，则返回状态码为`NoBinding`的Reply消息报; 3. 返回包含新的lifetime, T1/T2值的Reply消息报给客户机
Rebind (6)	客户机	服务器/中继代理	要求服务器延长之前分配的租约以及升级其它的参数，注意这个消息报只有在之前客户机发送的Renew消息报没得到服务器响应后才产生	创建并发送Rebind消息报	1.舍弃掉任何没有包括`server identifier`和`client identifier`选项的Rebind消息报; 2.若在服务器中没有找到与Rebind消息报中的IA选项中吻合的地址，或者发现地址但不再适合本链路，则服务器发回一个ilifetime置为0的Reply消息; 3. 若找到吻合的地址信息，服务器发回一个包含新的lifetime以及T1/T2值的Reply消息报。
Reply (7)	服务器/中继代理	客户机	当服务器收到客户机发送的Solicit(含rapid commit选项),Request, Renew以及Rebind消息时，产生Reply消息报回应
Release (8)	客户机	服务器/中继代理	客户机发送Release消息报告知服务器自己所分配的一个或者多个地址不再使用时产生Release消息报	创建并发送Release消息报，值得注意的是，释放掉的地址不能再使用，若没有收到Reply反馈消息报，则实现重传。	1. 舍弃掉任何没有包含`server identifier`和`client identifier`选项，或者`server identifier`选项中的DUID与服务器不匹配的消息报; 2. 服务器从Release消息报IA选项中的地址列表中找出有效的地址(即是由本服务器之前分配的)，并将这些地址标记为available; 3. 返回一个Reply反馈消息报; 4.  服务器保留分配信息，以备下次直接将配置信息赋给这台客户机.
Decline (9)	客户机	服务器/中继代理	客户机发送Decline消息告知服务器自己所分配的地址已经被本链路的其它主机占用	创建并发送Decline消息报,注意Decline消息报的`IA`选项中一定含有被占用的地址信息	1. 舍弃掉任何没有包含`server identifier`和`client identifier`选项，或者`server identifier`选项中的DUID与服务器不匹配的消息报; 2. 服务器检测Decline消息报中IA选项报告的地址，并将其删除，然后在本地做标记，下次将不再分配给其它客户机 3. 处理完地址后，返回带有状态码的Reply消息
Reconfigure (10)	服务器/中继代理	客户机	服务器通过发送Reconfigure消息去告知客户机，服务器端出现新的配置参数或者某些参数已经更新，并触发客户机同服务器共同去完成Renew/Reply和Information-request/Reply	1. 首先验证消息报的有效性：若消息报不是单播传给客户机;没有包含`server identifier`和`client identifier`,消息中没有包含`Reconfigure message`选项，消息中包含`IA`选项并且`Reconfigure meaasge`选项的消息类型是` INFORMATION-REQUEST `,则将该消息报舍弃; 2.客户机返回一个Renew或者Information-request消息报	创建并发送Reconfigure消息报，若在某个时间范围内，没有收到来自于客户机的Renew或者Information-request消息，则服务器重传该消息报
Information-request (11)	客户机	服务器/中继代理	客户机发送该消息报给服务器，仅仅为了得到配置参数，而不需要分配地址	创建并发送Information-request消息报，若没收到Reply反馈消息,则重传消息报	1. 验证消息报的有效性，若消息报中包含`server identifier`并且选项中的DUID与本地服务器不匹配,或者包含IA选项，则将该报舍弃; 2.构造一个包含配置信息的Reply消息报并发送给客户机
Relay-forward (12)
Relay-reply (13)

上表详细列出了DHCP6消息报的属性以及行为内容，有几个特别需要说明的地方是：

◆     对比，DHCP消息报，DHCP6在中继代理方面增加了消息报，以及其它一些机制，这方面的知识将在后面还会比较到。

◆     在`IA_NA`选项中，定义了多种状态码，分别为：

Name	Code	description
Success	0	表示成功
UnspecFail	1	表示出现不知原因的失败
NoAddrsAvail	2	表示服务器没有可用的地址去分配客户机
NoBinding	3	表示服务器没有绑定客户机信息
NotOnLink	4	表示服务器与客户机的地址前缀不匹配，即二者不在同一链路上
UseMulticast	5	表示服务器强制客户机使用 All_DHCP_Relay_Agents_and_Servers多播地址去发送消息

 

 

 

 

 

 

 

 

 

◆     在DHCP6中，客户机去选取连接DHCP6服务器是基于某种策略的，具体跟服务器所返回消息报中的`prefere option`有关，在这个选项中定义了服务器参考值(server                   prefere value)，它的最大值为255, 客户机正是根据服务器中的参考值不同选取目标服务器的，具体策略如下：

        ●     若某个服务器中的参考值为255，则它拥有最高优先级;

        ●     若服务器中的参考值正好相等，则根据对服务器返回的配置参数的兴趣而定;

       ●     客户机甚至会选取某些尽管参考值较低但返回更匹配的配置参数的服务器。 值得注意的是，在DHCP中，一般会选取最先返回配置参数的服务器！

表6列出了DHCP6消息报的填充字段以及选项。

表6  DHCP6消息报填充字段与选项

Type	Client	Server
Solicit (1)	填充`msg-type`, ` transaction-id `字段，必须包含的选项有：` Client Identifier`,`IA-NA/TA`,可选的有:` Option Request`,` Reconfigure Accept `和`rapid commit`. 另外还有注意，客户机发送solicit消息时采用的是本地链路地址，而目的地址是” All_DHCP_Relay_Agents_and_Servers address”多播地址,即ff02::1:2	N/A
Advertise (2)	N/A	填充`msg-type`字段，` transaction-id `字段来自于客户机发送的solicit消息报中的相应字段值。必须包含的选项有：`server identifier`, `client identifier`, `IA`选项(注意IA选项的数量由silicit消息报中的`IA`选项而定)以及客户机中的`optional request`选项中含有的一些选项。可选的有：` Preference `, ` Reconfigure Accept `, ``
Request (3)	填充`msg-type`, ` transaction-id `字段,必须包含的选项有：`server identifier`, `client identifier`, ` Option Request `,`IA-NA/TA`,可选的有：` Reconfigure Accept `以及其它选项，注意请求时的目的地址以及多播地址同solicit消息报。	N/A
Confirm (4)	填充`msg-type`字段，并产生` transaction-id `字段内容，必须包含的选项有：`client identifier`, `IA`(对于IA_NA选项，应该设置T1,T2域，以及preferred-lifetime and valid-lifetime域)	N/A
Renew (5)	填充`msg-type`字段，并产生` transaction-id `字段内容，必须包含的选项有：`client identifier`, `server identifier`, `IA`, ` Option Request `以及其他可选项	N/A
Rebind (6)	填充`msg-type`字段，并产生` transaction-id `字段内容，必须包含的选项内容有：`client identifier`, `IA`, `option request`	N/A
Reply (7)	N/A	1.   若是对solicit消息报(包含`rapid commit`选项)的回复：必须填充字段`msg-type`和` transaction-id `字段（来自于solicit消息报），必须包含的选项有：server identifier`, `client identifier`, `IA`以及request消息报中所请求的参数选项, `rapid commit`。 2.   若是对Request消息报的回复：必须填充字段`msg-type`和` transaction-id `字段（来自于request消息报）,必须包含的选项有:`server identifier`, `client identifier`, `IA`以及request消息报中所请求的参数选项; 3.   若是对Confirm消息的回复：填充`msg-type`字段，` transaction-id `字段来自于客户机发送的solicit消息报中的相应字段值。必须包含的选项有:`server identifier`, `client identifier`, `status code` 4.   若是对Renew消息的回复：填充`msg-type`字段，` transaction-id `字段来自于客户机发送的solicit消息报中的相应字段值。必须填充的选项有：`server identifier`, `client identifier`,,`IA` 5.   若是对Rebind消息的回复：填充`msg-type`字段，` transaction-id `字段来自于客户机发送的solicit消息报中的相应字段值。必须填充的选项有：`server identifier`, `client identifier`,,`IA` 6.   若是对Release消息的回复：填充`msg-type`字段，` transaction-id `字段来自于客户机发送的solicit消息报中的相应字段值。必须填充的选项有：`server identifier`, `client identifier`, `IA`(包含状态码选项) 7.   若是对Decline消息的回复：填充`msg-type`字段，` transaction-id `字段来自于客户机发送的solicit消息报中的相应字段值。必须填充的选项是：`server identifier`, `client identifier`, `IA`(包含状态码选项)
Release (8)	填充`msg-type`字段，并产生` transaction-id `字段内容,必须包含的选项有：`client identifier`, `server identifier`, `IA`	N/A
Decline (9)	填充`msg-type`字段，并产生` transaction-id `字段内容,,必须包含的选项有: `client identifier`, `server identifier`, `IA`	N/A
Reconfigure (10)	N/A	填充`msg-type`字段，并将` transaction-id `设置成0；必须包含的选项有:`server identifier`, `Reconfigure message`, `IA`, `Option request`则是可选的,其他的选项则都不能使用
Information-request (11)	填充`msg-type`字段，并产生` transaction-id `字段内容,必须包含的选项有：`option request`, `client identifier`	N/A
Relay-forward (12)
Relay-reply (13)

      

 

2. 两种版本的选项格式比较：

DHCP:

       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

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |   option-code  | option-len    |                              |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-                             +

      |                          option-data                          |

      |                      (option-len octets)                      |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Fix-length options: option 0 and option 255 are considered as without data, so it only includes option-code filed.

Variable-length options(except fix-length option): must follow a option-len field and the field value only specifies the size of option-data field, not include the size of option-code and option-len fields.

These options are encoded as a one-byte type code, a one-byte length, and a buffer consisting of the number of bytes specified in the length, from zero to 255. In RFC 3396, provides a rule how to concatenate(decode) and split(encode) option field when the option-len excedes 255 octets in size.

【注意】这个地方与DHCPV6存在着不同的处理方式，RFC 3396定义了如何处理当同code的选项数据被split并出现在不同的域内(field,主要有option, file和sname)时如何将它们连成一个单独的选项的规则；而在RFC 3315中则规定(section 22.1),当出现多个同code的选项时，它的选项数据是不能够联合在一起的，这也是跟二者所定义的选项内容结构差异密切相关的。

DHCPv6：

       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

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |          option-code          |           option-len          |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |                          option-data                          |

      |                      (option-len octets)                      |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

DHCP与DHCPV6常见的支持选项:

 

DHCP常见支持选项 (Public-defined options in DHCP)

Option Name	Code	Len (octet)	MAY, Must or Must not include	Function
pad	0	1	All MAY	align a subsequent field on a word (two-byte) boundary
end	255	1	All MUST	Placed after all other options to mark the end of the option list
Subnet Mask	1	4		Specific the client's subnet mask
Router	2	variable( multiply of 4)		Specifies a list of router addresses for the client to use  on the local network
Domain name server	6	variable( multiply of 4)		Specifies a list of domain name servers available to client
Host name	12	variable( multiply of 4)		Specifies a list of DNS name server addresses for the client to use on the local network
Network Time Protocol Servers	42	variable( multiply of 4)		Specifies a list of IP addresses indicating NTP servers available to the client.
Requested IP Address	50	4	Must:  DHCPREQUEST(when in SELECTING or INIT-REBOOT state), DHCPDECLINE, DHCPNAK MUST NOT: DHCPREQUEST(when in BOUND or RENEWING state), DHCPRELEASE, DHCPINFORM	Allow the client to request that a particular IP address be assigned
IP Address Lease Time	51	4	Must: DHCPOFFER, DHCPACK MUST NOT: DHCPINFORM, DHCPDECLINE, DHCPRELEASE	Allow the client to request a lease time for the IP address.
DHCP Message Type	53	1	All MUST	Specifies the type of the DHCP message
Server Identifier	54	4	MUST: DHCPREQUEST(when in SELECTING state), DHCPDECLINE, DHCPRELEASE, DHCPACK, DHCPNAK, DHCPOFFER MUST NOT: DHCPDISCOVER, DHCPINFORM	Specifies the ip address for the selected server to client
Parameter request list	55	variable	MAY: DHCPDISCOVER, DHCPREQUEST	Used by a DHCP client to request values for specified configuration parameters
Message	56	variable	MAY: DHCPNAK	Used by a DHCP server to provide an error message to a DHCP client in a DHCPNAK message in the event of a failure
Maximum DHCP message size	57	2	ALL MAY	Specifies the maximum length DHCP message that  it is willing to accept
Renewal Time Value (T1)	58	4		Specifies the time interval from address assignment until the client transitions to the RENEWING state.
RebindingTime Value (T2)	59	4		Specifies the time interval from address assignment until the client transitions to the REBINDING state.
Vendorclassidentifier	60	variable		Used by DHCP clients to optionally identify the vendor type and configuration of a DHCP client. such as “udhcpc 1.21.1”
Client identifier	61	variable	MUST: DHCPOFFER, DHCPACK, DHCPNAK	Used by DHCP clients to specify their unique identifier, usually consist of a hardware type (htype) and hardware address (chaddr).

 

 

DHCPV6 常见支持选项

Option Name	Code	Len (octet)	MAY, Must or Must not include	Function
Client identifier(RFC 3315)	1	Variable(equal to DUID)	Must:	Used to carry a DUID identifying a client between  a client and a server
Server identifier(RFC 3315)	2	Variable(equal to DUID)		Used to carry a DUID identifying a server between a client and a server
IA_NA(RFC 3315)	3	12(IAID+T1+T2) + length of IA_NA options		Used to carry an IA_NA, the parameters associated with the IA_NA, and the non-temporary addresses associated  with the IA_NA.
IA_TA(RFC 3315)	4	4(IAID) + length of IA_TA options		Used to carry an IA_TA, the parameters associated with the IA_TA and the addresses associated with the IA_TA.
IA address(RFC 3315)	5	16(IPV6 address) + 4(prefered-lifetime) +4(valid-lifetime) + length of Iaaddr-options		Used to specify IPv6 addresses associated with an  IA_NA or an IA_TA.
Option request(RFC 3315)	6	2 * number of request options (each option needs two octets )		Used to identify a list of options in a message between a client and a server
Preference(RFC 3315)	7	1(pref-value)		Sent by a server to a client to affect the selection of a server by the client.
Elapsed time(RFC 3315)	8	2		Sent by client to indicate how long the client has been trying to complete a DHCP message exchange
Status code(RFC 3315)	13	2(status code) + length of status-message		Returns a status indication related to the DHCP message or option in which it appears
Rapid commit(RFC 3315)	14	0		Used to signal the use of the two message exchange for  address assignment
Vendor class(RFC 3315)	16	4(enterprise-number) + length of vendor-class-data		Used by a client to identify the vendor that manufactured the hardware on which the client is running
Reconfigure message (RFC 3315)	19	1(msg-type)		Included in server and to indicate to the client whether the client responds with a Renew message or an Information-request message
Reconfigure accept  (RFC 3315)	20	0		Announce to the server  whether the client is willing to accept Reconfigure messages, and a server uses this option to tell the client whether or not to accept Reconfigure messages.
IA_PD(RFC 3315)	25	12(IAID + T1 + T2) + length of IA_PD options		Used to carry a prefix delegation identity association
IA_PD prefix (RFC 3633)	26	4(prefered-lifetime) + 4(valid-lifetime) + 1(prefix-length) + 16(IPV6 prefix)		Used to specify IPv6 address prefixes associated with an IA_PD
DNS Recursive Name Server (RFC 3646)	23	A multiply of 16 octets (each IPV6 address)		Provides a list of one or more IPv6 addresses of DNS recursive name servers to which a client's DNS resolver MAY send DNS queries
Information Refresh Time (RFC 4242)	32	4		Used from server to client to inform the client when it should refresh the other configuration data