主要领域
互联网基础设施
在 主要领域 分类下，互联网基础设施 按主要领域组织行业情报，帮助读者聚焦互联网基础设施、治理、连接市场或数字资本等方向。页面汇集了相关文章、公开证据、机构、公司、人物、区域关联、运营依赖和市场环境，这些内容可能分散在多个分类页面中。页面解释了该领域、可能的行为主体类型、市场或治理背景，以及读者比较信号时应使用的参考来源。运营商、分析师和治理领域的读者可以观察同一领域如何在事件、档案、市场变化、公开来源证据、区域依赖和更长周期的基础设施决策中随时间显现。
案例档案
一项完成的 SCIM 请求并未替跨域作出决定：RFC 9967
当异步 SCIM 请求收到 202，随后又出现带有同一事务值的 Security Event Token，人们很容易把这条轨迹读成一次完整的身份决定。RFC 9967 提供的是更清晰的关联，不是把远端目录的结论直接变成本地域的权限。它让接收方知道应当核对哪一项工作；接收方仍要决定该工作是否对应本地对象、是否符合本地规则、是否应当产生实际效果。
IETF
Tobias Fiebig 与 DNS 的四份可达性回执
一次权威 DNS 变更是否可以放行，常被压缩成“记录齐不齐”。RFC 10001 给出更严格也更实用的答案：先列出两份 IPv4 回执和两份 IPv6 回执，再逐项说明委派链、传输、数据与观测位置。四行都能复现，才有资格谈双栈连续性。
互联网历史
DHCP 之前，四个字节先选定语法：RFC 1048 与 BOOTP 的 64 字节边界
无盘工作站开机时，往往连自己的 IP 地址、启动服务器和文件名都不知道。它必须先从网络取得配置，才能真正使用网络。BOOTP 为这个最早的回答留出 64 个字节；RFC 1048 又用开头四个字节告诉机器后面应当怎样读。它解决了表示法，却从未声称能证明回答者可信。
互联网历史
名称就是地址，但它不是路由：RFC 1088 的 IP-over-NetBIOS 映射
1989 年的 RFC 1088 做了一件非常克制的事：把某台 IP-over-NetBIOS 主机的 IP 地址写成固定的 16 字节 NetBIOS 名称 `IP.XX.XX.XX.XX`。每个 `XX` 是地址中一个字节的 ASCII 十六进制表示。这样，发送 NetBIOS 数据报时不必为了得到该名称而查询物理地址。它节省的是一次特定的解析；它没有交付一条路由，没有认证主机，也没有证明任何应用已经收到或接受了数据。
互联网历史
四个字节让 TCP 有了报文边界，却没有重建 OSI 网络：RFC 1006 的 TPKT 边界
发送方可以一次写入一条完整指令，接收方却不应把一次 `read` 当成那条指令。TCP 保证的是连续有序的字节流。RFC 1006 面对 ISO 传输协议需要离散 TPDU 的问题，没有改写 TCP 的承诺，只在流上放置了一个可计数的边界。
案例档案
遗留代码点抵达了客户端，却没有重新授权服务器：RFC 9963
迁移评审中看到 IANA 新增一个代码点，很容易把它读成“旧算法又被允许了”。RFC 9963 的设计恰恰更窄。它为三种遗留 RSASSA-PKCS1-v1_5 签名分配 TLS 1.3 数值，但这些数值只能在服务器通过 `CertificateRequest` 明确提出后，由客户端用于自己的 `CertificateVerify`。它们不能用于服务器签名，默认应关闭，在注册表中也标为不推荐。这是一座只通向客户端的窄桥，不是对遗留 RSA 的全面放行。
案例档案
反向连接已抵达，设备身份仍待验证：RFC 10011
控制器等到了一个反向连接，往往会让人产生一种过早的确定感：设备应当回连，监听器也正为它打开，于是抵达者似乎自然就是那台设备。RFC 10011 和 RFC 8071 的组合恰好说明了为什么不能这样推论。前者让 RESTCONF 客户端、服务器和 Call Home 的配置关系可以用 YANG 表达；后者规定设备可以先发起 TCP。二者都没有说，一次成功抵达的套接字已经证明设备身份、RESTCONF 会话或变更权限。
互联网历史
令牌找到了连接，却没有准入子流：MPTCP 的 MP_JOIN 边界
一个新的 TCP SYN 可以携带一段更早建立的关系：它并非要新建应用会话，而是请求把自己的五元组并入已有的 MPTCP 连接。这个请求若被简化成“连接换了路径”，就会丢掉最要紧的几次判断：查找哪个状态、如何证明仍是原来的对端、谁有权接纳新子流，以及接纳后由什么字段处理数据包。
案例档案
抗量子密钥已经加入，传统收件人仍能打开邮件：RFC 9980
RFC 9980 为 OpenPGP 增加了后量子算法，并定义了把 ML-KEM 与 X25519 或 X448 组合在一起的复合加密密钥。这使迁移有了可互操作的技术基础，却不等于任何带有新密钥的邮件都自动具备抗量子保密性。为不中断通信，发送方可以同时为 PQ/T 密钥和传统密钥加密同一封邮件。RFC 9980 给出的边界非常明确：只有这封邮件所用的每一把收件人密钥都支持 PQ(/T) 加密，才可以说该邮件具有后量子保密性。
IETF
Weiqiang Cheng 与仍需一条路由的 SRv6 定位符租约
T1、T2、首选有效期和有效有效期可以把一份 DHCPv6 租约描述得非常准确，却不能回答路由表里有没有下一跳。RFC 10038 的价值，正是让这两个事实可以连接核验，又不被误写成同一个事实。
欧洲与中东国家电信趋势
数字固话的最终通知，只有确认关键呼叫路径后才可能构成安全停服
一份写明日期的通知，能够证明服务商启动了最终流程；它本身不能证明住户、远程照护服务或关键呼叫路径已经被安全地带过该流程。
互联网历史
横幅圈出了屏幕，却没有制定政策：RFC 933 与 Telnet 输出标记的边界
把安全标记重复塞进每一屏应用输出，既浪费带宽，也迫使服务器猜测远端终端有多大。RFC 933 的选择是让服务器只送一次横幅，由用户端 Telnet 维护版面；这项分工解决了显示问题，却没有把分类、授权和访问控制写进那串 ASCII 字符。
案例档案
快速报文维持了会话 Up，却没有授权变更：RFC 9985
RFC 9985 面对的是一个很实际的取舍：BFD 要靠高频控制报文及时发现受监测路径的问题，而每个报文采用同一种高成本认证，可能反过来压缩可承载的会话规模。它把会改变状态的报文与保持既有 `Up` 状态的报文分开处理。前者使用对实现成本更高的 MCI，后者可以使用成本较低的 LCI。这是一套会话保护安排，不是一张允许改路、切流或宣布服务正常的授权书。
互联网历史
NAK 拒绝的是端口，不是数据包：RFC 938 如何划清接收与分派的边界
1985 年的一项实验性协议曾允许接收方同时作出两种并不相同的陈述：它已把一个数据包计入连续接收状态，但该包所指向的本地端口无人认领。RFC 938 将这一响应命名为 `PORT NAK`。它的价值不在于替任何应用宣布失败，而在于拒绝让传输层的收据冒充本地分派决定。
互联网历史
UUID 跨过连接，决定权留在原处：RFC 927 的免重复登录交易
用户少输一次密码，不等于目标主机少做一次判断。1984 年的 RFC 927 允许已完成认证的一端送出四个八位组的用户编号，却把是否相信这次认证的权力明确留给接收服务的那一端。
互联网历史
这条分支说“下方无人”：RFC 1075 与 DVMRP 会过期的无成员报告
1988 年的实验性组播路由必须回答一个朴素而危险的问题：什么时候可以不再把一个组的数据送往某条分支？RFC 1075 给出的回答很窄。下游路由器可以说，某个组在自己的后代方向没有成员；上游邻居于是可以在指定时限内停止向这条分支转发该组。它不是互联网的成员普查，而是一项只作用于一棵转发表局部的临时指令。
互联网历史
一次按键只需四个八位组：RFC 916 如何让状态代替重复信息
“省掉三个八位组”并不是神奇压缩。接收方之所以还能正确读取，是因为连接状态已经回答了长度、待确认分组和接收上限等问题。RFC 916 把已知事实从线路上删掉，同时把这些事实写进更严格的状态约束。
互联网历史
不会报出读数的名字：RFC 1065 与可管理事物的形状
1988 年的互联网管理需要一种克制：它必须能够描述“可以观测什么”，却不能把描述伪装成已经取得的观测。RFC 1065 因而把受管对象类型的稳定名称、语法、编码与访问类别同某个具体实例在某一时刻的活值分开。
互联网历史
那个意为“重新开始”的字节：SLIP、RFC 1055 与串行帧恢复的代价
串行线路并不把一个个完整数据包交到接收端手中；它只不断交付字节。在线路噪声之后，缓冲区中可能留着一段没有明确归属的残片。RFC 1055 为 SLIP 提出过一个极小的动作：在下一个数据报之前也发送 `END`。这个字节不修复噪声，也不为随后的内容背书；它只让接收端放弃旧残片，并从可辨认的帧边界重新开始读取。
IETF
Mike McBride 与只消除一种碰撞的组播注册表
如果两个分配器都被允许从同一只箱子里取号，那么“各自随机”不是隔离机制，只是把冲突推迟到运气用尽。RFC 10028 所做的事情很克制：先把箱子分格，再要求运行中的实现证明自己真的换了格子。