跳转到主要内容

主要领域

基础设施

在 主要领域 分类下,基础设施 按主要领域组织行业情报,帮助读者聚焦互联网基础设施、治理、连接市场或数字资本等方向。页面汇集了相关文章、公开证据、机构、公司、人物、区域关联、运营依赖和市场环境,这些内容可能分散在多个分类页面中。页面解释了该领域、可能的行为主体类型、市场或治理背景,以及读者比较信号时应使用的参考来源。运营商、分析师和治理领域的读者可以观察同一领域如何在事件、档案、市场变化、公开来源证据、区域依赖和更长周期的基础设施决策中随时间显现。

APNIC 曾称 RPKI 镜像收益有限,NNIX 试点检验的是另一种收益

报道

APNIC 曾称 RPKI 镜像收益有限,NNIX 试点检验的是另一种收益

2025 年 10 月,APNIC 研究的是主仓库长时间不可达时,一份镜像能为刚启动的验证器争取多久;答案约为五天,收益被评为“非常有限”。七个月后,APNIC 与 NNIX 在杭州提出镜像试点,公开目标却转向时延、验证速度和数据可用性。同一个“镜像”名词,正在回答两道不同的问题。

2026年8月30日
ARIN 的 NET 权限会随查找路径改变

报道

ARIN 的 NET 权限会随查找路径改变

一项权力可以很窄,却不能是盲的。ARIN 的一份社区建议记录称:父级网络的直接登记方可以删除一个详细重新分配出来的子级 NET,也能用精确起止地址找到它,却不能用同一把 API 密钥按 handle 读取它。这里真正需要解决的不是“既然能删,就该什么都能看”,而是一次不可逆回收在执行前能否看清对象身份、当前状态与影响边界。

2026年8月30日
AFRINIC 现行 RPKI CPS 把其管理区域写成了亚太

报道

AFRINIC 现行 RPKI CPS 把其管理区域写成了亚太

AFRINIC 当前资源认证页面仍把读者引向一份 2020 年 5 月发布的 3.0 版认证实践声明。文件第 V.8 节用 AFRINIC 的名称搭配了 APNIC 的服务区域。真正需要修复的不只是一处地名,而是这次修改能否留下版本、授权与回读证据。

2026年8月30日
旧报文如何杀死新连接:TCP 的 TIME-WAIT 暗杀

IETF

旧报文如何杀死新连接:TCP 的 TIME-WAIT 暗杀

TCP 连接关闭时,它的所有报文副本未必已经从网络中消失。TIME-WAIT 负责隔开同一段会话的前后两次生命;RFC 1337 揭示,一段旧报文如何借助正常的 TCP 应答,诱发提前结束这段隔离期的重置报文。

2026年8月30日
每份证据都是真的,拼出的机器却可能不存在:RFC 9999 与远程证明的组合权

案例档案

每份证据都是真的,拼出的机器却可能不存在:RFC 9999 与远程证明的组合权

一台服务器可以提交 CPU、SmartNIC 与 GPU 三份格式正确、签名有效的证明,仍然没有回答最关键的问题:它们是否来自此刻请求权限的同一台机器。RFC 9999 让异构证明能够被统一封装和转交,但成员绑定、时效判断、可信评估与业务授权仍然各有权责。

2026年8月30日
RIPE NCC 报告 IPv4 队首已等 467 天,公开队列还缺一张流量账

报道

RIPE NCC 报告 IPv4 队首已等 467 天,公开队列还缺一张流量账

RIPE NCC 的等待名单同时运行着两只钟:公开表格每三小时刷新一次,8 月会员更新中的队首 LIR 却已经等待 467 天。高频快照能告诉人们队列此刻有多长,却不能解释一个月里有多少申请进入、多少 /24 发放、多少请求撤回。

2026年8月30日
LACNIC 公布了 98% 的外联满意度,却没有公布回复数

报道

LACNIC 公布了 98% 的外联满意度,却没有公布回复数

LACNIC 称,2025 年的会员见面活动覆盖了 5 个国家、7 座城市和 330 多家组织;在“收到的回复”中,98% 落在最高满意度区间。这个限定写得谨慎,但公开记录仍少了一个决定解释边界的数字:究竟收到多少份回复。

2026年8月30日
两边的地址都没错,重连后却只能留一个:RFC 10019 与零配置组播的冲突裁决权

案例档案

两边的地址都没错,重连后却只能留一个:RFC 10019 与零配置组播的冲突裁决权

网络分区会制造两份各自诚实的历史:两边都看不到占用,都分配出可用的组播地址,也都让应用开始发送。链路恢复时,问题不是找出哪一本账造假,而是承认旧观察范围已经失效,并决定谁迁移、怎样迁移,以及用什么证据证明新旧流量没有被混淆。

2026年8月30日
ARIN 把 1.7 万个历史网络写进博客,却没有给出完整状态表

报道

ARIN 把 1.7 万个历史网络写进博客,却没有给出完整状态表

ARIN 公开了一组少见的具体数字:数据库中约有 1.7 万个历史网络,大约一半没有联系人或联系人无法核验,当前已验证的仅占 11%,另有 20% 的联系信息不完整。数字本身未被证明有错;真正欠缺的是一张带时间戳的汇总表,用来说明“网络、组织、POC 记录”三种统计单位如何连接。

2026年8月30日
APNIC 2026 年与 SANOG 签了 MoU,公开链接却仍停在 2003 年的“xxx”

报道

APNIC 2026 年与 SANOG 签了 MoU,公开链接却仍停在 2003 年的“xxx”

SANOG 44 的议程和 APNIC 的会后记录都确认了 2026 年的签署,签署人及合作范围也已公开;然而,APNIC 当前合作伙伴页面上的 SANOG 文书链接仍打开一份 2003 年文件,正文日期保留着 `xxx`,APNIC 的签署人和职务栏则是空白。问题不是推定哪份文件无效,而是公共记录没有说明两份文书之间是什么关系。

2026年8月30日
探针走了同一条路,却没排同一个队:RFC 10014 与 OAM 的证据边界

案例档案

探针走了同一条路,却没排同一个队:RFC 10014 与 OAM 的证据边界

业务流遭遇拥塞时,探针完全可能穿过同一组节点和链路,却因为进入了更高优先级的队列而一路畅通。RFC 10014 的价值,是把过去常被“带内 OAM”混在一起的三个事实重新拆开:测量如何参与流量、是否走同一路径、是否受到同样的转发待遇。

2026年8月30日
ARIN把ROA与IRR对象连在一起,可见操作记录却只在ROA一侧

报道

ARIN把ROA与IRR对象连在一起,可见操作记录却只在ROA一侧

ARIN 的 IRR Auto-Manager 让一次操作可以同时留下两类记录:一份 ROA,以及与它关联的 IRR 路由对象。这项自动化确实减少了重复工作。问题出现在两者后来分开时:公开说明的变更历史能够解释 ROA 发生了什么,却还不能还原生成、关联、保留或删除 IRR 对象的完整操作。

2026年8月30日
ICANN 给 SSE 申请人 21 天提出异议:第一天应保存什么?

ICANN

ICANN 给 SSE 申请人 21 天提出异议:第一天应保存什么?

21 天窗口启动时,申请人往往还没有完成是否提出异议的专业判断。因此,第一天最重要的不是仓促形成结论,而是把决定、传送与接收事件、适用规则、潜在错误及后续提交材料纳入同一条可核验记录。

2026年8月30日
AFRINIC申诉委员会五个席位均于12月31日到期

报道

AFRINIC申诉委员会五个席位均于12月31日到期

AFRINIC 于 8 月 28 日补齐政策制定申诉委员会,五人的公开任期却没有错开:全部到 2026 年 12 月 31 日止。若把首尾两天都计入,这一首段任期覆盖 126 个日历日。短任期本身不能证明委员会有瑕疵,但它把续任决定和未结工作的保管同时压在一个年末节点上。

2026年8月30日
ICANN 确认 SSE 出错后还要重新评估:两次决定如何衔接?

ICANN

ICANN 确认 SSE 出错后还要重新评估:两次决定如何衔接?

申请人可能赢得 ICANN 字符串相似性评估挑战,却还没有赢得新的评估结果。中间不可省略的是重新评估记录:挑战确认了什么、评估人员重新考虑了什么,以及后来的决定如何承接第一次决定。

2026年8月30日
四个批次都返回了,邮箱却从未被冻结:RFC 10022 与 UIDBATCHES 的结案权限

案例档案

四个批次都返回了,邮箱却从未被冻结:RFC 10022 与 UIDBATCHES 的结案权限

RFC 10022 允许 IMAP 服务器用几个 UID 区间,为大邮箱预先划分后续工作。区间的端点可以没有对应邮件,实际数量可以少于请求值,旧区间会因删除变稀,新邮件则在原最高 UID 之外继续增长。因此,`OK UIDBATCHES completed` 只证明“地图算完了”,不证明地图里的工作已经执行,更不证明整座邮箱已经被清点。

2026年8月30日
许可证失效了,配置却没有消失:RFC 10016 与系统状态的执行权

案例档案

许可证失效了,配置却没有消失:RFC 10016 与系统状态的执行权

一项功能被关闭时,设备可以撤下由系统生成的节点,控制器却仍保存着自己的配置意图。RFC 10016 把这类分歧从厂商私有行为带进标准数据模型,也迫使管理者回答:设备提供的值、客户端提交的值、经过合并的目标与真正运行的状态,究竟由谁负责。

2026年8月30日
MENOG 本地主办方可以签合同,但批准权仍在秘书处

MENOG

MENOG 本地主办方可以签合同,但批准权仍在秘书处

MENOG 把大量现场工作和可见权益交给本地主办方,同时在主办要求里划出一条清楚的边界:主办方可以代表 MENOG 秘书处签署服务合同,但签署必须取得秘书处批准。

2026年8月30日
树已激活,第十二个叶子却一包未收:RFC 10018 与多点交付的结案边界

案例档案

树已激活,第十二个叶子却一包未收:RFC 10018 与多点交付的结案边界

多点业务最容易被“多数成功”掩护:根节点只发一份,网络在途中复制,十一处有流量,第十二处全黑,汇总曲线仍像一次成功变更。RFC 10018 为 MVPN、EVPN 与 SR-MPLS/SRv6 P2MP 建立了清晰的互操作接口;它并没有把路由通告、控制器回执或 Tree-SID 变成所有叶节点的收货单。真正可结案的对象,是同一个树版本下逐叶对齐的意图、成员、安装、转发、OAM 与业务结果。

2026年8月30日
版本没有退场,旧握手必须退场:RFC 10015 与 TLS 1.2 密钥交换的执行权

案例档案

版本没有退场,旧握手必须退场:RFC 10015 与 TLS 1.2 密钥交换的执行权

把 TLS 1.2 留在允许清单,不等于把它历史上所有握手方式一并保留。RFC 10015 划出更窄也更难执行的边界:有限域 DH 与 RSA 密钥交换必须从 1.2 的协商路径中消失,静态 ECDH 应当退出,而配置是否真正生效只能由运行中的端点和观测到的握手证明。

2026年8月30日