摘要

  • RFC 5417 为 DHCPv4 和 DHCPv6 分别定义控制器地址列表选项，列表顺序来自已配置的 DHCP 服务器策略。
  • 无线终端可以使用该列表，并应按给出的顺序尝试控制器；这并不证明地址可达或对端可信，建立 CAPWAP 会话时仍须通过 DTLS 认证。

排障时抓到 DHCP 报文里的 Option 138 或 Option 52，通常能看出服务器返回了哪些控制器地址；它却回答不了 WTP 是否联系了首选 AC，更不能说明这个对端是否通过认证。RFC 5417 讨论的正是这条启动线索及其边界：DHCP 可以给候选地址排序，CAPWAP 会话仍需后续发现与认证。

两个地址族使用不同的选项。DHCPv4 选项 138 携带 32 位 IPv4 地址，选项数据长度必须是 4 字节的整数倍；DHCPv6 选项 52 携带 128 位 IPv6 地址，长度必须是 16 字节的整数倍。代表 WTP 行事的 DHCP 客户端必须在参数请求列表中请求相应选项。只有当 DHCP 服务器配置了相应策略和控制器地址列表时，它才会返回该选项。

因此，顺序是服务器配置的一部分，不是对控制器健康状况的自动测量。RFC 5417 说明地址按偏好顺序排列；WTP 可以用这份列表查找 AC，并且“应该”按收到的顺序尝试这些记录。这个顺序会影响搜索路径，但不构成服务保证：列出的地址未必可达，首位控制器也未必会接受 WTP，选项本身没有测量负载或健康状态。

还不能把 IPv4 和 IPv6 的两份列表自动合并成一个总排名。RFC 5417 分别规定两类地址列表中的偏好顺序，没有说明跨地址族的统一优先级。如果运维人员希望两类地址中的首选项表达同一政策，需要在本地配置中明确协调。

地址被列出，也不等于控制器已经可信。DHCP 给 WTP 提供最初的目的地线索；CAPWAP 发现和会话建立另有步骤。RFC 5415 描述了发现请求、响应以及随后的会话过程。RFC 5417 的安全章节指出，攻击者若能修改或注入 DHCP 响应，就可能把 WTP 引向恶意 AC，后者可拦截呼叫请求或造成拒绝服务。CAPWAP 建立会话时必须使用数据报传输层安全（DTLS）认证双方。

这道认证边界并不意味着启动链路可以忽略。RFC 5417 指出，多数网络在网络接入认证之前下发 DHCP 选项，而且通常没有完整性保护或来源认证。在安全敏感环境中，不应只依赖这些选项决定 WTP 联系哪个 AC。RFC 5415 还定义了 WTP 可以使用的其他发现流程。设计是分层的：DHCP 提名并排序候选对象，后续经过认证的交换再确认对端是否可接受。

IANA 目前仍将 DHCPv4 选项 138 登记为 OPTION_CAPWAP_AC_V4，将 DHCPv6 选项 52 登记为 OPTION_CAPWAP_AC_V6，两者均引用 RFC 5417。这说明协议参数仍在登记表中，不代表所有当前产品都支持或请求这些选项，也不说明某个 WTP 在一次尝试失败后会如何处理。

对运维团队来说，真正需要核验的是整条链：WTP 是否请求了选项；DHCP 服务器针对相应地址族和作用域返回了什么列表；每个地址是否有路由并监听；CAPWAP 发现过程返回了什么；DTLS 是否认证了预期对端。抓包看到选项 138 或 52，只能证明 DHCP 交换携带了什么，不能证明 WTP 到达了预期控制器或建立了可用的控制会话。

RFC 5417 的贡献范围不大，却很关键：它让 DHCP 策略影响无线设备寻找管理面的先后顺序，但没有把配置偏好伪装成实时选举或安全结论。迁移控制器时，把各阶段分开，决策就更清楚：列表表达意图，发现过程尝试候选对象，DTLS 认证最终继续的对端。

来源