企业官网建设流程全解析

1. 先纠正一个流行说法：IPv6不是不需要DHCP，而是把"分配"和"配置"拆开了

IPv4时代，DHCP几乎是每张网的标准配置，分配地址、下发网关、下发DNS，一个服务搞定。到了IPv6时代，很多人以为DHCPv6没什么用了——SLAAC不是能自动配地址吗？结果真把设备拉上线才发现，终端拿到地址了，DNS全空，域名解析直接失败。我接触到不少从IPv4迁到IPv6的项目，前期都在DHCPv6这件事上栽过跟头。

这个事得从根上讲。IPv6的自动配置体系里有两条路：无状态和有状态。无状态这条路由SLAAC负责，核心机制是路由器周期发送路由通告RA，把前缀和前缀长度放进去，主机自己拿接口标识拼出一个地址来。整个过程非常轻量，不依赖任何服务器，插上网线就能用，这也是IPv6被宣传得"零配置"的底气所在。有状态这条路则交给DHCPv6，由服务器集中分配地址、下发参数、维护租约，逻辑上更接近IPv4里DHCP的样子。

关键点在两条路不是竞争关系，而是分管不同的活。SLAAC只解决"有没有地址"，管不了"地址怎么管、配置从哪来"。企业网络要做地址审计，管理员得知道谁在哪个网段、这个地址分给了哪台机器；运营商接入网要给用户侧设备下发DNS和域名搜索列表；分支机构要拿到一段可供内部再分配的前缀。这些需求SLAAC一个都满足不了。虽然RA里的RDNSS选项理论上能携带DNS甚至NTP信息，但各终端系统对这个字段的实现参差不齐，靠它撑生产网络，我心里没底。

这篇文章适合三类人：正在做IPv4向IPv6迁移规划的网络工程师，负责园区网、数据中心或分支互联IPv6地址分配体系的运维人员，还有刚开始啃IPv6协议栈的学生。我会把DHCPv6的设计动机、报文流程、无状态/有状态的区别、中继原理和部署排障一次性讲透，凡是我觉得容易踩坑的地方都会单独标出来。

2. 解构DHCPv6的底层设计：全新的端口、DUID和IA

2.1 端口与寻址方式改成了什么

DHCPv6和DHCPv4在传输层上就不是一回事。DHCPv4走UDP 67/68，服务器监听67，客户端用68，核心手段是广播。DHCPv6改成服务器监听UDP 547，客户端监听UDP 546，而且基本不靠广播，客户端发起请求用的是组播地址FF02::1:2，这个地址叫All_DHCP_Relay_Agents_and_Servers，属于链路本地范围，同一链路内的所有DHCP服务器和中继代理都在这一个组播组里监听。

要是服务器不在客户端的链路上怎么办？还有站点范围的组播地址FF05::1:3可以用于寻址远端服务器，但在实际架构里，跨链路找服务器更多靠中继代理转发，客户端直接发到站点范围组播的场景并不常见。IPv6协议栈里压根没有广播的概念，原来IPv4里用广播完成的"寻找服务"动作，到IPv6全被设计成组播。这个改动带来的抓包体验差异很明显：不会再看到广播风暴式的Discover请求满地飞，也不会看到源地址0.0.0.0、目的地址255.255.255.255那种包，DHCPv6的报文全是正常的IPv6地址在互发。过滤条件也从"bootp"换成了"dhcpv6"，很多老工程师第一次抓IPv6的DHCP包时找不到自己熟悉的字段，就是没切换这个认知。

2.2 DUID：设备级唯一标识

IPv4里区分客户端靠chaddr，也就是网卡MAC地址。DHCPv6不这么干，因为没法保证MAC唯一——虚拟机的虚拟网卡MAC可以随意改，一台设备装多块网卡也很常见，而且IPv6接口可以同时拥有多个地址，任何一个地址都不能代表"这台设备"。于是有了DUID，全称DHCP Unique Identifier。它是设备级别的标识，和接口无关，和地址无关。不管这台设备上配了哪块网卡、挂了多少个IPv6地址，它发出的DHCPv6报文里带的DUID始终是同一个。

这个设计的现实意义很大。需要做"按设备固定分配地址"的网络，可以直接在DHCPv6服务器上按DUID做地址保留，效果类似IPv4里的MAC绑定。但要注意，DUID不是硬件指纹，它通常在系统首次启用DHCPv6客户端时生成，然后写进配置文件或者注册表。Linux系统一般存在/var/lib/dhcp目录下的lease文件里，重新安装系统、重置网络配置都可能让它变化。系统一重装，DUID就变，按老DUID做的保留条目就全部失效。这个坑在IPv4时代根本不存在，因为MAC还在，到了IPv6时代反而成了高频问题，做终端标准化文档时一定要提醒相关团队。

常见的DUID有三种类型：DUID-LLT由链路层地址加时间戳生成，DUID-EN是企业自定义编号，DUID-LL是纯链路层地址。绝大多数系统默认用DUID-LLT，生成一次基本不再变，除非主动删除相关状态文件。

2.3 IA：租约对象从"一个地址"升级成"一组地址"

IPv4的租约对象就是单个IP地址，服务器给客户端分配一个，记录一下租期就完事。DHCPv6不是这样，它引入了IA这个概念，全称Identity Association，可以理解成一个存放地址的容器。一个IA里可以装多个IA地址，也可以装一段前缀，对应前缀委派场景。每个IA有一个IAID，用来区分客户端上不同的接口或不同的网络用途。

IA的重要性在于，IPv6的一个接口本来就要同时持有好几种地址：全局单播地址、临时隐私地址、链路本地地址，还可能跨多个前缀各拿一个。如果用IPv4那套"一个接口一个租约"的思路去管理，会非常混乱。IA把一组地址打包成一个管理单元，客户端可以对整组地址一起申请、续租和释放，服务器也便于在一个租约单元内维护所有信息。再加上IA_PD（前缀委派），DHCPv6可以一次性把一段前缀分配给下级路由器，让分支网络内部自己再细分。这块是DHCPv6相对IPv4最突出的能力升级，也是很多纯IPv6网络架构能跑起来的基础。

2.4 报文类型重新换了名字

DHCPv6的报文类型和IPv4完全是两套命名，拿IPv4的直觉去记一定会乱。核心四步是Solicit、Advertise、Request、Reply，对应IPv4里的Discover、Offer、Request、Ack，但名字不同，含义也有微调。后续的Renew（续租）、Rebind（重新绑定）、Release（释放）、Decline（拒绝）、Confirm（确认）、Information-Request（信息请求），以及中继封装用的Relay-forward和Relay-reply，都是独立类型，编号从1到13，没有一个是照抄IPv4的。

我见过很多同事排障时下意识说"这个DHCP Offer没收到"，其实IPv6里根本没有Offer这个报文，该查的是Advertise。这个细节看着小，但在跨团队协作时很耽误事。统一用DHCPv6的报文名称沟通，是迁移初期就应该养成的习惯。

3. 状态化四步握手全流程拆解：Solicit到Reply

3.1 客户端发起：Solicit

状态化模式下，客户端首次上线，第一步是发Solicit报文。源地址通常是客户端的链路本地地址，目的地址是FF02::1:2组播，端口是547。报文体里会带上客户端的DUID（Client Identifier），想要的IA类型，比如IA_NA要地址、IA_PD要前缀，以及一个请求选项列表，告诉服务器"我需要DNS、域名搜索列表这些信息"。

Solicit本质上是在问："有没有服务器能给我发一段配置？"它不指定要哪个地址，只表明需求。服务器收到以后，如果觉得自己能提供，就会回一个Advertise。这里有个细节：如果网络里有多个DHCPv6服务器，客户端会收到多个Advertise，客户端有选择权，标准上对服务器选择的排序没有强制规定，实际实现里经常是哪个先到用哪个。

3.2 服务器回应：Advertise

Advertise是服务器对Solicit的响应，里面携带着服务器自己的DUID（Server Identifier）、客户端的DUID回显、可提供的IA配置，包括候选地址、生命周期，以及一系列配置选项。地址在这里还只是"候选"，客户端没有正式承诺，服务器也还没有真正创建租约记录。

Advertise里的生命周期字段非常关键，它决定客户端这个地址能用多久。首选生命周期过了之后，地址不能作为新连接的源地址，但已有连接不受影响；有效生命周期过了，地址才完全不可用。这两个值直接决定租约续租的节奏。像BGP、专线承载这类长连接业务，如果地址生命周期配得太短，地址失效会造成连接断流，排查起来也很绕。我建议生命周期至少按业务最大连接时长来规划，核心链路的地址生命周期宁可配长一些。

3.3 客户端确认与服务器应答：Request和Reply

客户端从Advertise里挑定服务器后，发Request报文，目的地址还是FF02::1:2组播，或者目标服务器有单播地址时也可以单播发送。Request里会带上选中的服务器DUID，意思是"就你了，给我正式分配"。服务器收到Request后，正式创建租约记录，然后回Reply。Reply里包含最终确认的地址、生命周期和配置选项。到了这一步，客户端才算真正拿到可用的地址和配置。

这里要特别提一下：Reply是服务器的最终承诺，客户端拿到Reply就必须按里面的参数使用地址。万一Reply里的地址和Advertise给的不一样也不奇怪，一切以Reply为准。所以在抓包验证时，不要只盯Solicit和Advertise，要看客户端在Request里实际接受了哪个前缀的地址，以及Reply最终给了什么。整个四步流程里，Reply的权威性最高，其他都是过程信息。

3.4 续租、重新绑定与快速提交

租约到期前，客户端会在T1时间点发起Renew，目的地址是服务器单播地址，这个单播地址来自服务器之前下发的配置。Renew的含义是"地址我还在用，给我续一下"，服务器收到后回Reply并更新租约时间。如果Renew一直没有应答，到T2时间点客户端就改用组播发Rebind，相当于对网络里所有服务器喊话"随便哪台在，快来帮我确认"，只要有能应答的服务器就可以。

这套T1/T2机制设计得挺巧，T1默认是首选生命周期的50%，T2是80%。调优时要结合地址生命周期和终端行为来设，如果网络里有大量休眠后唤醒的终端，周期太短会让唤醒后的地址处于过期状态，连接表现会很奇怪。还有一个省流量的特性叫Rapid Commit。服务器配置支持的情况下，客户端可以在Solicit里带一个Rapid Commit选项，服务器就能跳过Advertise和中间确认的等待，直接回Reply完成分配，四步变两步。在终端数量大的园区网里，这个特性能明显减少请求量和处理延迟，但前提是网络里没有多台服务器同时应答，否则容易造成配置不一致。用这个特性前，先把服务器的主备协调关系理清楚。

4. 无状态模式与中继代理：两个容易被忽略的关键机制

4.1 Information-Request：只要配置、不要地址

前面讲的状态化模式核心是"要地址"，但IPv6网络里很多场景是地址完全由SLAAC负责，只缺配置下发。这种场景下客户端发的是Information-Request报文，服务器收到后直接回Reply，Reply里只有配置选项，没有地址和前缀。服务器也不需要维护租约数据库，不管理地址状态，所以叫无状态模式。

这个设计的意义很大。运营商接入网里，家庭路由器通常自己处理SLAAC，但运营商还想给用户统一下发DNS配置，这时在网关侧起一个无状态DHCPv6服务就够了，不用管用户的地址是哪个，也不用维护租约表。代价是无状态模式下拿不到任何地址审计信息，谁用了什么地址、什么时间在用，全靠别的渠道去查。所以我的判断是：无状态模式适合"只要配置、不要管理"的场合，需要做合规审计的政企网络建议慎选。

4.2 中继代理为什么是必需品

IPv4里也有DHCP Relay，但DHCPv6的中继使用频率高得多，很多网络架构里中继就是常态。原因是IPv6的组播报文范围通常受限，客户端的Solicit发往链路本地组播，服务器如果不在同一个二层域，根本收不到。而IPv6网络的分层结构又决定了，DHCP服务器不可能每个二层都放一台。于是中继代理成了连接客户端和服务器之间的标准通道。

中继代理部署在客户端所在的接入设备或汇聚设备上，它监听客户端的组播请求，收到Solicit后封装成新报文发给远端服务器，服务器的应答也通过中继转发回客户端。中继的存在让DHCPv6服务器可以完全集中化部署，所有分支的客户端请求都汇聚到一两台服务器上处理，配置和管理都集中在一个点。分支机构越多的企业，中继就越离不开。

4.3 Relay-forward和Relay-reply的封装逻辑

中继代理工作靠两种报文类型：Relay-forward和Relay-reply。中继从客户端收到原始DHCPv6报文后，创建一个Relay-forward报文，外层有中继自己的地址，内层通过Relay Message选项把原始报文完整装进去。同时中继还会额外加Interface-ID选项，标记这个请求是从哪个接口进来的，这样服务器应答时能通过这个选项把数据回给正确的接入接口。

服务器收到Relay-forward后，解析出内层报文，按正常流程处理，然后把应答封装在Relay-reply里发回中继。中继再取出内层报文还原成原始DHCPv6报文，按Interface-ID对应的接口转给客户端。最容易出错的点是中继接口和服务器之间的回程路由：中继转发的外层地址必须是服务器能路由回去的地址，否则服务器就算收到了请求，应答也到不了中继。排这类问题，先抓链路看Relay-forward有没有到服务器，再确认回程路由，顺序不能反。

5. 现网部署的实战要点：前缀委派、选项配置与抓包排障

5.1 IA_PD：给下级路由器分一段前缀，而不是一个地址

DHCPv6最让我觉得比IPv4高级的地方是前缀委派IA_PD。IPv4时代，分支网络要么用NAT躲地址不够的问题，要么手动划一个静态网段给分支，再由分支自己维护子网。IPv6地址数量充裕，但核心网络要统一管理地址分配，于是DHCPv6服务器可以把一段前缀，比如2001:db8:1080::/56，分配给分支路由器，分支路由器再往下把/64子网分给各个业务网段。

IA_PD的租约概念跟IA_NA一样，有生命周期有T1/T2，只是分配的对象是前缀而不是地址。这个特性直接支撑了"无NAT的纯IPv6网络"和"端到端可寻址"这两个目标。部署要点是：下游路由器开启DHCPv6 PD客户端，上游路由器或服务器开启PD服务，并且要规划好每级分配多少位前缀。位长规划做不好，后面扩容调整会非常痛苦，网络里所有下级设备的配置都得跟着动。

5.2 常用的配置选项

DHCPv6提供的配置选项很多，但生产环境里最常用的是三个：DNS递归服务器、域名搜索列表、NTP服务器。DNS和域名搜索列表的用途跟IPv4里一样，但格式是IPv6地址，配置时要小心别把IPv4地址格式混进去。NTP服务器这类选项在不同设备上支持程度有差异，稳妥的做法是同时通过无状态DHCPv6和RA的RDNSS选项下发，互为备份。

我的个人习惯是在园区网的DHCPv6策略里，DNS至少下发两个地址，一个主一个备，域名搜索列表按实际业务域名填。别小看这些，很多终端对域名搜索列表的处理是拼接式的，配置错了会出现很怪异的解析失败，排查半天才发现是搜索列表顺序的问题。

5.3 抓包怎么看

排查DHCPv6问题，首选还是抓包。抓包时过滤dhcpv6这个协议关键字，就能看到完整报文交换。我一般按这个顺序排查：先确认客户端有没有发出Solicit，连Solicit都没有，问题在客户端或接入链路；然后看服务器有没有回Advertise，没回就查服务器的监听状态和地址池里有没有可用资源；再看客户端Request最终接受了哪个地址，以及Reply里的生命周期是否合理。

还有个容易忽略的点：请求者不一定每步都用组播。Renew是单播给服务器的，抓包时如果只过滤组播流量会漏掉续租包。另外，中继转发的场景下，客户端接入端口和服务器上联端口抓到的报文内容完全不一样，只看一边很容易误判。我的习惯是两边同时抓，对照起来看整个链路到底断在哪一跳。

5.4 三种最常见的问题

地面项目里遇到最多的DHCPv6问题就三类。第一类，客户端能通过SLAAC拿到地址但DNS为空，多半是RA里没有设置M位和O位，终端根本不知道要去找DHCPv6。第二类，DHCPv6服务器状态正常但请求到不了，几乎都是中继没配好或者中继接口上没启用DHCPv6中继功能。第三类，地址保留不生效，原因是DUID和预期不符，典型场景就是终端系统重装后DUID变了。这三类问题用常规手段都能在一个会话内定位清楚，怕就怕不做抓包直接猜配置，越改越乱。

6. 我踩过的那些坑：三则配置失误的记录

6.1 只开SLAAC不开DHCPv6，终端DNS全空

第一次给一个园区网启用IPv6时，我只在核心路由器上开了RA。地址倒是下发成功了，所有终端都拿到了2001:db8:开头的地址，但用户反馈网页经常打不开。抓包一看，终端的DNS请求全部超时，因为系统根本不知道DNS服务器在哪。RA里的RDNSS选项我虽然配了，但部分老版本终端系统对这个字段的支持有兼容问题，最终还是补开了无状态DHCPv6，用Information-Request给终端下发DNS，一切恢复正常。从那以后，我的默认规范变成了：启用IPv6的同时，把RA的M位或O位和DHCPv6服务一起规划，别省这一步。

6.2 RA的M位和O位没配对

第二个坑更隐蔽。有一次给分公司网络调整IPv6配置，我在路由器上同时开了SLAAC和DHCPv6状态化服务，但RA通告里的M位没打开。结果终端认为地址靠SLAAC配就够了，根本不发DHCPv6请求，DHCPv6服务器上一条租约都没生成，可网络里确实同时跑着两个服务。后来把M位打开，终端才重新发起完整的四步协商。这里的逻辑关系是：M位代表地址由DHCPv6管理，O位代表其他配置由DHCPv6管理。要用SLAAC地址加DHCPv6其他配置，就只设O位不设M位；要让DHCPv6管地址，就两个都设。理清这个关系以后，我再没犯过同类错误。

6.3 中继接口忘加组播成员

还有一次现网故障耗了很长时间。DHCPv6服务器在骨干部署，分支网络的接入设备上开了中继功能，分支内所有终端始终拿不到地址。从客户端抓包看，Solicit正常发出，组播也在链路上走；从服务器端抓包看，一个Relay-forward都没有到。最后发现接入设备的组播成员配置里，FF02::1:2没有被加入到中继接口的监听列表，组播请求根本没被识别成需要上送中继的报文。这个问题在文档里常常一笔带过，实际配置时特别容易漏。凡是部署DHCPv6中继，第一步就要确认接口对组播地址的接收和上送没有过滤。

这三则经历给我最大的教训是：DHCPv6调试的每一步都要拿抓包结果说话，想当然地改配置只会让问题更难定位。协议本身逻辑清晰，但涉及的环节多，从RA标志、DHCPv6服务、中继链路到终端行为，每一环都验证一遍，问题基本跑不掉。希望这篇文章能帮你在IPv6落地时少走几段我走过的弯路。