摘要

  • draft-munizaga-quic-alternative-server-address-02 让服务端用递增序号发布一份完整候选地址集，并以 CURRENT_PATH 区分优先项与备用项；它仍是没有正式 IETF 地位的个人互联网草案。
  • 发布地址不会创建路径。优先值只是相对提示，客户端可依本地策略忽略，普通数据还必须等相应方向的路径验证成功。
  • 运维记录应分别保存公告版本、本地准入、方向性验证、实际使用和聚合影响，因为大量客户端同时遵循同一提示，可能把一次合法协调变成针对第三方的“惊群”。

这项机制解决的是一个真实但很窄的问题：连接已经建立，服务端的地址条件却发生变化。现有握手期 preferred_address 无法持续更新。修订版 02 引入 ALTERNATIVE_ADDRESS 帧，让服务端在加密连接内交付一份可替换的地址地图。

“地图”不是“指令”。帧带有 Sequence Number，较大的序号原子替代客户端最近处理的旧集合；网络即使把帧送乱，客户端也能拒绝倒退。新集合没有出现的地址不再由这项扩展公告。它证明的是服务端当前声称什么，并不证明客户端已经停止旧探测、清除在途包或同步完成切换。

清单中必须恰好有一个 CURRENT_PATH。没有协商 multipath 时，标记前的地址高于当前路径，标记后的地址只作为备份。同一侧的数值越小越优先，相同数值表示服务端无进一步偏好；两侧数值不能横向比较。把整个表格当成一个全局排行榜，会给数字添上规范并未提供的权力。

草案明确说 Priority Hint 是建议。客户端自己决定探测哪些地址、是否并行、使用哪条已验证路径，也可以因本地政策完全不按顺序行动。私有 IPv4、ULA、企业边界、NAT、耗电限制和安全策略，都可能使同一地址对不同客户端产生相反答案。

因此，第一张凭据是公告，第二张是本地准入。后者至少要写明客户端接受了哪些候选、拒绝原因、可用 Connection ID 数量、并发探测上限和随机延迟。若没有未使用的连接标识符，客户端甚至无法同时验证所有“高优先”地址。

路径验证也有严格边界。客户端向候选路径发送 PATH_CHALLENGE。匹配的 PATH_RESPONSE 可以从另一条路径回来，却仍验证挑战所发送的那条路径。反过来，从未公告源地址收到一个认证成功的探测包，并不会把该源地址自动变成已验证路径。证据属于挑战、目标四元组和方向，不能借给承载回包的任意源地址。

服务端在向新路径发送非探测数据之前，还要验证自己的发送方向。验证之后，客户端可能迁移，也可能在 multipath 中增加路径、只保留备份或根本不用。Multipath 草案不规定应用调度算法。RTT、丢包、拥塞窗口和应用连续性，只能由真正承载流量的路径证明。

安全章节最值得领导层注意。恶意服务端可以让大量客户端都把同一受害地址视为更高优先级。单个客户端的帧有认证、路径也可能验证成功，但群体同时迁移仍会造成冲击。草案只建议用随机延迟缓和，没有定义全局速率预算、受害端同意凭据或“已经有多少客户端正在汇聚”的共享信号。

这正对应 Heng Lu 对协调与权力的区分：共同规范应只定义能互操作的最小语法，未来行动由承担本地风险的运行主体决定。服务端记录不能替代客户端决定，客户端路径成功也不能替代目的端容量与应用结果。文件发布、IANA 请求、实现声称和真实部署是四层事实。

截至冻结时点，9 月 25 日的修订版 02 是个人草案，Datatracker 状态为 I-D Exists，没有 stream 或负责 AD。草案请求的临时代码在保存的 IANA QUIC 注册表快照中尚未出现。证据包也没有产品实现、互操作测试、性能收益、采用率或已发生攻击的材料。

来源