IPv6下DHCPv6协议(RFC3315)详细介绍

最新推荐文章于 2024-03-23 17:16:57 发布
最新推荐文章于 2024-03-23 17:16:57 发布
阅读量1.3w 收藏 76
点赞数 14
分类专栏： IETF-RFC 网络标准协议 DHCP 文章标签： 网络协议 经验分享
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Kuaisen/article/details/118675607
版权

DHCPv6 详细介绍

前言

DHCP(Dynamic Host Configure Protocol)即动态主机配置协议，按照IP协议种类分为DHCPv4和DHCPv6。其中DHCPv4叙述在一下文章中聊过。
DHCP介绍（DHCP交互过程以及相关抓包分析）
补充：对DHCP协议的报文细节补充
RFC 2132 的 DHCP Options
DHCP relay的工作过程以及DHCP option82的作用
这里主要讲述的是DHCPv6，包括基础部分介绍封包类型，基本的地址请求过程。进阶部分会详细介绍各种封包交换情况，以及部分基本的option等。
说明：
 1）文章中提到的client和server指的的dhcpv6-client和dhcpv6-server;
 2）对于dhcpv6-relay以及dhcpv6认证方面没有做描述(option以及封包交互)；
 3）参考RFC3315。目前关于DHCPv6的最新的是的RFC8415，最新的多包括一些option以及其他的描述；
 4）如认为有什么疑问，欢迎讨论；
 5）仅供参考，如有必要可以去阅读RFC文档。

一、基础部分

1、多播地址
  Server一般是单播发送封包，源地址和目的地址使用link-local地址。DHCPv6 client发包目的地址一般使用组播地址，源地址和单播的地址一致使用link-local地址，如果没有那就使用::(表示全0)。Client使用的两个特殊的组播地址;
  1）FF02::1:2
    表示目标为所有的DHCPv6 Server和DHCPv6_Relay，一般为client使用去定位server或者relay
  2）FF05::1:3
    表示所有的Server，一般为relay使用，去定位server以转发来自client的数据包
   注：client发送不一定都是组播发送的，如果server同意client可以单播，那么client就可以直接单播和server交互了。
  后面有叙述
2、DHCPv6 端口号
  Client监听UDP端口号546，server监听UDP端口号547，即DHCPv6是基于UDP协议的。
3、DHCPv6的封包类型和简易描述
  介绍数据包类型，简单描述一下各个封包的作用，详细的后面继续说到。

类型（值）(msg_type(value))发送方(sender)描述(description)
Solicit(1)client配置请求开始，client发送solicit定位server，确定当前环境是否存在server
Advertise(2)server收到solicit后，server发送advertise以表明自己可以提供dhcp的服务
Request(3)clientClient收到advertise后，根据条件选择一server,发送request去请求相关配置以及ipv6地址等
Confirm(4)client当client的当前链路环境变化，client向server发送confirm去确认当前地址是否仍然可以使用
Renew(5)clientClient为了延长当前配置和地址的使用时间，向server发送renew表示延长配置和地址的使用时间或者更新当前配置
Rebind(6)client和renew类似，也是为了延长配置的使用时间，不同的是：1）renew向特定server发送，rebind向任意server发送;2）当renew没有被回复后client才会发送rebind
Reply(7)serverServer发送reply以回应client的solicit,request,renew,rebind,inform-request,confirm,release 以及decline。具体情况下述说明
Release(8)clientClient发送release表示当前分配的地址自己不再使用
Decline(9)clientClient发送decline表示server分配的地址已被其他节点使用，不能再分配出来
Reconfigure(10)serverServer发送reconfigure表示当前配置已经更新，想要client更新最新的配置
Inform-request(11)clientClient发送inform-request表示向server请求除了地址之外的其余配置信息
Relay-forw(12)relayRelay向server或者其他relay转发client/relay的信息
Relay_repl(13)serverServer向relay发送Relay_repl，包含了server对client的reply封包信息

4、client和server信息交换的方式
 Client和server进行信息交换的两种方式，根据上述表格和描述，可以得到两种方式:
 1）two-message
 一般client用来更新某些配置信息，server回复reply，完成一次信息交换。例如：

  •  Inform-request/reply,client请求/更新除IP地址之外的其他信息。
  •  Solicit/reply,这个比较特殊，用于快速配置ip地址信息，client需要携带特殊信息，表示需要server立即分配地址给client使用，特点就是速度快。
  •  Renew,rebind/reply,client延长地址分配时间，向server发送renew/rebind
  •  Release/reply,client不再使用分配的地址，向server表示不需要维护当前绑定状态。
  •  Decline/reply,分配的地址不能使用，client发送decline，server之后不会再分配该地址。

 2）four-message

  通过四步完成地址请求过程，solicit->advertise->request->reply。在定位server阶段，client组播solicit，分别由两个server收到，同时回复advertise，此时client选择其中一个（如何选择见下述）。之后client发送request请求地址和配置信息，相应的server回复reply。Server2收到request没有回信息，因为client带有选择的server标识，server2检查和自己不匹配，不会回复。更加详细的叙述见下述。

5、数据包格式(msg_format)

 1) msg_type:如上述表格所表示的类型以及括号里的value,表示封包类型
 2) Transaction_id:直译就是业务标识，主要用于client和server用于信息检查。由client随机生成，然后传输数据包时，添加进数据包，server在回复对client的请求时把cllient发送来的transaction_id拷贝到相应字段，client收到server的回复后，会检查transaction_id是否和发出的一致，否则抛弃收到的数据包。
 3) Options:为了适用于更多应用，采用TLV格式的option，根据client端选择/请求，server给予对应的服务信息。Option散布在很多RFC文档，随着应用的不断更新option也在不断的更新。一些基本的option会在后面叙述。

二、DHCPv6的进阶

  根据第一节的描述，大概了解了dhcpv6是干什么的，数据包的类型，数据包的格式以及一个获取ipv6地址和配置基本交互过程，下面更近一步了解DHCPv6的相关概念和细节处理。

1、相关术语/概念(Term)

 1）DUID(DHCP Unique Identifier)
  直译就是DHCP唯一标识。client和server都有一个唯一的DUID.server使用DUID来标识给client分配的 地址和配置信息，根据DUID就可以查找到给这个client分配了什么参数。Client使用DUID去定位一个server，当更新信息等，使用DUID去请求指定的server。DUID以option的方式附加在DHCPv6封包中，理由是：DUID长度可变，并且并不是所有的数据包都需要DUID的信息，这样更灵活节省流量。Unique规定DUID必须是唯一的，需要保证DUID从设备出厂就是唯一的。下面介绍一下DUID的几种类型：
  DUID的格式中包含两字节的类型字段(DUID_type)：

DUID_type(类型)Description(描述)
1链路层地址(MAC地址)+时间(DUID_LLT)
2厂商的唯一ID标识(DUID_EN)
3链路层地址(DUID_LL)
4（RFC6355）UUID(Universally Unique IDentifier)通用唯一标识符

  (1) DUID_LLT
    链路层地址(link-layer address)加时间(time)，格式：

  •  Type:2字节，value为1;
  •  Hardware type:2字节，硬件类型
  •  Time:4字节，由2000.1.1起生成的DUID时间,单位秒
  •  Link-layer address:mac地址

  (2) DUID_EN
    厂商唯一标识符，包括IANA分配给生产商的ID(enterprise number)以及生产商分配给设备的ID(identifier)构成，格式如下：

  •  Type:2字节，value=2
  •  enterprise number:IANA分配给厂商的表示，32bits
  •  Identifier:厂商分配给设备的表示，长度可变

   (3) DUID_LL
   链路层地址，格式如下：

  •  Type:2字节，value=3
  •  Hardware type:2字节，硬件类型
  •  Link-layer address:mac地址

  (4) DUID_UUID
   UUID:通用唯一标识，简单理解是给设备/应用使用的唯一标识，能保证唯一性。DHCPv6在;RFC6355中提出使用UUID作为DUID的组成，UUID的描述在RFC4122中，感兴趣的可以去看一下。格式如下：

  •  Type:2字节，value=4
  •  UUID:128bits，唯一标识符

 2）IA(Identity Association)
  可以被叫做身份联盟/身份联系，也即是标记身份的ID号。主要用于client和server用于识别、管理和组织相关的配置(比如IPv6地址，PD前缀信息等)。每个IA的组成包括IAID及其相关信息。常见IA类型有：

  • IA_NA
     表示向server请求该ipv6地址。
  • IA_TA
     Temporary Addresses，表示client向server请求临时地址。
  • IA_PD
     Prefix Delegation(前缀分配)，表示client请求server分配前缀信息。
    说明：
     (1)上述三种类型均为dhcpv6的option
     (2)相关类型的IAID均由client自动生成，但是需要保持IAID在同一类型中的唯一性，也就是同一类型中不能出现相同的IAID。
     (3)client填充上述类型，表示向server请求相关信息
     (4)Server收到封包后，通过IAID标记给client分配出去的信息
     (5)Client收到server的回复后，也通过IAID标记从server的得到的相关信息

 3）Status Code
  状态码。主要作用是server用来说明client或者server请求的option或者message的情况。具体使用是在Status Code option中，见后述option。这里说明Status Code的作用和类型。

Status Name(状态名)Status Code(状态码)Description(描述)
Success0表示成功
UnSpecFail1失败但是原因未知
NoAddrsAvail2表示server没有可以分配的ipv6地址。一般用来说明几个请求地址的option
NoBinding3client处于未绑定状态，当server收到renew/rebind后，会检查该client是否绑定在列表中，如果没有则返回此状态
NotOnLink4地址前缀不适合当前client所在的链路。主要用于在client链路改变时候，向server发送Confirm封包，如果当前分配的地址不适合client的时候，server回复此状态
UseMulticast5强制client使用广播发送封包，主要用于在server没有指示client可以使用单播时，如果client使用单播发送，那么server会回复此状态

 说明：
 （1）这些Status Code仅仅是定义在RFC3315中的
 （2）Status Code和随着option不断更新，在其他option RFC中，会额外定义其他 的Status Code。

2、几个相关的算法/规则

1）client封包重传算法
  Dhcpv6是基于UDP的，所以可能出现封包丢失的情况，client需要提供封包的重传，以保证dhcpv6的正常工作。以下定义相关参数和算法描述：
 (1) 参数

Parameter(参数)Description(描述)
RTRetransmission timeout:重传超时时间
IRTInitial retransmission timeout:初始的超时重传时间
MRCMaximum retransmission count:最大重传次数
MRTMaximum retransmission timeout:最大重传超时时间
MRDMaximum retransmission duration:最大重传间隔
RANDRandomization factor:重传随机因子 (-0.1~+0.1)

 (2) 描述
  对于封包重传，需要确定几个问题，封包是否有重传上限、封包的重传间隔时间、如果有上限，上限条件是什么？

  •  首先第一个问题：封包是否有重传上限
     对于有些封包没有没有重传上限，封包类型有solicit。其他类型封包均有重传上限。
  •  第二个问题：封包的重传间隔时间
     算法描述了每一种类型封包，上一包和下一包重传的间隔时间，计算如下：
     第一次重传时间间隔：
     RT = IRT + RANDIRT
     后续重传时间间隔：
     RT = 2    RTprev + RANDRTprev
     RT不能大于MRT，如果大于MRT:
     RT = MRT + RAND    MRT
  •  第三个问题：封包重传上限条件
     条件有两种，一是定义的最大重传次数(MRC)，二是最大重传间隔时间(MRD)，只要在重传过程中，满足条件之一，就表示重传失败，不会再传输这种封包。判断方法如下：
     对于MRC，client在进行重传时，每发送一次，计数+1，直到大于MRC，重传失败。
     对于MRD，一种类型的封包连续重传时间的和不能超过MRD，即如果RT1+RT2+RT3+……>MRD，那么重传失败。

 (3) 每一种封包的具体重传参数

Message type | ParamIRT(value)MRC(value)MRT(value)MRD(value)
SolicitSOL_TIMEOUT(1s)0SOL_MAX_RT(3600s)
RequestREQ_TIMEOUT(1s)REQ_MAX_RC() REQ_MAX_RT(30s)
ConfirmCNF_TIMEOUT(1s)0CNF_MAX_RT(4s)
RenewREN_TIMEOUT(10s)0REN_MAX_RT(600s)
RebindREB_TIMEOUT(10s)0REB_MAX_RT(600s)
Inform-requestINF_TIMEOUT(1)0INF_MAX_RT(3600s)
ReleaseREL_TIMEOUT(1)REL_MAX_RC(4)0
Decline DEC_TIMEOUT(1)DEC_MAX_RC(4)00

  注 ：表格中0表示没有定义此参数，也就是忽略。

2）Advertise的选择
  根据上述四步流程，当client发送solicit的时候，可能不止一个server回复advertise，那么在如何选择一个advertise。Dhcpv6 option有一个叫做Preference Option(优先option)，一个字节大小的整型数据。通过这个值根据以下条件选择：

  • 当前advertise封包中preference值最大的为最优先
  • 如果preference值相同，那么client会选择自己感兴趣的，比如advertise带有的option是client需要的，那么可能会优先选择。
  • 或者如果有自己感兴趣的option，也会直接选择，而不看preference值。
    Client选择一个advertise后，会保存下来当前收到的可用的advertise的值， 作为备用server服务器，当当前选择的server无法回复或者满足client的 时 候， client就会从备选server中选择一个继续请求。

3）Renew/rebind时间的计算
  Renew和rebind的时间是用来在到时后，发送renew/rebind封包，用于延长client的配置信息。这里需要稍微超前一下，了解一下IA_NA的option的格式：

 这里主要了解几个参数就可以，其他参数在后面后叙述。
 T1:4个字节，一般用来指定发送renew的时间
 T2:4个字节，一般用来指定发送rebind的时间
 preferred-lifetime:4字节，首选生存时间，主要用来计算的。
 valid-lifetime:4字节，有效生存时间，地址信息的最大使用时间。
 如下计算renew和rebind的时间：
  ①　如果T1和T2都不为0，并且T1<T2，那么T1和T2分别作为renew和rebind的时间。否则认为T1和T2时间无效，需要重新计算，转到4
  ②　如果T1为0，T2不为0，那么renew为preferred-lifetime的0.5倍，rebind 为T2，如果T1>T2，则认为无效需要重新计算，转到4
  ③　如果T1不为0，T2为0，那么renew为T1，rebind为preferred-lifetime的0.8倍。如果T1>T2那么认为无效，重新计算时间，转到4
  ④　如果T1和T2都为0，或者计算时间无效。Renew为preferred-lifetime的0.5倍，rebind是preferred-lifetime的0.8倍。

3、Message交换过程详述

1）地址初始请求过程

定位server:
 （1）client端
  发送solicit：
   填充msg_type，transaction id以及必要的option。其中option1(client Identifier)和option 3(IA_NA)必须填写，因为在这里是请求地址，所以必须需要option3。组播（组播地址如上述）发送，重传算法按上述所述。
  接收advertise：
   如上图，client可能收到不止一个server发送来的advertise，此时根据上述所说的选择其中一个client最感兴趣的。检查封包合法性，检查transaction id是否和solicit一致。记录option3，server的identifier。
 （2）server端
  接收solicit：
   收到solicit，进行封包检查，包括目的地址，option，是否有携带非法的option。然后解析封包，根据solicit的option，来判断client需要什么配置。
  发送advertise：
   解析到client需要地址，Server端需要检查自己的地址池中，是否有空余地址用于分配，如果没有则不予分配。解析其他option，相继填入所需配置信息。填充msg_type，复制solicit的transaction id作为transaction id，填充其他option，其中要包括option2(server identifier)，option5(IA_Address)，填充分配的地址和时间信息。单播发送封包。

地址请求和分配：
 （1）client端
  发送request：
   填充msg_type，重新生成transaction id，填充option，特别的option1,option3(表示指定当前选定的server)，组播发送，重传算法如上述。
  接收reply；
   检查封包，检查server identifier，检查transaction id是否和request的一样，解析option，使用DAD检查地址是否可用，如果可用则配置从reply得到的地址信息和其他配置信息，计算renew,rebind，启动定时器。
 （2）Server端
  接收request：
   检查封包，特别检查option3，是否是给自己的请求，否则丢弃。将client，加入到绑定列表。
  发送reply：
   填充msg_type，复制request的transaction id作为transaction id，填充必要的option。从地址池中分配一地址，添加option5（IA_Address）,，填充分配的地址和时间信息，单播发送。

2）地址重新请求过程

 （1）Client
  发送renew:
   在收到server的reply之后，分配的地址带有时间限制，根据renew和rebind的时间计算得到两个时间，当renew的定时器到时后，client需要主动发送renew封包，表示续约地址的有效时间。填充msg_type，生成transaction id，特别注意填充option1,option2,option3，option5。即需要说明自己的身份（client identifier），请求的server（server identifier），和需要续约的地址信息（IA_NA），组播发送。重传按照上述算法。
  发送rebind:
   发送rebind不是必须的，如果发送的renew封包被请求的server回复reply，如第一个图。此时renew和rebind时间会被刷新。但是如果renew经过重传后，还是没有等到回复，但是rebind时间到了，那么client主动发送rebind封包，此时可认为原先请求的server没有工作或者其他原因。填充msg_type，生成transaction id，填充option，注意不需要携带option2。组播方法，重传按上述算法。
  接收reply:
   检查封包，检查transaction id，确定是否是对前一次请求的回复。解析option，根据信息更新配置信息，重新计算和设定renew和rebind时间。这里说明一下，不一定会收到reply，如果在rebind重传结束之后仍然没有收到reply，那么地址已经过期，client不可以再使用，client会采取两种策略：
  一是重新发送solicit去请求地址
  二是如果client还有可用的地址，那么就不做请求了。
 （2）Server
  接收renew:
   检查封包，检查server identifier是否是给自己的，检查client identifier是否在绑定列表中，检查IA_ID自己是否分配该地址信息。
  接收rebind:
   检查封包，检查client identifier是否在绑定列表中，检查IA_ID自己是否分配该地址信息。
  发送reply:
   填充msg_type，复制rebind的transaction id到作为封包的transaction id，更新地址的时间信息，填充其他option。单播发送reply。

3）链路变化请求过程

 链路变化的情况：
  一是Client重启
  二是线路断开重新连接
 （1）Client
  发送confirm:
   当发生上述链路变化情况后，client主动发送confirm去询问当前分配的地址还是否可用，填充msg_type，生成transaction id，填充option，其中需要的有option1（client identifier）,option3，option5（分配的地址信息），组播发送，重传按上述算法。
  接收reply:
   检查封包，transaction id是否和发出去的confirm的一致，解析option，如果option13的状态是Success，那么可以继续使用地址。如果状态是NoOnLink，那么应该要重新发送solicit请求，重新获取地址。注意：client也可能收不到reply，那么就默认此地址可以使用。
 （2）Server
  接收confirm:
   检查封包，通过后，分析option5的地址是否还适合client所在的链路，如果检查通过，那么回复状态Success，如果没有通过测试，那么就回复状态NoOnLink，如果server自己无法做出判断，所需信息不足，那么不予以回复。
  发送reply:
   填充msg_type，复制confirm的transaction id到transaction id，填充option，option1,option2,option13表示对confirm的回复。单播发送。

4）Server配置更新请求过程

  当server的配置更新了，会主动发送reconfigure封包去通知client更新当前地址或者配置信息。就会发生如上图的封包交换。
 （1）Client
  接收reconfigure:
   检查封包，检查option1的DUI是否匹配，检查是否有option19，解析封包，根据option19的类型，开始准备发送对应封包。
  发送renew:
   发送过程和renew时间到时，一样的过程，参考即可。
  发送inform-request:
   发送inform-request表示client只请求更新除了地址之外的配置信息。填充msg_type,生成transaction id，填充option，包括option1(client identifier)，option2(server identifier)以及option6(request option)，这里不需要请求更新ip地址信息，不需要option3等，组播发送封包。
  接收reply:
   检查封包，transaction id是否和inform-request/renew的一致，检查option，更新reply中的配置信息。
 （2）Server
  发送reconfigure:
   填充msg_type，填充transaction Id为0，填充option，其中有option1(client identifier)，option2(server identifier)，option19(reconfigure)，其中option13的value为renew或者inform-request的msg_type值，至于是renew还是inform-request，我认为是看server的配置是否改变了地址池的信息，如果是那么发送填充renew，如果只是添加了一些配置信息那么就填充inform-request，单播发送封包。
  接收renew:
   和上述接收renew的逻辑一样可参考。
  接收inform-request:
   检查封包，检查option1，option2是否正确，通过后，解析option6(request-option)，确定client需要更新的信息有哪些。
  发送reply:
   如果是否renew 回复reply，逻辑和上述一致，可参考。对于inform-request，填充msg_type，复制inform-request的transaction id到transaction id，根据解析的request-option，填充server能提供的option信息，单播发送封包。

5）其他一些情况
（1）client检查地址不能使用

 当client收到对request回复reply，含有ipv6地址的时候，client需要检查ipv6地址是否可以使用，否则就发送decline，表示此地址不可以使用。
 Server:
  发送reply(addr):
   见上述，server收到request的时候，回复reply。
  接收decline:
   检查封包，检查过后，解析封包，把不能使用的地址从地址池中移除，表示地址不可用，之后的地址地址分配不会再分配该地址。
  发送reply:
   填充msg_type，复制decline的transaction id，填充option，有option1,option2,option3和option5等。
 Client:
  接收reply(addr):
   收到reply后，检查封包，检查transaction id，检查option。解析option，解析到ipv6地址的时候，需要是使用DAD(duplicate Address Detect)，这是ND6的一种功能，感兴趣的可以了解，这里只要知道通过DAD可以检测出该地址是否可用，如果不可用说明分配的地址已被其他设备使用，不能再使用了。
  发送decline:
   填充msg_type，生成transaction id，填充option，有option1(client identifier)，option3和option5。广播发送封包，重传算法见上述。
  接收reply:
   收到reply并不需要做什么，只相当于给client的确认。Client在拒绝这个地址之后，也可采取两种方式，一是重新请求，二是如果还有地址可用，不需要请求。

（2）client 释放地址

 当client不再使用此分配的地址时（比如直接配置static地址），那么client就会执行释放地址的过程。
 Server：
  接收release:
   检查封包，检查option，核对server identifier是否是发给自己的。检查IAID，解除与client的绑定状态，将ip地址再放回地址池中。
  发送reply:
   填充msg_type，复制release transaction id并填充，填充option，包括option1，option2，option3以及option5等。单播发送。
 Client:
  发送release:
   填充msg_type，生成transaction id，填充option，其中包括option1(client identifier),option2(server identifier),option3以及option5(IA Address)等，组播发送，重传算法按上述描述。
  接收reply:
   并不需要做什么特殊行为，仅仅是server对release的回复。

4、基础的几个option介绍（RFC3315)(option 1-20）

Option的格式：

Option-code:2字节，option的代码，唯一标识一个option，范围在0-255
Option-len:2字节，value是option-data的字节数，也就是option-data的大小 要在255字节以内
Option-data:大小具体需要看每个option，option的数据区域。

1）Client Identifier Option(option 1)
（1）Format(格式):

（2）字段
 Option-clientId:即option-code，value为1
 Option-len:DUID的字节数
 DUID:如上述描述的几种类型。
（3）说明
 表明client的身份，client发送封包，基本都带有这个option，server通过这个option来标识一个client。
在这里插入图片描述

2）Server Identifier Option(option 2)
（1）Format(格式):

（2）字段
 Option-clientId:即option-code，value为2
 Option-len:DUID的字节数
 DUID:如上述描述的几种类型。
（3）说明
 Server发送封包会携带该option，以及client向特定server请求会携带，标识server的身份。
在这里插入图片描述

3）Identity Association for Non-temporary Addresses Option(option 3)
（1）Format(格式)：

（2）字段
 Option IA_NA：option code为3
 Option-len：12 + IA_NA sub-option的长度
 IAID：如上述描述，4字节，用于标识此地址
 T1：见上述描述，用于生成renew的时间
 T2：见上述描述，用于生成rebind的时间
 IA_NA sub-option：IA_NA的子option，用来描述此地址的信息或状态
（3）说明
 非临时地址option。如果client要请求NA ipv6address，那么需要携带从option， 一般不需要填充IA_NA option。Server收到这个option后，会填充相关字段，T1,T2,IA_NA sub-option。IA_NA sub-option有IA Address Option和Status Code Option。具体IA_NA sub-option见后续描述。
在这里插入图片描述

4）Identity Association for Temporary Addresses Option(option 4)
（1）Format(格式)：

（2）字段
 Option IA_TA：option code为4
 Option-len：4 + IA_TA sub-option的长度
 IAID：见上述描述，用于标识此临时地址
 IA_TA sub-option：IA_TA的子option，用于描述此临时地址的信息或状态
（3）说明
 临时地址option。如果client需要请求临时地址就携带此option，一般不需要填充IA_TA sub-options，server回复的时候，会填充IA_TA sub-options。IA_TA sub-option有IA Address Option和Status Code Option。具体IA_TA sub-option见后续描述。

5）IA Address Option(option 5)
（1）Format(格式)

（2）字段
 Option_IAAddr：option -code为5
 Option_len：24 + IAAddr-options的长度
 IPv6 Address：IPv6地址，128bits
 Preferred-lifetime：首选生存时间，单位为s
 Valid-lifetime：有效生存时间，单位为s，这个时间到期后，不能再使用配置的地址信息。
 IAAddr-options：sub-option，一般携带Status Code Option，表示此option的状态。
（3）说明
 此option只能作为IA_NA option或则IA_TA option的sub-option，不能单独出现。如果client携带此option，表示希望server尽量分配这个IPv6 Address给client。一般由server填充。
在这里插入图片描述

6）Option Request Option(option 6)
（1）Format(格式)

（2）字段
 Option_ORO：option code为6
 Option_len：2 * request-option的数目
 Request-option-code-*：2字节，表示需要请求的option的code
（3）说明
 Option请求。Client一般会在 Solicit,Request,renew,rebind,confirm,inform-request封包中包含此option，表示 希望server给client这些option。server一般会在Reconfigure封包中包含此 option，表示client应该向server请求哪些option。
7）Preference Option(option 7)
（1）Format(格式)

（2）字段
 Option_Preference：option code为7
 Option_len：1
 Pref-Value：Preference的值
（3）说明
 优先option。Server一般在Advertise封包中包含此option，client根据此值去选择Advertise，见上述描述。
8）Elapsed Time Option(option 8)
（1）Format(格式)

（2）字段
 Option Elapsed_Time：Option code为8
 Option_len：2
 Elapsed_Time：2字节，百分之一秒，即Elapsed-Time/100(s)。表示client自请求开始到现在的时间数。
（3）说明
 已用时间option。Client发送的所有封包都必须包含此option，第一个封包Elapsed-Time为0
在这里插入图片描述

9）Server Unicast Option(option 12)
（1）Format(格式)

（2）字段
 Option_Unicast：option code为12
 Option_len：16
 Server-address：收到此option后，client与server单播通信用的ipv6地址。
（3）说明
 Server单播option。Server向client发送此option，client解析到此option后，之后向该server发送的封包，都使用单播发送，目的地址为option携带的地址。
10）Status Code Option(option 13)
（1）Format(格式)

（2）字段
 Option_Status_Code：Option Code为13
 Option_len：2 + Status_Message的长度
 Status_Code：状态码，
 Status_Message：状态说明
（3）说明
 状态码option。此option可能出现在Message中或者出现在某个option中，用来说明此Message或者option的状态。一般为client请求的option，server会填充此option用于说明option的情况。
11）Rapid Commit Option(option 14)
（1）Format(格式)

（2）字段
 Option_Rapid_Commit：option Code为14
（3）说明
 快速回应Option。client发送solicit包含此封包后，server解析到，会立即回复reply，带有client的请求参数。这样只需要solicit/reply两步就可以完成信息交互。
12）User Class Option(option 15)
（1）Format(格式)

User_Class_Data Format(格式)：

（2）字段
 Option_User_Class：option code为15
 Option_len：长度为User_Class_data的长度
 User_Class_Data：长度可变，client写到的class说明
 User_Class_Len：2字节。
 Opaque_Data：Data内容。
（3）说明
 用户类说明Option。此option可以携带多个User_Class_Data。只能client使用该option，表示client所代表的用户或者应用类型。
13）Vendor Class Option(option 16)
（1）Format(格式)

Vendor_Class_Data Format:

（2）字段
 Option_Vendor_Class：option code为16
 Option_Len：4 + Vendor_Class_Data的长度
 Enterprise_Number：厂商在IANA注册的厂商编号
 Vendor_Class_Data：client的配置信息或者client硬件配置信息
（3）说明
 厂商信息option。由client填充，用于描述client的一些信息。
在这里插入图片描述

14）Vendor-specific Information Option(option 17)
（1）Format(格式)

Option_data Format:

（2）字段
 Option_Vendor_Opts：option code为17
 Option_len：4 + Option_data的字节数
 Enterprise-number：厂商在IANA申请注册的厂商编号。
 Option_data：包含厂商特殊的信息数据。格式如Option_data的格式。格式内容由厂商自己定义。
（3）说明
 厂商特殊信息option。主要由厂商描述除了option16信息之外，其余的关于设备信息。
15）Interface-Id Option(option 18)
（1）Format(格式)

（2）字段
 Option_Interface_ID：option code为18
 Option_Len：Interface_ID的长度
 Interface_ID：由中继代理（relay-agent）生成，用于标识唯一接口
（3）说明
 中继接口ID option。中继代理收到client的message后，填充此option在Relay_Forward中，表示从该interface收到client的message。Server在回复中继，发送Relay_Reply时候，copy 此option的interface ID到此option中，然后发送给中继代理，中继代理收到后，解析此option，从该interface发送封包出去。
16）Reconfigure Message Option(option 19)
（1）Format(格式)

（2）字段
 Option_Reconf_Msg：option code为19
 Option_Len：1
 Msg_Type：message类型，表示希望client以哪种方式更新信息，表示通过renew，11表示通过Inform_request。
（3）说明
 重新配置信息option。此option只能在Reconfigure中使用，有server填充，当server的配置更新的时候，server向client发送Reconfigure并携带此option。如果msg_type是5，表示需要client发送renew，如果是11，表示需要client发送Inform-request。具体使用见上述。
17）Reconfigure Accept Option(option 20)
（1）Format(格式)

（2）字段
 Option_Reconf_Accept：option code为20
（3）说明
 接收重新配置option。Client在封包中携带此option，表示自己愿意接受Reconfigure Message。Server携带此option，表示询问client是否接受Reconfigure Message。如果client没有携带此option回复server，那么默认client不愿意接收Reconfigure。

5、Message的option table

说明：
（1）标注’Y’的表示对应封包可能会携带的option，这里只包括了option1-20的部分，对于其他特殊应用的option没做描述。
（2）没有标注’Y’也就是说明绝对不能携带，否则在检查封包的时候，可能就会drop掉。
（3）对于中继封包没做描述。
（4）以上仅供参考。

6、Ubuntu搭建dhcpv6 server

 1）isc-dhcp-server(Ubuntu 14.04)

sudo apt-get update
下载isc-dhcp-server:
sudo apt-get install isc-dhcp-server
创建配置文件：
sudo touch /etc/dhcp/dhcpd6.conf

#valid life-time,有效生存时间单位s
default-lease-time 14400;
#preferred life-time,首选生存时间单位s
preferred-lifetime 7200;
#T1 value,对应T1的时间值单位s
option dhcp-renewal-time 3600;
#T2value,对应T2的时间单位s
option dhcp-rebinding-time 7200;
#option 7 preference value
option dhcp6.preference 255;
#server enable rapid-commit,server支持client的rapid-commit
option dhcp6.rapid-commit;
#指定leases文件位置
dhcpv6-lease-file-name "/var/lib/dhcpd/dhcpd6.leases";
subnet6 2001::/80 {
    #ipv6address pool,range 2102-2220; #分配地址范围
range6 2001::2102 2001::2220;
#temporary ipv6address; #临时地址范围
range6 2001::/64 temporary; 
}

创建leases文件，会自动记录分配的信息
sudo touch /var/lib/dhcp/dhcpd6.leases
启动dhcpv6 server
sudo dhcpd -6 -f -cf /etc/dhcp/dhcpd6.conf eth0

说明：
  (1）启动时，eth0是对应的网卡，注意网卡的ipv6地址要是2001::/80网段的，否则失败，当然2001::/80也可以修改
 (2）subnet6 2001::/80，中的80并不表示指定分配地址前缀长度，据了解dhcpv6不能分配前缀长度
  (3）这里的配置只包括了上述option的一部分，后续介绍其他option会慢慢补充dhcpd6.conf文件，目前这些配置足够用来测试

 2）Dibbler-server(Ubuntu 20.04)
因为我在14.04安装，但是启动后server不工作，所以换了高版本的测试可以。

sudo apt-get update
下载dibbler-server:
sudo apt-get install dibbler-server
启动：
sudo dibbler-server run(前台运行)
sudo dibbler-server start(后台运行)
停止:
sudo dibbler-server stop(后台运行停止)
安装dibbler-server一般直接就写好了一些配置，只需要做更改就可以运行

sudo vim /etc/dibbler/server.conf
这里更改如下：只需要将interface-name更改为网卡的名称即可(ifconfig)
Iface “interface-name”{
    t1 1800-2000
    t2 2700-3000
    ....
}
配置信息的具体描述，server.conf描述的有，可参考。
Kuaisen
关注
  • 14
    点赞
  • 踩
  • 76
    收藏
    觉得还不错? 一键收藏
  • 6
    评论
专栏目录
rfc3315(中文版)
09-18
DHCPv6 Relay 通用rfc文档，中文翻译版本。DHCPv6中继服务。
DHCPv6和无状态配置
xianranruyi的博客
05-04 1297
关于DHCPv6的简单解释，内容参考了H3C的文档
IPV6协议之DHCPV6
最新发布
AXDRXS的博客
03-23 1081
DHCPv6是一种运行在客户端和服务器之间的协议，与IPv4中的DHCP一样，所有的协议报文都是基于UDP 的。但是由于在IPv6中没有广播报文，因此DHCPv6使用组播报文，客户端也无需配置服务器的IPv6地址。客户端侦听的UDP目的端口号是546。服务器、中继代理侦听的UDP端口号是547。IPv6协议具有地址空间巨大的特点，但同时长达128比特的IPv6地址又要求高效合理的地址自动分配和管理策略。手动配置。
三种IPv6动态地址分配方法
wjj970802的博客
01-31 2882
DHCPv6 PD（Prefix Delegation）是一种 DHCPv6 的扩展，它通常与 SLAAC（Stateless Address Autoconfiguration）和无状态 DHCPv6 结合使用，以提供更全面的 IPv6 地址配置和前缀分配。ipv6状态下ISP建立DHCPv6-pd服务器，用户路由器为DHCPv6-pd客户端，客户端拿到前缀后再发路由通告RA给内网的终端设备，给每个设备按这个前缀设置一个公网的ipv6地址。的情况下获取 IPv6 地址的方法。SLAAC 的核心是。
DHCPv6 Relay报文转发功能实现研究 (2008年)
05-26
IPv6可以解决当前地址资源匮乏问题，而动态主机配置协议能够实现IPv6地址参数配置的自动化，降低维护人员的劳动强度。基于rfc3315区分不同类型的DHCPv6报文，对13种报文类型的中继过程做出相应处理。在路由器设备上实现中继配置功能和报文转发功能，使客户端即插即用。客户端和服务器不在同一链路时，中继代理有效解决地址配置问题，使IPv6地址成功申请。
RFC3315(中文) 动态主机配置协议-DHCPv6
02-15
摘要 DHCPv6使DHCP服务器能够传递配置参数(如IPv6网络地址)给IPv6节点。它提供(可重复使用的)网络地址自动分配能力，增加了配置灵活性。本协议是“IPv6无状态地址自动配置”(RFC2462)的有状态等价物，能够用于独立获得配置参数或与后者一起获得配置参数。 目录 第1章 引言和综述 1-1 协议和寻址 1-2 涉及2个消息的客户端-服务器交换 1-3 涉及4个消息的客户端-服务器交换 第2章 要求 第3章 背景 第4章 术语 4-1 IPv6术语 4-2 DHCP术语 第5章 DHCP常量 5-1 多播地址 5-2 UDP端口 5-3 DHCP消息类型 5-4 状态代码 5-5 发送和重复发送参数 5-6 时间值和作为时间值的“Infinity”表示法 第6章 客户端/服务器消息格式 第7章 中继代理/服务器消息格式 7-1 Relay-forward消息 7-2 Relay-reply消息 第8章 域名的表示法及应用 第9章 DHCP唯一标识符(DUID) 9-1 DUIC内容 9-2 基于链路层地址加时间的DUID[DUID-LLT] 9-3 根据企业编号由供应商分配的DUID[DUID-EN] 9-4 基于链路层地址的DUID[DUID-LL] 第10章 身份关联 第11章 选择分配给IA的地址 第12章 管理临时地址 第13章 客户端消息发送 第14章 客户端初始消息交换的可靠性 第15章 消息合法性检测 15-1 Transaction IDs使用 15-2 Solicit消息 15-3 Advertise消息 15-4 Request信息 15-5 Confirm消息 15-6 Renew消息 15-7 Rebind消息 15-8 Decline消息 15-9 Release消息 15-10 Reply消息 15-11 Reconfigure消息 15-12 Information-reques消息 15-13 Relay-forward消息 15-14 Relay-reply消息 第16章 客户端源地址和接口选择 第17章 DHCP服务器请求 17-1 客户端行为 17-1-1 Solicit消息生成 17-1-2 Solicit消息发送 17-1-3 Advertise消息接收 17-1-4 Reply消息接收 17-2 服务器行为 17-2-1 Solicit消息接收 17-2-2 Advertise信息生成和发送 17-2-3 Reply消息生成和发送 第18章 DHCP客户端-发起的配置交换 18-1 客户端行为 18-1-1 Request消息生成和发送 18-1-2 Confirm消息生成和发送 18-1-3 Renew消息生成和发送 18-1-4 Rebind消息生成和发送 18-1-5 Information-request消息生成和发送 18-1-6 Release消息生成和发送 18-1-7 Decline消息生成和发送 18-1-8 Reply消息接收 18-2 服务器行为 18-2-1 Request消息接收 18-2-2 Confirm消息接收 18-2-3 Renew消息接收 18-2-4 Rebind消息接收 18-2-5 Information-request消息接收 18-2-6 Release消息接收 18-2-7 Decline消息接收 18-2-8 Reply消息发送 第19章 DHCP服务器发起的配置交换 19-1 服务器行为 19-1-1 Reconfigure消息生成和发送 19-1-2 Reconfigure消息超时或重新发送 19-2 Renew消息接收 19-3 Information-request消息接收 19
DHCPv6基础
热门推荐
Howie66的博客
05-26 1万+
转载自：https://cshihong.github.io/2018/02/01/DHCPv6%E5%9F%BA%E7%A1%80/DHCPv6简介IPv6动态主机配置协议DHCPv6(Dynamic Host Configuration Protocol for IPv6)是针对IPv6编址方案设计，为主机分配IPv6地址/前缀和其他网络配置参数。目的：IPv6协议具有地址空间巨大的特点，但同...
DHCP与DHCPv6讲解（DHCP报文格式、DHCP中继、DHCP攻击）
m0_49864110的博客
06-06 5221
攻击者发送大量恶意请求报文（修改DHCP报文中chaddr-客户端MAC地址字段），耗光DHCP服务器地址池中的地址（服务器也是根据chaddr来分配地址的，一个chaddr对应一个地址--而不是根据数据链路层的MAC地址来分配的）DHCP客户端向DHCP服务器发送报文时采用67端口号，DHCP服务器向DHCP客户端发送报文时采用68端口号（服务端监听的端口为67，客户端监听的端口为68）服务器对Request报文的确认响应报文（客户端收到此报文后，才真正获得了IP地址和相关的配置信息）
DHCPv6(dhcpv6配置)
计算机毕业论文源码，学生个人网页制作html源码。贴近用户做网络推广和互联网优化。
02-25 4898
家里联通宽带如何使用ipv6 IPv6在默认状态下已经安装并启用，无需额外配置。 IPv6使用两种地址自动配置协议，分别为无状态地址自动配置协议(SLAAC)和IPv6动态主机配置协议(DHCPv6)。SLAAC不需要服务器对地址进行管理，主机直接根据网络中的路由器通告信息与本机MAC地址结合计算出本机IPv6地址，实...
DHCPv6 snooping
qq_18631331的博客
06-27 2811
DHCP V6简要说明ipv6存在三种IP地址配置方式，一种是动态配置（dhcp）是本文介绍的主要对象；一种是无状态地址自动配置（SLAAC,即设备中生成IP），这个是DNP snooping关心的，本文不涉及；第三种就是静态配置，即用户手动设置，是本文中防护措施需要考虑的场景之一。DHCPv6 是DHCP协议的ipv6版本。该协议允许终端快速自动地获取IPV6地址。该协议方便网络管理员管理和验证...
华为HCIA进阶笔记：DHCPv6 原理与配置
君逍遥o
06-21 3400
主机在运行IPv6时，可以通过使用无状态地址自动配置或DHCPv6协议来获取IPv6地址。IPv6动态主机配置协议DHCPv6(Dynamic Host Configuration Protocolfor IPv6)采用了客户端/服务器通信模式，是针对IPv6编址方案设计的、为主机分配lPv6地址和其他网络配置参数的协议。
rfc6106-DNS配置的IPv6路由器通告选项.txt.pdf
08-20
本文档指定IPv6的路由公告选项，允许IPv6路由器将DNS递归服务器地址列表和DNS搜索列表通告给IPv6主机。ipv6地址的分配也分为DHCPv6和SLAAC，其中SLAAC的分配方法中，DNS地址的下发是通过RA报文通告给终端的，DHCPv6则沿用传统的方法。
RFC 3315 - Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
12-23
RFC 3315 - Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
DHCPv6-RFC3315(中文)
12-24
本文件介绍 DHCPv6， 一个客户端/服务器协议，该协议提供设备的管理配置。 DHCP 能够为设备提供 DHCP 服务器分配的地址和其他配置信息，所提供的内容均由 选项携带。通过定义携带本文件中没有规定的配置信息的新选项...
rfc3315-DHCPv6
01-23
（IPv4）的全球互联网面临网络地址消耗殆尽、服务质量难以保证等制约性问题，IPv6能够提供充足的网络地址和广阔的创新空间，是全球公认的下一代互联网商业应用解决方案。大力发展基于IPv6的下一代互联网，有助于显著...
DHCP介绍（DHCP交互过程以及相关抓包分析）
Kuaisen的博客
07-24 5959
`DHCP介绍（DHCP交互过程以及相关抓包分析）`DHCP 简介DHCP的报文种类以及作用DHCP工作流程DHCP报文字段格式DHCP抓包报文分析说明 DHCP 简介 DHCP（Dynamic Host Configuration Protocol）动态主机配置协议，前身是BOOTP协议。在大型局域网中，需要给很多主机配置地址信息，如果采用传统手工配置（累死），效率太低，因此采用此协议可以很方便的给主机配置各种地址信息，例如IP地址，SubMask、网关地址、DNS等等。下面进行简单介绍，下面所述中Cli
DHCP relay的工作过程以及DHCP option82的作用
Kuaisen的博客
07-23 4027
DHCP一家子（不包括DHCPv6）包括DHCP Client、DHCP Server、DHCP Relay以及DHCP Snooping，之后我会一个个详细学习之后发出来。今天讲述一下DHCP relay，之前先学习的DHCP Sever，还没来得及整理，之后会发出来，今天先说说DHCP Relay。 DHCP Relay（DHCP中继）,也叫作DHCP Agent，主要用于DHCP Client和DHCP Server不在一个网段时，DHCP Client又有自动地址分配的请...
SNMP SMI语法与书写MIB文件
Kuaisen的博客
09-10 2369
文章目录摘要一、SMI下的宏的类型二、SMI下的数据类型三、宏类型的参数MODULE-IDENTITYOBJECT-IDENTITYOBJECT-TYPENOTIFICATION-TYPETEXTUAL-CONVENTION四、MIB文件的书写 摘要 本章讲述SNMP SMI的语法部分，如何编写MIB文件。参考RFC1902和RFC1903 一、SMI下的宏的类型 MODULE-IDENTITY 该宏用于提供每个MIB模块的信息，例如更新时间，开发组织信息联系等。 OBJECT-IDENTITY 该宏用于定
在IPv6校园网中使用DHCPv6的用处
05-25
在IPv6校园网中使用DHCPv6的用处主要有以下几点： 1.自动配置IPv6地址：DHCPv6可以为设备自动分配IPv6地址，从而避免手动配置的繁琐和可能出现的错误。 2.分配IPv6前缀：DHCPv6可以向设备分配IPv6前缀，从而使得设备可以通过该前缀生成自己的IPv6地址。 3.提供其他配置信息：DHCPv6可以提供其他配置信息，例如DNS服务器、NTP服务器、路由器等，从而使得设备可以方便地访问网络资源。 4.管理IP地址池：DHCPv6可以管理IPv6地址池，预防地址冲突和地址浪费。 5.安全性：DHCPv6支持IP地址绑定，可以防止未授权设备获取IPv6地址，提高网络安全性。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 6
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值