主要领域
基础设施
在 主要领域 分类下，基础设施 按主要领域组织行业情报，帮助读者聚焦互联网基础设施、治理、连接市场或数字资本等方向。页面汇集了相关文章、公开证据、机构、公司、人物、区域关联、运营依赖和市场环境，这些内容可能分散在多个分类页面中。页面解释了该领域、可能的行为主体类型、市场或治理背景，以及读者比较信号时应使用的参考来源。运营商、分析师和治理领域的读者可以观察同一领域如何在事件、档案、市场变化、公开来源证据、区域依赖和更长周期的基础设施决策中随时间显现。
互联网历史
主密钥从未加密过一个数据包：RFC 3079
RFC 3079 把一个值称为“主密钥”，同时明确禁止它直接处理流量。它先被拆成带角色和方向含义的两条支路，再生成瞬态发送密钥与接收密钥，最后才初始化两个独立的 RC4 状态。这套层级说明：算出一串长度正确的字节，只证明计算完成；只有认证事件、端点角色、方向和协商强度都一致，那串字节才属于同一次通信。
互联网历史
计数器发现了丢包，却无法解密下一包：RFC 3078
MPPE 的 12 位一致性计数器能让接收端看见序列已经跳变。但在有状态模式中，暴露缺口的那个包仍然必须被丢弃：接收端要沿反向路径发出 CCP Reset-Request，再等待发送端用 FLUSHED 标出新的同步边界。发现故障是一份证据，不等于恢复了服务。
互联网历史
卫星链路只能单向传输，链路层却要表现为双向：RFC 3077
卫星馈送可以把数据送到接收端，却不能沿同一介质听见接收端的回答。RFC 3077 没有把这种不对称变没，而是把广播链路与另一条经由 IP 的双向回传路径组合起来，让上层网络继续把它当作一段熟悉的链路。
互联网历史
解析器早已改变文档，字节随后才被规范化：RFC 3076
Canonical XML 给出的是稳定输出，不是原始文件的取证副本。RFC 3076 开始排列命名空间和属性以前，XML 处理器已经统一换行与属性值、展开实体、替换 CDATA，并把输入建成 XPath 节点集。可重复性从这里开始，也止于这里的边界。
互联网历史
签名验证了变换结果，却没有验证你看到的整份文档：RFC 3075
屏幕上是一份文档，签名引擎面对的却是一条加工链：先选资源，再依次变换，把结果摘要写入 `SignedInfo`，最后才验证签名值。RFC 3075 的贡献不是给 XML 盖上无边界的可信印章，而是精确规定那枚印章究竟覆盖了什么。
互联网历史
哈希决定哪台 DHCP 服务器可以应答，却不能保证服务送达
RFC 3074 把预设的负载比例拆成 256 个哈希桶，只回答一个有限问题：哪台服务器有资格回应？它既不测量实际工作量，也不能证明客户端拿到了租约。
互联网历史
哈希指定了服务器，却没有证明它能提供服务：RFC 3074
RFC 3074 让协作的 DHCP 服务器无需逐次协商，就能算出谁该响应。相同计算却无法说明被选中的服务器是否在线、是否还有合适地址，或客户端最终能否完成配置。
案例档案
只验证送达、从不证明处理：Svea 旧网络块滥用联络渠道的问责断点
当一个注册数据库中的滥用联络地址每年都通过技术验证，却没有任何公开记录显示它处理过一份报告时，问责实际发生在哪里？对瑞典 Svea 银行集团遗留网络块 193.105.138.0/24 的这桩案例，答案不在注册库，而在瑞典金融监管局的一份处罚决定里。
互联网历史
MIME 名称是公开的，完整字体规范仍留在厂商手中：RFC 3073
RFC 3073 把 Portable Font Resource 纳入公开的 MIME 名称体系，却没有让这个名称替代完整规范、兼容解码器或实际呈现结果。
互联网历史
解析器可以跳过数据块，却未必知道它是什么意思：RFC 3072
RFC 3072 为未知 SDXF 数据块提供了可定位的边界，让读取器能继续向后解析。但抵达下一个数据块，不等于理解刚才跳过的内容，更不能据此认定应用可以安全忽略它。
互联网历史
两位字符标出国家代码，却说不清注册局服务谁：RFC 3071
2001 年，John Klensin 指出，顶级域名的外形未必能说明注册局实际服务的对象。RFC 3071 把两位字母、商业做法与政治代表权分开，也提醒 DNS 管理者不要把技术管理变成“谁是国家”的裁判。
互联网历史
掩码说它是邻居，VLAN 却要求路由器介入：RFC 3069
RFC 3069 让彼此隔离的客户 VLAN 共用一个 IPv4 子网，以省下为每个客户切割前缀所浪费的地址。这个方案的关键不只是地址池变大，而是打破了一个熟悉的等式：掩码判断为“本地”的两台主机，未必共享二层广播域。缺失的邻接关系必须由路由器制造，地址归属、隔离与可达性的事实也随之迁入设备状态。
互联网历史
隧道与介质无关，承载电路却不是：RFC 3070
RFC 3070 让 L2TP 可以穿越帧中继网络，但“可移植”不等于承载层已经消失。隧道下方仍是一条有端点、有封装标识、有建立方式、有报文尺寸上限的虚电路，服务质量和安全责任也没有被抽象层一并解决。它留下的历史启示是：抽象能够重新安排依赖，却不能凭命名取消依赖。
互联网历史
共同事故对象，不等于共同裁决：RFC 3067
RFC 3067 设想了一份能够跨越组织和国界、又不丢失行动所需差别的安全事故记录。它最重要的见解并不是要求所有响应团队得出相同结论，而是让一个共同对象能够携带不同类型的事实、不同访问权和持续变化的判断历史。
互联网历史
标签标明内容，却不能证明理解：RFC 3066
2001 年 1 月，RFC 3066 为互联网协议提供了一种紧凑方法，用来说明信息对象使用哪种人类语言。它同时划出了一条至今仍常被越过的边界：合法标签可以引导选择，却不能替人证明读者会理解结果。
互联网历史
网关掌管毫秒，Call Agent 仍掌管通话：RFC 3064
老式电话中继的动作快到不能逐项越网请示。RFC 3064 把 CAS 的计时与低层状态机留在媒体网关，却没有把整场通话的决策一并下放。它尤其提醒运营者：中继已经空闲，不等于分组网络连接也已经删除。
互联网历史
标签等到线程回卷后才放行：RFC 3063
MPLS 网络的下一跳发生变化时，三层路由可能已经绕成一个环，而新的标签交换路径还没有建立。RFC 3063 提出先让一条带颜色的控制线程沿候选路径往下走；只有线程按无环条件回卷，标签映射才可以发布。
北美区域 ISP
加夫奇公司：一个在互联网路由登记系统中逐渐碎裂的身份
当一家运营了二十多年的美国电信运营商的名字同时出现在一个早已废弃的路由注册对象和一份刚刚生效的新自治系统登记里，而在两者之间却找不到任何公开的路由安全控制证据时，值得追问的就不再是"这家公司出了什么事故"，而是"谁在验证这家公司的控制面"。本文基于登记册与第三方监测数据，逐项核查加夫奇公司（GAFACHI INC）当前可验证的路由身份。
互联网历史
缺失的扩展不是“空答案”：RFC 3059
RFC 3059 想在服务发现中省掉一次往返：让每个服务 URL 连同属性一起回到客户端。真正值得保留的历史教训，却藏在这条捷径没有出现的时候。回复里没有扩展，不等于服务没有属性；它只说明客户端还欠网络一次追问。
互联网历史
OID 让 IDEA 可以被编码，却没有让密码算法自动可用：RFC 3058
RFC 3058 为 IDEA 在 CMS 中的两种用途给出了精确名称，也规定了可复现的内容密钥封装方法。它解决的是合规软件应如何表示这种密码算法，并没有替任一端安装 IDEA、授予使用许可、为某封邮件作出选择，或证明收件人能够解密收到的内容。