上线为什么需要清单
六层上线失败的原因很少出在链路本身，多数是配套没跟上：地址拿到了但没有下发方式、地址下发了但解析没有记录、解析有了但防火墙把必需的差错报文挡在外面、监控按单个地址编写在地址轮换后疯狂误报。按清单逐项确认，可以把这些问题在上线前消除。
清单的六项
第一项是前缀到位，无论通过委派获得还是静态配置；第二项是下发方式明确，通告报文的标志位与解析信息按设计下发；第三项是解析记录齐备，正向与反向都要有；第四项是防火墙策略按必需类型放行；第五项是监控按前缀编写；第六项是保留四层回退路径并准备双栈验证脚本。
基本信息
| 前缀来源 | 通过委派获得，或静态配置固定前缀 |
|---|---|
| 下发方式 | 通告报文的标志位与解析信息按设计配置 |
| 解析记录 | 正向与反向记录都要创建并验证 |
| 防火墙 | 必需类型的差错与邻居发现报文必须放行 |
| 监控与回退 | 按前缀编写告警，保留四层回退路径 |
典型使用场景
- 新业务上线：按清单逐项确认后再切换流量，避免上线当天才发现缺项
- 故障复盘：现有问题逐条对照清单，快速定位是哪一项缺失或配置错误
- 规范制定：把清单固化为内部上线流程，减少对个人经验的依赖
- 双栈验证：验证脚本同时覆盖两种协议，确认服务在两条路径上都可用
- 监控改造：把按单个地址的告警改为按前缀，地址轮换不再触发误报
- 回退演练：切换前演练一次回退流程，确认四层路径仍然可用
检查清单
检查清单
第一项 前缀：委派或静态配置已就位
第二项 下发：通告标志位与解析信息按设计配置
第三项 解析：正向与反向记录双查
第四项 防火墙：必需类型差错与前缀发现报文放行
第五项 监控：按前缀告警，避免地址轮换误报
第六项 回退：保留四层路径，验证脚本覆盖双栈就绪快检
就绪快检
ping -6 2606:4700:4700::1111 # 出网连通性
ip -6 route show default # 默认路由是否存在
curl -6 -sI https://[示例地址]/ # 服务可达性（示例）
dig +short AAAA 示例域名 # 正向记录是否可解析常见缺项与表现
| 缺项 | 典型表现 | 排查入口 |
|---|---|---|
| 解析未下发 | 能通地址不能解析域名 | 查看通告内容 |
| 防火墙拦差错报文 | 小包通大包不通 | 放行差错报文 |
| 监控按单地址 | 地址轮换后频繁误报 | 改为按前缀 |
| 无回退路径 | 切换异常后无法快速恢复 | 保留四层并演练 |
监控要按前缀而不是按单个地址编写：终端普遍使用会定期变化的隐私地址，按单个地址告警会在地址轮换时产生大量误报，让人对告警失去信任。
上线顺序建议先通再切：先并行开通六层路径并验证，确认可用后再逐步切换流量，异常时立即回退到四层，整个过程的耗时可以控制在分钟级。