时间范围
Immediate 0 30d
在时间范围维度下，Immediate 0 30d时间跨度情报按信号预计产生影响的时间段组织文章。该页面帮助读者区分即时运营变化与可能需要数季度或数年才会逐步显现的长期治理、投资、标准和基础设施变化。它将时间预期与公开证据、相关方、市场背景、客户影响、政策压力和基础设施规划联系起来，以便读者判断某项动态是紧迫、具有战略意义，还是仍在等待证实证据。页面还解释了时间跨度如何改变信号的含义、哪些组织可能面临风险，以及哪些基础设施决策需要短期行动或长期监测。
报道
ARIN IPv6 草案将单站点 /48 与多站点扩展公式分开
ARIN-2025-7 号 Recommended Draft Policy 是一次范围有限但可验证的文字澄清：在不改变资格标准的前提下，让每个有依据的站点数量对应一个可预测、按 nibble 对齐的 IPv6 分配结果。
报道
ARIN-2025-1：术语修订为何改变规则适用对象
草案把实施标为“Immediate”，而 ARIN 工作人员估计培训、文件、流程和应用程序更新需要六个月。这是来源中的两种不同表述，并非 BTW 制造的矛盾。
报道
APNIC上线公开查询账本，但会员视图并未上线
APNIC 上线公开查询账本，但会员视图并未上线 的情报摘要说明事态进展、可核验的公开证据、相关组织、区域背景、市场风险敞口，以及可能带来的基础设施影响。报道情报 语境将这一信号与网络运营、服务商策略、治理决策、资本流动、客户依赖、监管压力、合作关系动向、韧性规划、采购风险和服务连续性联系起来。
报道
APNIC 已建成 RPKI 吊销机制，但行使权限的制度依据仍在追赶
APNIC 表示，prop-166 的技术实施已经完成，但公开记录仍将该政策列为“实施中”，认证实践声明和 RPKI 条款与条件的更新尚未完成。这个差距并非文字细节：该提案拟允许 APNIC 在自托管 RPKI 认证机构持续失效超过 60 天后，吊销其资源证书。
报道
APNIC prop-175 把 IPv6 需求证明提前到首次申请
APNIC prop-175 拟允许符合资格的机构在首次申请时，就以已经明确的运营需求证明其需要大于 `/48` 的运营商无关 IPv6 地址。该提案目前仍只是在 Policy SIG 邮件列表发布。它试图减少重复程序，但真正的治理考验在于：部署尚未发生时，APNIC 能否像审查既有使用情况那样一致地审查规划证据。
北美云服务趋势
Opti9买走云服务，机房仍留在Hut 8
这笔加拿大交易转移的是客户服务、部分设备和十名员工，不是数据中心产权。原本在同一家公司内部解决的协同问题，今后要由一份多年托管协议承担。
报道
APNIC prop-164 将更小的 IPv6 分配变成一场保留空间治理测试
APNIC prop-164 拟允许账户持有人从小于 `/32` 的 IPv6 分配起步，同时为未来增长保留空间。它可能改善 Whois 和 RDAP 的准确性，但真正的检验在于：保留空间能否始终是一项可见、可审计的注册管理承诺，而不是默认形成的隐性权利。
报道
APNIC扩大IPv4分配前，必须先制定排队规则
APNIC 的 prop-168 将允许符合条件的账户持有者把合计持有量提高至/22，同时提议设立独立的/12 过渡储备。该提案规定谁可以申请以及最多能获得多少地址；但其自身的稀缺性计算表明，当合格需求超过普通供应时，它还必须规定谁应当优先。
报道
ARIN 的 RDAP 转型需要三道不同的退出验证关口
ARIN 希望以一种标准化目录协议取代三项旧服务。目标本身清晰；真正的运营考验，是证明 Whois-RWS、RWhois 和 43 端口 Whois 能够依据各自承载的用户与依赖关系退出。
报道
APNIC prop-170 必须量化 IPv6 需求与十六进制对齐之间的空间
一个技术上有效的 IPv6 前缀，不一定是易于运营的地址单元。APNIC prop-170 将允许 LIR 在需求已经得到验证后，申请能够满足该需求的最小四位边界对齐地址块。提案试图在不放弃按需分配的前提下改善地址规划；其可信度取决于，对齐所增加的空间能否保持可见、可审查且有条件。
报道
APNIC 的 IPv4 需求测试应衡量实际审核的地址块
APNIC 的 prop-169 拟把 LIR 使用计划测试中固定的 `/23` 改为实际接受审核的地址委派。这项改动范围很窄，但证据应对应申请者真正提出的请求，而不是一块未必会被分配的更大地址空间。
报道
APNIC prop-174 将滥用邮箱纳入有约束力的政策义务
prop-174 拟把 APNIC 滥用邮箱的操作惯例写成明确政策义务。这能让联系渠道是否有效更可衡量，但也会使投递、过滤、分流和回复记录进入一条最终可能触及会员责任的证据链。
报道
APNIC 的 prop-173 将目录查询变成治理议题
Prop-173 拟为 APNIC 的普通 WHOIS、RDAP、网页查询及同类 API 制定一份公开、可追溯版本且独立于批量访问协议的可接受使用政策。关键不只是有没有条款，而是能否清楚区分正当的网络运维复用与替代性数据库，并为自动化限制提供有效复核。
报道
APNIC 可以定义互联网滥用，但不应成为案件裁判者
Prop-172 试图为涉及 IP 地址的互联网滥用建立共同词汇。它能否成立，关键不在清单有多长，而在边界是否清楚：给行为命名，不等于授权 APNIC 判定举报、监控网络或施加处置。
案例档案
版本相同，路由现实却分叉了
两台 RPKI 验证器显示相同的 RRDP 会话标识与最新序号，并不代表它们走过同一段仓库历史。只要某个已经见过的增量文件在同一会话、同一序号下换了哈希，两台机器就可能各自保持内部自洽，却输出不同的验证载荷。RFC 9697 给出的修复不是相信屏幕上的版本号，而是保留旧证据、识别历史被改写、从最新快照重新同步，再逐层验证到路由与报文。
案例档案
序列号相同，区域却不是同一个区域
一份 DNS 区域已经传完，SOA 序列号与变更单完全一致，文件也能正常解析；但其中一条 glue 记录在落盘时丢失。版本号只能说明发布者把它叫作哪一版，传输认证只能说明数据经过哪条获准通道。ZONEMD 增加的是第三项判定：准备启用的整份区域，是否真是发布者为该序列号承诺的那一份内容。
案例档案
控制器算对了，但它依据的那座桥已经断了
链路故障后，两个 BGP-LS 生产者各自保留了相反方向的一半旧信息。消费者把两半拼成一条看似完整的链路，控制器据此算出一条完全合规的路径。算法没有算错；真正失控的是一份没有明确作者、时效和撤回边界的拓扑陈述。
案例档案
会话都正常，路由却没有来：被忽略的反向订阅链
某个新 VRF 已经绑定正确的导入 Route Target，源端也确实存在目标 VPN 路由，但接收 PE 始终看不到它。RFC 4684 让“需要哪些路由”的意图先逆向传到源头，再让匹配的可达性返回。若只检查 Established 会话和源端路由，就会漏掉真正断开的那一段。
ICANN
ICANN 先扩大项目基金，后补资格规则
一笔钱进入治理系统时，最容易被忽略的并不是金额，而是顺序。先有项目、再有标准，与先有标准、再让项目接受检验，可能得到相同的“合格”标签，却不是同一种问责。ICANN 董事会在 2026 年 5 月 3 日把原本服务于获批社群建议的 SFICR 扩大为可资助“任何合格项目”的项目基金，同时要求总裁兼首席执行官或其受托人另行制定资格规则。25 天后，一笔预计为 1,800 万至 2,100 万美元的 FY26 运营盈余已经让这项先后关系具有现实意义。钱尚未获分配，项目也尚未获批；真正需要提前固定的是规则、事实与决定之间的连接方式。
案例档案
先问零出现在哪个字段
AS 0 在 BGP 中不是可以暂借的编号，却也不能靠“发现了数字 0”来处置。ORIGIN 的取值 0 合法表示 IGP，AS 0 ROA 则是 RPKI 中的不路由声明。RFC 7607 真正建立的，是按字段拒绝一个无效身份、同时保护无关有效状态的权力边界。