一份叫 IPv7 的 IETF Internet-Draft，很容易被名字带偏。
它不是“IPv6 之后的官方新协议”。目前能看到的定位，是个人提交的 draft-subbiah-ipv7-00，仍是 work in progress。IETF draft 本来就可能更新、替换、过期或消失。标题里提到 Rust implementation，但现有材料不足以展开实现细节，更不能当成成熟部署信号。
更值得看的是它想改什么：把 IP 层从“只负责把包送到”，往“这个包从谁那里来、能不能被验证、该不该被信任”推了一步。
IPv7 草案想解决的不是寻址，是滥用归因
IPv4/IPv6 的基本气质，是可达性优先。地址主要说明网络位置，不天然说明真实身份。这个设计让互联网长得快，也留下了安全债。
草案瞄准的，是今天最难处理的几类滥用：住宅代理、IoT 设备沦为代理或僵尸网络、欺诈、撞库、DDoS。
住宅代理尤其麻烦。攻击流量披着家庭宽带的外衣，看起来像普通用户。风控系统下手太轻，拦不住；下手太重，误伤一片。
IPv7 草案的思路，是让源地址变成一种可验证的身份声明。不是让每台路由器都知道“你是谁”，而是让网络知道：这股流量是否来自它声称的提供商，是否带有可验证来源，能不能进入某种策略处理。
| 机制 | 草案里的作用 | 现实指向 |
|---|---|---|
| 身份化源地址 | 地址中包含 service、location、Provider ID、tenant、role/policy 等字段 | 让来源更容易归因 |
| VLIB | 可变长度身份块，承载 EIT、Provider ID、策略和签名 | 把身份信息塞进包头结构 |
| EIT | 临时身份令牌 | 避免长期身份直接暴露给中间系统 |
| Origin Signature | 来源签名 | 证明流量确由声明来源发出 |
| Source-Provider Validation | 校验 Provider ID 与签名是否匹配 | 提高伪造来源的成本 |
草案也没有说自己能消灭 Botnet、住宅代理或 DDoS。更准确的说法，是提高滥用成本，缩小伪装空间。
这个方向不是空想。应用层风控已经被打穿太多次。只靠账号、Cookie、设备指纹，很难处理“正常家庭 IP 后面跑着异常自动化流量”的问题。
安全团队看到这类草案，短期不会迁移架构，但会多盯两件事：一是来源信誉能不能变成可用信号；二是 ISP、云厂商、CDN 会不会把类似验证能力做进现有网络产品。采购和架构决策不会因为“IPv7”三个字提前下注，但会把“provider-level attestation”这类能力放进评估表。
真正的矛盾：验证权在谁手里
我不反对它要打住宅代理。这个问题真实存在，而且越来越贵。
我更在意的是：身份一旦进了网络层，谁来定义身份，谁来维护信誉，谁有权披露，谁能把一个节点降级、限速、隔离，甚至封掉。
草案强调隐私。长期用户身份不暴露给中间系统，中间系统看到的是 EIT 这类临时令牌。验证和披露主要留在 provider 侧。
这听起来克制。问题也正出在这里。
权力会集中到 ISP、云服务商、策略系统和合规接口手里。协议层说的是验证，落地后常常会变成风控、审查、执法协作、商业分层一起进场。
“天下熙熙，皆为利来。”放到网络协议里，就是安全目标不会单独行动。它会和商业激励、监管压力、平台控制一起行动。
这和电话实名制不完全一样，也不等于平台账号体系。更像是把账号化治理往底层压了一层。应用层封号，用户还能换平台；网络层信誉受损，影响面更硬，申诉路径也更远。
| 受影响对象 | 可能得到什么 | 可能付出什么 | 更现实的动作 |
|---|---|---|---|
| 安全团队 | 多一个识别伪装住宅流量的信号 | 依赖 provider 信誉质量，误判责任更难切 | 先观望标准进展，把来源验证纳入风控路线图 |
| ISP/云厂商 | 获得更强验证入口 | 承担密钥、误封、披露、合规压力 | 不会轻易全网改造，可能先做局部试点或私有实现 |
| 普通用户 | 被劫持设备可能更早暴露 | 连坐、误伤、隐私披露风险上升 | 真正受影响时，可能不是“被黑”，而是突然访问受限 |
| 小型网络 | 来源信号更清楚 | 部署、互联、策略对接成本更重 | 大概率等大厂和运营商先动，自己不先烧钱 |
最硬的现实约束，不是 header 怎么写。
是部署。
IPv6 推了这么多年，已经说明基础协议不是靠一份 draft 就能滚动升级。更何况 IPv7 草案碰到的不只是技术兼容，还有跨域信任、密钥轮换、签名性能、策略一致性、误封申诉、供应商锁定。
路由器能不能处理是一回事。运营商愿不愿背锅，是另一回事。
反方技术观点也不难理解：与其重写 IP 层，不如继续加强 BCP 38、RPKI、MANRS、DDoS 清洗、应用层风控、设备侧安全和网络准入。它们不完美，但更贴近现有部署路径。
所以，IPv7 草案目前更像一份压力测试题：当应用层和边缘防御不够用时，行业会不会接受“把身份前移到网络层”这条路。
接下来别看名字，看三个变量
如果只问“IPv7 会不会取代 IPv6”，问题就问偏了。
眼下没有证据支持这种判断。它还只是个人 Internet-Draft，不是 IETF 标准，更不是官方下一代 IP 协议。
真正该看三件事。
一看它是否进入更正式的 IETF 讨论轨道。个人 draft 很常见，能不能变成工作组议题，是完全不同的门槛。
二看实现和互通。标题提到 Rust implementation，但没有足够材料说明它的成熟度、性能、兼容性和真实网络测试。没有互通，协议只停在纸上。
三看大网络的态度。ISP、云厂商、CDN、安全厂商如果只把它当概念，那影响有限；如果他们开始用类似机制做来源证明和信誉接口，哪怕不叫 IPv7，也说明方向在落地。
历史上，铁路、电力、电话、互联网都经历过类似阶段：先是连接问题，后是治理问题。连接越密，滥用越多；滥用越多，管理权就会往基础设施层下沉。
但历史类比只能像三成。互联网比铁路更开放，比电话更分散，也比传统基础设施更依赖端到端创新。把身份塞得太深，可能压住的不是坏流量，而是小玩家、边缘服务和匿名表达。
我的判断很简单：这类方向会反复出现，名字未必叫 IPv7。
住宅代理、IoT 僵尸网络、自动化欺诈会继续把压力推给基础设施层。应用层风控不够用，CDN、ISP、云厂商迟早被拉进来。
但代价也会一起到场。网络越聪明，越不像公共道路，越像有门禁、有评分、有执法接口的园区。
安全债确实要还。可如果还债方式是给每个包都挂上可治理身份，那账本归谁管，就比协议版本号重要得多。
这份 IPv7 草案的价值，不在于它是不是下一代 IP。它提醒我们，互联网底层争论正在从“怎么把包送到”，转向“谁有资格把包送到”。