主要领域
互联网基础设施
在 主要领域 分类下，互联网基础设施 按主要领域组织行业情报，帮助读者聚焦互联网基础设施、治理、连接市场或数字资本等方向。页面汇集了相关文章、公开证据、机构、公司、人物、区域关联、运营依赖和市场环境，这些内容可能分散在多个分类页面中。页面解释了该领域、可能的行为主体类型、市场或治理背景，以及读者比较信号时应使用的参考来源。运营商、分析师和治理领域的读者可以观察同一领域如何在事件、档案、市场变化、公开来源证据、区域依赖和更长周期的基础设施决策中随时间显现。
互联网历史
前缀写着发送者，服务器仍要核对来路：RFC 1459
“消息写着谁发来”与“服务器知道它从哪条连接来”是两件事。1993 年的 RFC 1459 没有让消息开头的名字自证真实：接收服务器还要在自己的数据库中找到该来源，并确认它确实登记在入站连接背后。前缀是一项声明，来路关系才使声明可被接受。
案例档案
解码器报出了 Profile，Level 与 Band 才把工作量说完整：RFC 9924
“支持 APV”只能说明有人贴上了一个类别标签。RFC 9924 要求把 Profile、Level 和 Band 组合起来，分别约束编码特征、图像与分块负荷以及码率；缺少后两项，能力声明仍然没有边界。
互联网历史
标签穿过了网络，它的含义却还没有抵达：RFC 1457
一串比特可以毫发无损地到达终点，一条规则却可能死在解释途中。接收端看见与发送端完全相同的标签，并不等于它知道谁定义了标签、怎样把它换成本地语义、哪个进程获准接收数据。1993 年的 RFC 1457 把这种“形式抵达、含义未到”的落差变成了安全标签设计的核心问题。
案例档案
“符合 CMC”写在产品上，责任角色却没写：RFC 10004
一套系统昨天只服务终端实体，今天被放到注册机构与认证机构之间，同一份合规结论就可能失效。变化的不是标签，而是它承担的角色和条件义务。
互联网历史
六个控制码成了字母，标签必须说明如何解读：RFC 1456
256 个位置像一排已经住满的抽屉。ASCII 字母和标点占据了最容易使用的一半，控制码守着早期终端与通信程序的机关；越南语却还需要容纳 134 种字母与附加符号的组合。RFC 1456 记录的不是一次简单扩容，而是一场兼容性预算：保住哪些旧含义，又把哪些位置改作文字。
案例档案
控制器建好了恢复图，下一个数据包仍要等待本地决定：RFC 9912
无线网络里的“已就绪”至少有三个时钟：控制器准备选项、PLR 根据眼前状况选路、转发面执行数据包。RFC 9912 的价值，正是拒绝把这三个时刻压成同一个绿色状态。
案例档案
恢复图列出了所有可行路径，却没有记录这个包走过哪一条：RFC 9912
RFC 9912 为不稳定链路划出了可控的恢复空间，也留下了一条不能跨越的证据边界：图描述“可能怎样走”，分布式转发才决定“实际怎样走”。
互联网历史
数据包请求最安全的路径，网络却没有承诺保密：RFC 1455
1993 年，一个 IPv4 数据包可以在头部带上四个全为一的比特。它们不是锁，也不是通行证，而是一张写给路由器的便条：如果条件允许，请选择最不容易被网外人员偷看的物理路径。RFC 1455 的价值，恰恰在于它把这句话写进协议时，没有把“请求”伪装成“保证”。
互联网历史
参与方已有名称，三元关系仍须许可操作：RFC 1447
在 1993 年的 SNMPv2 权限表里，数字 35 不是“普通管理员”，更不是信任等级。它只是 1、2 和 32 的和，分别允许 Get、GetNext 与 GetBulk。这个数字只有落到特定发起方、特定接收方和特定资源上下文的交点上，才构成一条可执行的许可。
案例档案
参数是 NULL，不等于参数不存在：RFC 9909 的 SLH-DSA 证书边界
RFC 9909 为 SLH-DSA 进入 X.509 规定了精确的标识与字节格式。系统认得算法名称只是第一步；Pure 与 Hash 模式、参数缺席、密钥用途、证书路径和依赖方策略必须分别留下证据。
IETF
Dave Thaler：观察到阻断，不等于归因于一项政策
页面无法访问、连接被重置或 DNS 回答被改变，都可能是真实观测。但单凭这些现象，不能识别是谁制定了政策、其目的为何，更不能证明影响一定出于故意。
IETF
Suresh Krishnan：链路上线并非端到端可达性的回执
无线、Wi-Fi 或有线接口已经能够传送帧，并不等于客户所需的路径已经可用。Suresh Krishnan 参与编撰的 RFC 4957 的价值，正是在于守住这条边界。
案例档案
分类器给流起了名字，却没有证明它受到怎样的处理：RFC 9892
RFC 9892 让 DLEP 调制解调器向路由器描述报文类别，但一个本地 TID/FID 只能说明分类规则。扩展是否启用、哪条规则胜出、队列是否生效以及业务结果，仍需分别取证。
IETF
Peter van der Stok 与那条不等于端点在线的资源登记
目录里仍有一条资源记录，并不表示资源此刻仍在工作。RFC 9176 把这件事写得很具体：CoRE Resource Directory 保存的是可维护的登记信息，不是对端点在线状态的实时宣告。Peter van der Stok 是这份 IETF 集体成果的五位作者之一。
互联网历史
代理声称实现了对象组，对象仍得亲自回答：RFC 1444
设备清单说“支持”，仪表读数却未必出现。1993 年的 RFC 1444 没有把这两件事混成一个事实。它分别规定对象如何成组、符合性声明最低要求什么、某个产品版本声称实现什么；然后把最难的一步留给运行现场：对象必须给出可信的回答。
案例档案
客户端估算了时延，服务器仍掌握验证窗口：RFC 9891
RFC 9891 允许 ACME 客户端说明延迟容忍网络中的预计往返时间，但这项说明只是输入，不是命令：实际等待多久、接受哪些路径证据以及何时作出结论，仍由服务器负责。
互联网历史
网络明明有带宽，应用却仍在挨饿：RFC 1453
一条高速链路可以满载着光亮的数据抵达主机，屏幕上的人脸却依旧冻结。问题不一定出在“网速”上。1993 年的 RFC 1453 把视线移到机箱内部：从传输层到操作系统，再到应用的缓冲区，任何一道边界都可能让充足的网络容量变成用户拿不到的服务。
IETF
Dino Farinacci 与那份没有分配组播地址的需求文件
验收表上写着“应当具备”，并不表示网络里已经“正在具备”。RFC 10019 的价值，正是在这个常被跳过的差别上。它由 Dino Farinacci、Nate Karstens 和 Mike McBride 共同署名，给未来的零配置组播地址分配机制划出了一组应答的题目，而不是交付了一套正在运行的答案。
案例档案
VLAN 字段只有十二位，管理说明却给了十六位：RFC 9895
RFC 9895 把以太网标签接入 DLEP 信用窗口，却在管理段落中给 12 位 VID 写出一组 16 位边界。线格式能决定报文如何编码；它不能自动保证配置接口、控制器与厂商实现都拒绝多出来的四位。
报道
APNIC 提案测试面向纯 IPv6 网络的单个 /24 IPv4 过渡桥梁
APNIC prop-165 第 4 版拟允许有资格获得初始 IPv6 分配的组织，为纯 IPv6 部署中的过渡功能申请一个 IPv4 `/24`。该提案仍在讨论中；关键不只是区块大小，而是声明、注册表关联、归还义务和可衡量的日落机制能否使稀缺 IPv4 始终服务于过渡用途。