摘要

  • RFC 7844 定义的是一套 DHCP 匿名配置，而不是一个“匿名地址”。DUID、IAID、旧地址提示、服务器标识符、FQDN 与类别选项，都可能把新连接接回旧记录。
  • 即便没有直接姓名，客户端索取哪些选项、以什么顺序索取，也会形成实现指纹。共同配置要求减少选项并打乱顺序，避免隐私模式本身成为罕见标记。
  • 协同遗忘会牺牲连续性：服务器可能暂存更多旧租约，地址池和绑定表承压，要求预登记设备的网络也可能拒绝接入。它降低 DHCP 层的关联面，并不承诺隐身。

地址只是最显眼的一件行李

隐私讨论很容易盯住一串地址。它可见、可比较，也容易演示：旧值消失，新值出现，两个会话似乎已经断开。RFC 7824 所做的分析更朴素——把 DHCP 报文里其余能够持续的字段逐一列出来。

在 DHCPv6 中，DUID 让服务器识别客户端，IAID 区分同一客户端里的身份关联。Client FQDN 可以直接给出主机名；User Class、Vendor Class 和厂商特定信息透露用途或实现；Option Request Option 列出客户端想要的参数。旧地址提示与缓存的 Server Identifier 还会把先前的网络状态带到新链路。

这些值不必单独具有全球唯一性。关联者只需要足够罕见的组合。一个长期不变的 DUID 加上一组固定排序的请求选项，就可能把两次观察连接起来。某些 DUID 类型若包含链路层地址，更会直接抵消无线地址随机化。观察者甚至不必知道设备属于谁，仍能判断“这大概是同一台”。

Huitema、Tomek Mrugalski 与 Suresh Krishnan 在 2016 年发表 RFC 7844，把解决方案写成共同的客户端配置。它的目标不是把设备从世界上抹去，而是在用户选择匿名模式时，减少 DHCP 自己贡献的稳定线索。共同二字很重要：如果每家实现都以独特方式保护隐私，那些差异本身就会成为新的指纹。

DUID 的寿命必须有边界

普通 DHCP 运维偏爱稳定标识。服务器认出回访客户端，便能续租、保留策略和减少重复状态。匿名模式改变了交易目标：如果链路层身份已经更新，旧 DUID 却继续出现，它就成了跨越两次连接的桥。

RFC 7844 因而把 DHCP 标识符的生命周期绑到链路变化上。采用随机链路层地址时，DUID 不能悄悄比与它配套的身份活得更久；在相关的非随机化情形中，规范也给出了随机 DUID-LLT 的处理。2026 年的 DHCPv6 基础规范 RFC 9915 仍以 DUID 稳定为一般原则，同时明确承认 RFC 7844 的匿名例外。这不是规范互相矛盾，而是两个运行合同各有边界。

IAID 范围更小，却不能被做成永久机器签名。它所需的稳定性只属于当前链路层关联。审计时真正该问的不是“这个数字是否稳定”，而是它对谁稳定、跨越了什么变化、服务了哪种连续性。

旧地址也如此。客户端要求继续使用过去的地址，可能减少中断，却也主动披露了先前连接。匿名配置在链路层地址改变时清除已存地址。便利的重逢与更干净的断点不能同时免费获得。

没有名字的列表也会认人

RFC 7824 区分了直接标识与指纹。不同客户端索取不同组合的配置参数，也常按固定顺序排列。这种“购物清单”可能暴露操作系统或 DHCP 实现家族，哪怕报文里没有一个看似属于身份的字段。

RFC 7844 的办法不是再加一个宏大标签，而是减少规则性：只索取必要的最小子集，改变请求顺序，不因缓存存在就重发旧值，不习惯性携带 User Class、Vendor Class、厂商信息或 Client FQDN。局部网络或许需要一个仅在本地有效的 FQDN，但它不应变成随设备旅行的公开姓名。

规范甚至拒绝设计“我要匿名”的专用标志。一个客户端若公开声明隐私意图，就可能被单独归类、阻断或重点观察。稀少的临时地址选项同样可能暴露意图：名称听起来像隐私功能，不等于在线路上就更难识别。

这体现了最小共同规范的价值。标准没有强迫所有客户端说更多，而是让它们以更少、更一致的方式说话。未来决定仍留给用户；共同层只负责降低无意泄露。

规范没有删除其他观察者

RFC 7844 明确把无线电指纹排除在范围之外。硬件发射特征、流量时序、应用账号与其他协议仍可能建立关联。承认边界不是软弱，而是让 DHCP 改进保持可验证：它能减少哪些字段，就只对这些字段作出主张。

运维成本也被摆在台面。服务器无法认出回访客户端时，旧租约可能一直保留到到期，新身份又获得新状态；频繁变化会增加地址池或绑定表占用。只允许预登记链路层地址的网络，可能直接拒绝连接。依赖稳定身份的状态服务也会失去连续性。

这些结果不等于技术失败。它们表明参与者追求不同目标：服务器希望节省状态，准入系统希望有稳定抓手，用户则可能不希望两次到访被合并。RFC 7844 把是否启用配置的权利留给用户，同时要求诚实描述代价。

Huitema 留下的是克制的方法

IETF 档案显示 Huitema 长期参与互联网标准，并在离开 Microsoft 后继续从事隐私与 QUIC 工作。他的个人简介把运输、命名、安全和信息自由放在同一条职业轨迹上。但 RFC 7844 并非单人发明：Mrugalski 与 Krishnan 共同署名，RFC 7824 的分析也来自更广的 DHCP 社群。

这段历史的意义不是英雄叙事，而是一种检查方法。一个协议可以通过许多普通字段的组合泄露连续身份。修复便要先清点全部观察面，再为它们指定同一个变化边界，并拒绝把局部改善包装成完全匿名。

标识符不是人，稳定值也不是所有权。它只是特定策略下产生的一张收据。Huitema 参与制定的配置要求我们在正确范围内阅读收据，也要求客户端在它不再服务于用户目的时，不要把它带过下一道门。

来源