OneNote 笔记显示空白却提示已是最新，这种怪病一位日本用户忍了近三周，微软支持查了五周没头绪，最后是一个 AI 代理陪他抓了一晚上网络包找到真凶。肇事物料就躺在系统里，随 Windows Update 装进来的英特尔连接性能套件。这起事件上周起在技术社区发酵，我把当事人自建的事故报告站、原始分析帖和规范原文都核了一遍，全程值得细说。
出了什么事
先讲机制，尽量说人话。IPv6 数据包头部有个二十位的流标签字段，规范要求连接期间保持不变。涉事驱动的流量控制组件在握手完成后，把后续每个包的流标签改写成零。微软云服务的边缘负载均衡用这个字段决定数据包送往哪台后端服务器，标签被清零后，后续包被哈希到另一台从没参与这条连接的机器上，对方直接回一个重置信号，连接瞬间断掉。受害者的抓包数据触目惊心，一千三百八十五个包的流标签被清零，新建 IPv6 连接六成到十成在一个往返时间内被掐灭。IPv4 没有这个字段，毫发无损，这也是故障难查的原因，症状只出现在特定服务上。
规范层面没有模糊地带。互联网标准文档原文写着，中间节点不得把非零流标签改为零，改写即违规。
排查与修复路径
当事人的取证过程本身是亮点。先用另一个编程代理查了一晚无果，换 AI 代理直接跑在故障机上，确认 IPv6 到微软云端被单次往返重置，抓包发现重置信号与握手应答来自不同机器，逐个隔离网络过滤驱动后锁定目标服务。禁用相关服务后，十个连接十个成功，六十五个包全部保留标签，OneNote 一分钟内恢复同步。
普通用户的自检方法一条命令就够，循环访问一个云服务域名并强制 IPv6，健康机器返回状态码，中招机器报连接重置。修复两条路，禁用那组服务，或卸载整机厂定制版改装英特尔通用版驱动，后者实测一百七十次连接成功一百六十九次。要泼冷水的是，新版驱动的更新说明只写了功能更新四个字，只字未提此缺陷，装新只能算实测有效。等官方修复公告出来前，别用更新目录里的同名旧包，版本号接近不等于内容一致。
影响范围与厂商态度
范围比想象中大。微软更新目录里这套件共一千零八十六条目、四十七个版本、十九家整机厂提交，已验证修复的版本仅一条对应条目，而且面向的设备标识跟中招机型对不上，想等自动更新推到修复版短期内不现实。更早的报错记录显示，去年九月就有用户在英特尔社区发帖描述完全相同的问题，两次被以未收到回复为由关闭。
三家厂商的回应状态同样如实用录。英特尔收到案例后追问无答复，无公告无确认。微软支持五周后失联，投诉已升级到驱动分发团队。受害者在三星社区发帖一度被垃圾过滤器吞掉，客服回复仅作记录，正式投诉信已发往三星美国总裁办公室。整起事件里行动最快的是一台笔记本上的 AI 与它的主人。
解决了什么需求
对普通读者，这篇的价值是一份对照清单。OneNote 或网盘长时间不同步、浏览器登录页打不开、换网络就正常，这类症状先怀疑 IPv6 连接，一条命令自检，别急着重装系统重置网络，受害者把常规手段试了个遍全无效。跑十次看重现率，高比例的重置一眼可疑。对行业读者，这是基础设施脆弱性的活标本，一个驱动小改动穿过三层厂商的流程缝隙，一年没人接住。装完系统更新后留意一下这个组件的版本号，多一分警觉不亏。警觉有时就是止损。
来源
- 当事人事故报告站 https://coolak.github.io/intel-icps-ipv6-flow-label-incident/
- 技术分析页 https://coolak.github.io/intel-icps-ipv6-flow-label-incident/technical-analysis.html
- CircleID 报道 https://circleid.com/posts/intel_driver_defect_disrupts_ipv6_connections_across_multiple_laptop_brands
- 规范原文 https://www.rfc-editor.org/rfc/rfc6437
- IT之家中文报道 https://www.ithome.com/1/010/369.htm