IPv6折腾了这些年，有个问题我几乎每次排查都会遇到：网络明明是通的，某些设备却拿不到需要的网络参数，或者网关、DNS时灵时不灵。不少人第一反应是“IPv6没配置好”，但实际上根子往往出在DHCPv6协议的细节上。借着这个题目，我把DHCPv6这件事从头到尾捋一遍，把我实际调试中踩过的坑、验证过的结论一并写出来。这篇文章不堆术语，尽量用大白话把协议讲清楚，同时保留足够的技术细节，适合刚接触IPv6的运维和网络工程师，也适合想在实验环境里完整跑一遍DHCPv6的同学。
1. 为什么IPv6还需要一个“类似DHCP”的东西
我一直觉得要理解DHCPv6，必须先解决一个认知问题：IPv6不是号称“地址多到用不完、设备自己就能生成地址”吗，那为什么还得有DHCPv6？这个问题的答案，恰恰是理解整个协议的关键。
1.1 SLAAC解决了地址问题，但没解决全部问题
IPv6确实有SLAAC（无状态地址自动配置），路由器通过发送**RA（Router Advertisement，路由通告）**报文把自己的前缀和网关信息广播给网络里的主机。主机收到RA以后，用自己的网卡MAC地址或者随机生成的接口ID组成一个完整的IPv6地址，这就是所谓的“无状态”。
这套机制的优点是零配置，插上网线就能通。但它有个天然的盲区：RA报文里能携带的信息太有限了。除了前缀、网关、MTU这类核心网络参数，主机真正经常需要的DNS服务器地址、NTP服务器地址、域名搜索列表这些“应用层网络参数”，在最初的SLAAC设计里并没有可靠的下发通道。虽然后来RA里加入了可选的DNS选项（RFC 8106），但兼容性和支持度在真实网络里始终不够理想。
所以DHCPv6存在的第一个理由就是：把“网络可达性配置”和“业务参数配置”分开。SLAAC负责让你“通”，DHCPv6负责让你“好用”。
1.2 DHCPv6和DHCPv4到底差在哪里
从名字上看，DHCPv6像是DHCPv4在IPv6平台上的简单升级，但实际协议细节差异非常大。不少同事第一次抓包看DHCPv6报文时都会懵，原因就在于两者的交互逻辑根本不一样：
| 对比项 | DHCPv4 | DHCPv6 |
|---|---|---|
| 服务器发现 | 主机发广播的DISCOVER，全网找服务器 | 主机发组播的SOLICIT，组播地址是FF02::1:2 |
| 服务器回应 | 服务器单播发送OFFER | 服务器单播发送ADVERTISE |
| 消息匹配 | 靠xid事务ID即可 | 靠xid + Client ID + Server ID共同确认 |
| 终端标识 | 通常用MAC地址（chaddr字段） | 用DUID（DHCP Unique Identifier），不一定是MAC |
| 客户端源地址 | 尚未获取IP时用0.0.0.0 | 用链路本地地址作为源地址 |
| 地址分配状态 | 协议自带租约、续租、释放机制 | 地址分配和状态管理由服务器维护，续租逻辑不同 |
| IA地址管理 | 一次性分配IPv4地址 | 按IA_NA/IA_PD管理，可分配地址亦可分配前缀 |
这里最值得提的就是DUID。DHCPv6不再依赖网卡MAC作为客户端唯一标识，而是用DUID。DUID有多种生成方式，比如基于时间戳+MAC、基于厂商定义、或者基于链路层地址。这个设计有一个实际好处：一台设备可能有多个网卡、多个MAC，但DUID可以在系统层统一，跨网络移动时身份标识更稳定。坏处也很明显：如果重装系统导致DUID变化，原来绑定的地址或前缀就会失效，这在排查“为什么老拿不到固定地址”时是个重要方向。
1.3 三种工作模式的取舍
DHCPv6没有沿用DHCPv4那种单一的“动态分配”思路，而是区分了三种工作模式，对应不同的网络管理需求：
SLAAC（无状态模式）：RA报文里的A标志位置1，主机自己生成IPv6地址。这种方式下，DHCPv6的存在与否不影响地址生成，但RFC 3736定义了一种“无状态DHCPv6”场景：主机地址自己生成，但DNS等参数通过DHCPv6获取（RA里的O标志位会提示这一点）。这种模式在大型无线网络里很常用，因为服务器不需要维护每一台终端的地址租约，压力小。
有状态DHCPv6：RA报文里的M标志位置1，主机收到RA后不再自己生成地址，而是直接去请求DHCPv6服务器分配。路由器自身不参与地址分配，只负责“指路”。这种模式适合需要集中管控IP地址、做准入控制、做地址审计的网络。
PD（前缀委派，Prefix Delegation）：这个模式最容易被忽略，但对家庭和企业网络意义极大。上级路由器（DHCPv6客户端）向下级路由器（通常是家用路由器或分公司出口）申请一个IPv6前缀，拿到后下级路由器把前缀切分给局域网内的终端使用。没有PD，很多下级路由器就无法自动配置IPv6连接。PD模式下，DHCPv6的“地址”不再是单个IP，而是整段前缀，管理粒度完全不同。
我的实际建议是：能SLAAC就SLAAC，需要管控就上有状态DHCPv6，多层网络一定检查PD链路。这三条看似简单，实际规划和排障时能省掉大量麻烦。
2. DHCPv6的报文体系与状态流转
理解了为什么需要DHCPv6，接下来就是协议本身的“语法”问题。DHCPv6的报文类型不多，但它把“连接建立”和“参数配置”分得比DHCPv4更清楚。
2.1 报文类型一张表讲透
DHCPv6协议定义了几种核心报文，各自的用途如下：
| 报文类型 | 发送方向 | 作用 |
|---|---|---|
| SOLICIT | 客户端 → 服务器 | 客户端发起请求，寻找DHCPv6服务器 |
| ADVERTISE | 服务器 → 客户端 | 服务器响应SOLICIT，告知自己“可作为服务器” |
| REQUEST | 客户端 → 服务器 | 客户端选择一台服务器，正式请求分配地址/参数 |
| REPLY | 服务器 → 客户端 | 服务器确认分配结果，携带地址、前缀、配置参数 |
| RENEW | 客户端 → 服务器 | 租约到期前，客户端向原服务器续租 |
| REBIND | 客户端 → 服务器（组播） | 客户端没有收到RENEW响应时，向所有服务器请求续租 |
| RELEASE | 客户端 → 服务器 | 客户端主动释放地址/前缀 |
| DECLINE | 客户端 → 服务器 | 客户端检测到地址冲突，拒绝使用该地址 |
| INFORMATION-REQUEST | 客户端 → 服务器 | 客户端只请求配置参数，不请求地址，用于无状态模式 |
| CONFIRM | 客户端 → 服务器 | 客户端网络变化后，确认当前地址是否仍然有效 |
可以看到，DHCPv6的报文设计比DHCPv4多了一条清晰的“确认”路径。比如CONFIRM报文，在客户端网络发生切换（比如从WiFi切到有线、从办公区移动到客访区）时用于验证自己的地址是否还能用，这个在移动办公场景里是很实用的机制，DHCPv4里没有对应动作。
2.2 DUID和IA：客户端身份与“地址容器”
每个DHCPv6客户端至少持有一个DUID，但是在报文中真正承载地址需求的是IA选项。
IA（Identity Association）是一个核心概念。可以把它理解成一个“容器”，用来区分不同用途的地址请求。目前常见的类型有三种：
- IA_NA（Identity Association for Non-temporary Addresses）：用于申请常规的可变IPv6地址，相当于DHCPv4里的动态地址。
- IA_TA（Identity Association for Temporary Addresses）：用于申请临时地址，这个地址可以频繁变化，通常用于隐私保护场景，避免把设备真实身份暴露到公网。
- IA_PD（Identity Association for Prefix Delegation）：用于申请前缀而不是单个地址，是PD模式的核心。
一个客户端可以同时携带多个IA选项，比如同时申请一个IA_NA和一个IA_PD。服务器在分配时，会分别处理每个IA，并给每个IA返回一个唯一的IAID。这意味着同一条REPLY报文里，客户端可能拿到自己用的地址，也拿到给内网划分用的前缀。
我调试PD时见过很多次这种情况：路由器申请前缀成功了，但IA_PD里的前缀长度和期望不符。其实服务器完全有权返回比请求更长的前缀（更小的分配范围），这是合规的，客户端必须接受。很多厂商固件在这里会报错，原因就是没有做好“服务器给了不同长度前缀”的容错处理。
2.3 租约续期逻辑的坑
DHCPv6的租约续期逻辑和DHCPv4有本质区别。DHCPv4的客户端通常持有IP地址不变，续租只是把租约时间延长；DHCPv6有状态分配里则引入了T1和T2两个时间点：
- T1：到达租期50%左右时，客户端尝试向原始服务器续租（RENEW）。
- T2：到达租期80%左右时，如果RENEW失败，客户端会改用组播REBIND，向本网络内的任意服务器寻求响应。
这个机制在有多台DHCPv6服务器的网络里非常关键。因为服务器之间默认没有状态同步，一台服务器分配出去的地址，别的服务器不知道。如果RENEW迟迟没有响应，客户端就会REBIND，这实际上是“再找一台新服务器接管我”。如果新服务器此前不认识这个客户端，它很可能会分配一个新的地址，客户端就会默默切换地址。
在“双机DHCPv6热备”场景下，这个坑特别明显。很多人搭建双机时，习惯性地只做VIP漂移，却没有同步租约DB，结果主备切换后，大量客户端直接丢弃原有地址，重新走一遍SOLICIT/REQUEST流程，全网重配。我在实际项目里建议的做法很简单：优先使用服务器自带的租约数据库复制机制（比如ISC DHCPd 的 failover 配置），如果实在无法同步，就等下一次REBIND阶段自然切换，同时把T2时间调短，减少客户端长时间“失联”的窗口。
3. 从零实现一个DHCPv6服务器
理论讲再多，不如动手做一遍。我挑最常用的三套方案来演示：Linux下的ISC DHCPd、Windows Server自带的DHCPv6、以及家用/边缘路由器上的常见实现。三者覆盖了主流场景，也各有各的脾性。
3.1 Linux环境：ISC DHCPd配置全流程
ISC DHCPd虽然已经不是最“时髦”的方案，但依然是Linux世界里兼容性最好的选择。装好包以后，配置核心就是/etc/dhcp/dhcpd6.conf。我直接给一份能跑通的配置：
# 指定IPv6监听接口，这里以 eth0 为例 default-lease-time 600; preferred-lifetime 300; option dhcp6.name-servers 2001:db8::53; option dhcp6.domain-search "example.com"; # 有状态地址分配 subnet6 2001:db8:1:1::/64 { range 2001:db8:1:1::100 2001:db8:1:1::200; } # 前缀委派，给下级路由器分配 /60 前缀 subnet6 2001:db8:2::/56 { prefix6 2001:db8:2:: 2001:db8:2:ff:: /60; }配置完成以后，启动方式和DHCPv4完全不同。注意，必须显式指定监听IPv6接口，否则服务起不来：
systemctl start dhcpd6 systemctl enable dhcpd6启动以后，我建议立刻做三件事验证：
- 抓包确认有没有收到SOLICIT报文。在接入交换机或者服务器上执行
tcpdump -i eth0 ip6 -n -vv -s 0 port 547，看到SOLICIT说明客户端已经找到了服务器路径。 - 查看租约文件。ISC DHCPd的租约文件路径通常是
/var/lib/dhcp/dhcpd6.leases，确认分配出去的地址范围和预期一致。 - 手动模拟一个客户端请求。用
dhcpv6c或者ndisc6等工具触发一下，观察ADVERTISE和REPLY交互。
我在实际项目里发现一个很常见的配置失误：配置了subnet6却忘了给接口配置对应的IPv6地址。DHCPd启动时会检查接口上是否已配置了该子网的地址，如果没配置，即使配置文件语法正确，服务也会拒绝启动，日志里会报“No subnet declaration for eth0”之类的错误。排查时务必先确认接口地址、路由和配置文件子网声明三者是严格对应的。
3.2 Windows Server环境：图形界面和PowerShell双管齐下
Windows Server的DHCPv6配置比Linux友好很多，但理解的思路不能变。步骤通常是“先授权角色，再创建作用域，再配置选项”。
新建IPv6作用域时，Windows会要求填写“前缀”和“偏好/有效生命周期”，注意这里不是直接写地址范围，而是写一个前缀长度。比如你规划了一个2001:db8:100::/64的内网段，服务器地址范围可以写成从2001:db8:100::1到2001:db8:100::ffff。
DNS选项配置在“作用域选项”里，和IPv4 DCHP类似。唯一让人困惑的是Windows Server里IPv6作用域没有默认的“003 Router”选项，因为IPv6网关信息普遍走RA，不需要DHCP下发，如果强行下发反而会导致设备上出现多个默认网关。
PowerShell下的操作也顺手，关键命令长这样：
Add-DhcpServerv6Scope -Prefix 2001:db8:100:: -Name "IPv6 Office Scope" -State Active Set-DhcpServerv6OptionValue -Prefix 2001:db8:100:: -DnsServer 2001:db8::53 -DomainSearch "example.com" Get-DhcpServerv6Lease -Prefix 2001:db8:100::PowerShell的方式适合批量操作规模大的网络，不用一只鼠标点几百次界面。
3.3 路由器上的PD实现
到了路由器和运营商接入这个层面，情况就不太一样了。家用路由器最常见的形态是作为DHCPv6客户端，向运营商申请前缀，然后再作为服务器给局域网分配IPv6地址。这个过程中，真正容易被忽略的是**“中继请求处理”**。
不少网关型路由器会把终端发来的DHCPv6请求通过中继转发到运营商侧，由运营商的服务器统一分配。这种方案里，路由器本身不维护地址池，只做一个“传话筒”。在抓包时候，如果只盯着路由器本身的接口，大概率看到的是大量Relay-Forward和Relay-Reply报文，而不是ADVERTISE和REPLY。这时候不要误判为协议不通，因为中继模式下，正常交互本来就是三层转发实现的。
从我自己的测试结果看，PD链路一旦通了，下层网络配置效率非常惊人。上级下发一个/60前缀，路由器切成16个/64子网，每一段对应一个SSID或者一个VLAN，终端设备各自SLAAC或者DHCPv6分配，整个过程不需要手动填任何地址。这也是IPv6真正的价值体现：网络规划以“段”为单位，而不是以“个”为单位。
4. 无状态与有状态的实战抉择
写协议的时候可以画一条清晰的线，但实际组网时“无状态”和“有状态”经常需要结合着用，甚至是同一张网里的不同VLAN各走各的模式。这一节我把两者放在一个场景里比较一下，给出我的决策建议。
我在一个中等规模的办公网里做过一次完整的IPv6改造。终端大致分为三类：
- 员工有线/无线笔记本：需要访问业务系统，需要DNS优先，最好能追踪到人，所以这段走有状态DHCPv6。RA关闭A标志位，M标志位置1，全部地址由DHCPv6服务器分配。
- 访客WiFi：不需要严格控制，只要通网和基本DNS即可。这段走SLAAC，RA置A标志位，同时用无状态DHCPv6下发DNS参数（INFORMATION-REQUEST流程）。
- 打印机、摄像头等物联网设备：每种品牌对IPv6的支持差异巨大，采购时没提要求的话，默认就当他们不支持有状态。这段同样走SLAAC，DNS参数不回传也无所谓，因为多数物联网设备只需出网，不需要名字解析。
这样分配的思路是什么呢？核心是把地址分配“控制粒度”和“运维成本”对齐。有状态意味着服务器要记录每条租约，要处理续租、释放、冲突检测，这些事情在数千终端规模的网络里会产生实打实的运维量。无状态意味着终端的地址本质上是“自生自灭”，服务器完全不关心，运维成本显著降低。不是所有网络都需要精细化管控，也不是所有网络都适合粗放。
另外有个细节值得注意：RA里的M标志位和O标志位并不互斥，它们可以同时置1。比如M=1强制使用有状态DHCPv6获取地址，但O=1又允许设备再发起一次INFORMATION-REQUEST获取其他参数。这给了网络管理员一个比较灵活的组合空间：地址分配走有状态集中管理，DNS等参数可以随设备的需求自行获取。
5. 客户端配置与主机的“脾气”
协议交互是双向的，服务器端配置好了，客户端如果不开窍，一样白搭。
5.1 网卡属性里可能藏着大问题
Windows系统对IPv6的支持一直被人诟病“默认关闭”或者“半开状态”。其实Windows 10/11和Server 2016以后，默认的IPv6行为是启用的。真正的问题是网卡属性里“Internet协议版本6”的设置，以及DHCPv6相关服务是否被禁用。
我遇到过一个经典案例：某台Windows机器在同一网络里只有它能通过IPv6上网，其他设备都通。排查后发现这台机器曾经安装过某种“优化工具”，把网卡IPv6的“自动获取IP地址”改成了“手动”，但地址却是空的。哪怕系统前台的界面显示的是“自动”，DHCPv6服务（DHCP Client服务）却没起来。解决办法很简单：确认服务里Dhcp服务状态为“正在运行”，启动类型为“自动”；网卡属性IPv6项里全部选“自动”。
在某些精简版或者企业镜像封装的时候，DHCP服务被误伤的情况很多。我一般会要求项目组在镜像分发前用一条命令确认：
Get-Service Dhcp | Select Status, StartType如果返回不是Running和Automatic，直接改注册表或者用SC命令修正，比事后逐台改省力得多。
5.2 Linux客户端的确认方法
Linux生态下网络管理工具五花八门，NetworkManager、systemd-networkd、dhcpcd等各领风骚。但不管哪一套，确认客户端是否走DHCPv6的关键点是一样的：RA里M标志位是否被接受、网络管理进程是否启用了DHCPv6、以及客户端有没有DUID。
以NetworkManager为例，我常用的验证命令是：
nmcli device show eth0 | grep -i ipv6输出里能看到method: auto或者method: dhcp。如果是manual或者ignore，说明IPv6配置没有交给DHCPv6流程处理。
另外有个冷门问题：DHCPv6的客户端DUID文件如果被删除，地址就换了。在NetworkManager中，DUID保存在/etc/NetworkManager/下；在dhcpcd中，DUID保存在/var/lib/dhcpcd/下。重装系统或者虚拟机克隆后，DUID会变化，从而影响固定地址绑定。如果公司有基于DUID的地址保留策略，这个细节必须注意。
6. 常见问题排查与避坑实录
最后这部分，我把我这几年来被问得最多、也最让人头疼的DHCPv6相关问题整理成一份速查表，后面跟着几个详细拆解过的案例。
| 现象 | 常见原因 | 排查手段 |
|---|---|---|
| 客户端完全拿不到IPv6地址 | RA或DHCPv6被防火墙拦截、交换机组播过滤 | 检查ff02::1:2组播是否放行，抓包看SOLICIT是否出得去 |
| 能拿到地址但DNS不通 | 服务器下发了不可达的DNS地址、客户端DNS配置未生效 | 抓包确认REPLY里的选项信息，手动测试DNS服务器连通性 |
| 有状态DHCPv6分配慢 | T1/T2配置过长、客户端没有处理RENEW | 检查服务器租约时间和T1/T2参数，缩短续租周期 |
| SLAAC和DHCPv6冲突 | RA里A和M标志位同时置1但设备优先选择了不期望的方式 | 关掉对应标志位，明确唯一的获取路径 |
| PD拿到了但内网设备不通 | 路由器没有把PD前缀的路由下发到内网 | 检查路由表是否有指向内网接口的前缀路由 |
| 无线终端偶尔断流 | 无线控制器未透传IPv6组播，导致DHCPv6交互丢失 | 检查无线侧组播过滤策略，开启IPv6组播桥接/代理 |
6.1 现象一：组播到不了，SOLICIT出不去
排查DHCPv6的第一个拦路虎往往不在服务器而在网络设备。DHCPv6客户端发出的SOLICIT报文目的地址是组播ff02::1:2，这个地址在本链路内有效。但如果交换机开启了IPv6组播过滤，禁止未知组播泛洪或者没有配置MLD Snooping，SOLICIT就可能出不了接入层。服务器自然收不到，整个过程看上去就是“客户端静默失败”。
抓包时有一个典型特征：在客户端网卡上能看到组播报文发出来，但服务器网卡上死活看不到。这时候先查中间交换机组播表项，再看有没有启用组播窥探，最后查端口是否有IGMP/MLD Snooping相关策略限制。无线环境里这个问题会更突出，因为无线控制器默认可能丢弃某些组播帧，需要在WLAN的高级选项里开启“IPv6组播透传”相关配置。
6.2 现象二：RA里的M标志位被忽略
另一个常见困惑是，明明路由器配置了“下发M标志”，但Windows终端还是不发起DHCPv6请求。排查发现有些终端的IPv6协议栈对M标志位的响应逻辑和标准不完全一致，特别是双栈场景下，它可能优先采用SLAAC，而把M标志当作“可选建议”。这种情况下，单靠RA里的M标志并不足以强制客户端走有状态DHCPv6。
解决办法有两个方向：一是确认服务器本身是否能主动向客户端发送DHCPv6通告（某些厂商的网关支持主动推送模式）；二是在客户端层面由管理员统一下发策略，比如Windows可以用组策略指定“IPv6地址分配方式为DHCPv6”，Linux可以在NetworkManager配置里强制method: dhcp。
6.3 现象三：地址拿到了，但网关不通
这个问题比较隐蔽。有状态DHCPv6只负责分配地址和下发参数，但IPv6的默认网关信息只来源于RA。如果网络里RA报文的发送方（路由器）没有正确开启RA，或者RA里的前缀跟DHCPv6分配的不是同一个子网，客户端就会出现“有地址、没网关”的情况。
我在一个客户现场就碰到过：服务器分配的是2001:db8:10::10这类地址，但路由器通告的网关前缀却是2001:db8:20::1，两边不在一个网段。抓包一看，RA和DHCPv6来自两个不同的三层设备，配置没有统一规划。解决方法是保证RA通告的前缀、DHCPv6地址池的前缀、以及网关接口的地址必须三段一致。任何一段对不上，终端就会“看得见摸不着”。
6.4 现象四：双栈环境里IPv4通了，IPv6还是慢吞吞
这个通常不是DHCPv6协议本身的问题，而是IPv6 DAD（重复地址检测）和NDP（邻居发现）的时序问题。双栈终端在获取IPv6地址后，还要做DAD，重新解析邻居，这个过程比IPv4要慢几百毫秒。如果DNS服务器里同时配置了IPv4和IPv6地址，系统默认可能先尝试IPv6连接然后超时降级，体感上就是“网很慢”。
遇到这种情况，建议先从DNS入手，把IPv6的DNS记录查询测试一遍，确认服务器确实能快速回应。排除DNS因素后，再检查终端IPv6地址是否通过DAD检查。如果DAD反复失败，很可能是同一链路上有别的设备已经用了相同地址，这种境地基本只有检查RA前缀和地址池规划才能根治。
7. 我自己的一点体会
最后说点个人感受，不讲太多理论，毕竟协议细节前面说得够多了。
DHCPv6这个协议，论复杂度其实不算特别高，但它非常依赖网络里每一层的配合。RA、SLAAC、DHCPv6、PD、NDP，这些机制互相咬合，任何一处配置疏忽都会表现为“终端症状”，而不是直接指向协议问题。所以排障时别急着怀疑协议实现，先从链路上抓一份完整的交互报文，确认SOLICIT出去、ADVERTISE回来、REQUEST再出去、REPLY回来，这四步走通了，剩下的大概率就是参数配置或者域名解析的细节问题。
还有一个经验是，IPv6排障时抓包一定要关掉无关的过滤条件，多看一眼NDP和RA报文。很多人只盯着DHCPv6端口547和546过滤，漏掉了RA报文的M标志位状态，结果绕了一大圈才找到问题症结。抓包工具我常年用的就是tcpdump配合Wireshark进行分析，IPv6的路径MTU问题也可以直接在Wireshark的IPv6字段里看到扩展头信息，定位起来比纯黑盒测试高效太多。
如果你正打算把内网IPv6全面落地，我的建议是先从无状态SLAAC开始跑通链路，再监控一段时间的稳定性，然后按需叠加DHCPv6和PD。一步到位往往会让问题面铺得太宽，到时候你都不知道该查服务器、交换机还是路由器。这个思路，不管是几十台的小网，还是上千台的大网，都适用。
