摘要

  • RFC 950 增加 ICMP Address Mask Request/Reply，让启动中的主机取得本地子网所用的 32 位掩码；若无人回答，只能退回到规范自己也承认可能错误的分类网络掩码。
  • RFC 1122 把回答权限定为经过显式配置的权威 agent：收到掩码并不会让接收者有资格回答别人，而主机用第一份被接受的答复设定掩码，之后的答复一律忽略。
  • DHCP 后来把掩码纳入更完整的配置事务，还能分别开关旧式的发现者与供应者角色；RFC 6918 最终以已有机制取代其用途为由废弃 ICMP 类型 17 与 18。

地址并没有告诉主机边界在哪里

早期 IPv4 地址本身不足以说明一个组织如何把获配网络切成内部子网。RFC 950 选择 32 位地址掩码，正是为了让每个组织决定本地地址中的哪些位属于子网、哪些位属于主机。

这枚掩码直接改变转发。主机分别用它遮住目的地址与自身地址；结果相同，就尝试在本地链路直接交付，结果不同，便把包交给网关。掩码错误不是显示出一个难看的前缀长度而已，它会改变主机认为谁是邻居、谁必须经过路由器。

有磁盘的主机可以从静态文件读取配置；但从局域网启动的无盘工作站未必有持久存储。RFC 950 注意到，新主机往往同时需要地址、网关、域名服务器和掩码，最好由启动服务器用一次请求给齐。尽管如此，规范仍为“只缺掩码”设计了单独后备机制。

Address Mask Request 与 Address Mask Reply 因而加入 ICMP。这个交换没有假装公网可以从地址推导组织内部拓扑，而是让本地配置在启动时回答一个本地问题。

问题先喊给整根线听

RFC 950 设想启动主机广播 Request。网关，或代替网关承担该职责的主机，返回收到请求的那个子网上所用的 32 位掩码。若请求者还不知道自己的地址而把源地址写成零，Reply 也会广播。

报文很短：Type 区分请求与回答，Code 为零，Checksum 覆盖 ICMP 消息，Identifier 与 Sequence Number 可帮助对应交换，最后一个字段携带 32 位 Address Mask。后来的注册表把二者列为 ICMP 类型 17 与 18。

但 RFC 950 又说，对应关系可以忽略。它并非说 Identifier 和 Sequence 不存在，而是作了一个架构假设：同一 LAN 只有一个可能的正确掩码。因此多个网关同时回答也不应冲突；即使 Reply 是广播，主机也无需证明它由哪一枚 Request 触发。

这个假设暴露了信任边界。掩码被当作连接介质的共享配置，不是某个客户的租约，也不是双方谈判出的偏好。Identifier 可以关联消息，却不能说明哪个回答者有权定义整个 LAN。

一种沉默同时对应三种现实

合理次数的重试之后，主机仍可能什么也没听见。RFC 950 列出三种解释：本地网络永久与外界隔离；没有使用子网，因而根本不存在供应者；或本地所有网关只是暂时离线。

三种现实产生同一个观测。没有 Reply 无法区分稳定拓扑与短暂故障。规范于是让主机采用 Internet network number 的掩码，也就是地址类别暗示的未划分子网解释。

这项“安全”结论有严格范围。RFC 950 认为它不会阻止原本能够成功的发送，却明确承认选择以后可能被证明是错的。沉默支持一个临时动作，却不证明管理员没有划分子网。

这是一种克制的负面证据。主机必须继续运行，所以选择保守默认值；它没有把一段时间内没收到消息升级为关于制度设计的事实。

回来的 agent 会主动修正旧猜测

后备值被设计成可逆。RFC 950 要求网关恢复时广播一枚未经请求的 Address Mask Reply。若主机此前的猜测与该值冲突，就应改用新值。

主动广播很重要，因为主机可能早已停止重发请求。修复不要求 agent 找回旧请求，也不要求主机一直停留在特殊发现窗口。配置权威重新出现，就发布一项所有本地节点都能看见的新事实。

但修复通道依赖一项关键禁令：任何主机或网关都不应根据“猜来的”掩码发 Reply。否则每个超时节点都能把临时推断包装成权威答案。一次短暂故障会制造许多自信却可能错误的发布者。

协议因此把使用与发布分开。主机可以用后备值维持运行，却不能把后备值输出为他人的配置。

RFC 1122 把权威变成显式管理动作

RFC 1122 收紧了这条边界。系统除非是 address mask 的权威 agent，否则不得发送 Reply；这个角色必须显式配置。承担者可以是主机，也可以是网关，机器类型本身不产生权威。

更重要的是，收到一份 Address Mask Reply 不会赋予权威。接收者不得把学到的掩码作为自己回答他人的依据。一个事实可以被消费，却不会因此自动附带以“官方答案”身份再发布的许可。

规范解释了原因：随意发出无效掩码的主机曾造成严重困扰。解决办法不只是检查语法是否合理，还要求由显式管理行动挑选回答者。

这仍不意味着报文本身能够认证。ICMP 格式没有密码学证据证明发送方确实被正确配置。RFC 1122 规定谁有资格说话；实际部署还需要受保护的局域网与实现控制，才能让资格可靠落地。

第一份答案会关闭发现窗口

RFC 1122 允许静态配置或动态发现，并要求使用哪种方法应可配置。若启用发现，主机会按需重发。针对某个本地地址收到的第一份 Reply——无论是应答还是主动广播——设定掩码；之后的 Reply 静默忽略。

这条规则限制了震荡。否则迟到或重复的消息可能不断改变主机视图。但“先到先得”不是认证。错误回答只要结构合理并抢在权威 agent 前面，仍可能被接受。

主机应对掩码做合理性检查。规范建议拒绝全为一的值，并要求掩码要么为零，要么最高八位全开。这能抓住某些不可能或明显可疑的值，却不能证明一个看似合理的掩码就是管理员真实意图。

若发现功能被关闭，主机不发请求，也静默忽略收到的 Reply。同一份报文只有在本地政策打开发现窗口时才产生作用。识别协议不等于授权配置改变。

“每根 LAN 一个掩码”既简化也放大风险

RFC 950 假设一条物理 LAN 只有一个正确掩码。这个前提让多个答案无害，也让请求对应关系显得不必要；同时它把掩码变成一种集体属性，错误会影响所有正在发现的主机。

可以把这套机制理解为本地配置公告栏。Identifier 与 Sequence 能标记问题，内容的正当性却来自获授权的公告源。多宿主主机可能要为每个 LAN 分别学习掩码，也说明该值属于接口环境，而不是整台主机的永久身份。

随着子网实践更灵活，一值广播模型也暴露年龄。它无法表达丰富的逐客户配置、租约状态或服务器选择，也不能让掩码与它所解释的地址分配形成一个事务。

弱点不只在于 ICMP 很旧。掩码问题从启动所需的其他事实中被单独拆出，因此顺序、来源和一致性只能依靠约定补足。

DHCP 把答案装进更大的配置行为

RFC 2131 回顾了早期启动工具：RARP 可帮助发现地址，ICMP 可供应掩码或路由器信息，BOOTP 可传输一组配置参数，其他系统再补充别的片段。DHCP 把地址分配与主机配置结合成有状态交换。

这不表示旧机制在 RFC 出版当天全部消失。DHCP 文档仍把 ICMP mask request 列为可用工具之一，也把 Subnet Mask 视作逐接口的主机配置参数。

RFC 2132 特别清楚地展示过渡。Option 1 直接携带四字节 Subnet Mask；若同时提供 Router option，掩码必须排在路由器之前，使客户端先获得解释地址所需的边界。

DHCP 还能治理旧机制。Option 29 Perform Mask Discovery 告诉客户是否执行 ICMP 发现；Option 30 Mask Supplier 告诉客户是否回答 ICMP 掩码请求。新配置通道既能交付数值，也能控制旧的提问者与发布者角色是否继续存在。

取代是一段过程，不是瞬间删除

这些开关让简单的替代叙事站不住脚。DHCP 到来后，类型 17 与 18 并未立刻变成不可能。它提供迁移界面：管理员可以直接给出掩码、关闭重复发现，也可以有意保留某个 ICMP 角色。

共存期里，旧协议的权威模型仍然重要。由 DHCP 下发“充当 mask supplier”的指令仍是一项显式配置决定；仅仅听到 ICMP Reply 仍不够。

随着时间推移，把信息打包减少了单独广播询问的价值。负责分配或确认地址的服务器可以在同一配置关系里提供掩码。一个辅助协议的沉默不再需要独自承担“是否存在子网”的判断。

制度上的改进并不是 DHCP 让答案绝不会错，而是它把掩码放进较完整、较可识别的配置关系，还给政策提供关闭遗留发现路径的直接控制。

废弃只是记录替代已经胜出

RFC 6918 正式废弃了若干 ICMPv4 消息。它对 Address Mask Request 与 Reply 的解释很简洁：二者原本用于取得子网掩码，但 DHCP 等机制已在主机配置中取代它们。

文档没有声称所有实现同一时刻停止，也没有说消息编号消失。废弃告诉新设计不要继续依赖，并让注册状态追上早已改变的配置实践。

RFC 7279 在制定新 ICMP 类型与 Code 的分配政策时，把 17 与 18 列为 Deprecated。数值仍是历史坐标；保留可见性可以避免重新分配后让旧流量含义混乱，却不再为新使用背书。

因此，从正式机制到废弃类型经历了渐变：单独广播发现、更严格的主机要求、由 DHCP 开关治理的共存，最后才是正式确认其用途已经被取代。

一枚抓到的 Reply 能证明什么

捕获到类型 18，可以证明观察点看见了结构正确、Checksum 可验证并声称某个 32 位掩码的 ICMP 消息。Identifier 与 Sequence 也许能把它与请求对应，即便早期操作并不要求这种对应。

它不能证明发送者经过显式配置、掩码符合管理意图、请求主机真的安装了它，或没有更早的 Reply 赢得第一答案竞争。语法合理不等于管理权威。

反过来，一枚无人回答的 Request 只证明某段时间、某个观察点没有看到 Reply。agent 可能不存在、可能宕机、可能被过滤，回答也可能丢失。主机据此采用分类掩码，只能证明其后备规则，不能证明 LAN 未被划分子网。

ICMP 掩码发现的历史因而是一部限定主张的历史。本地答案可以指导转发，沉默可以支持可逆猜测；两种观察都不能凭自身制造给所有人配置网络的权力。

来源与证据边界

封闭证据集包括 RFC 950、RFC 1122、RFC 2131、RFC 2132、RFC 6918 与 RFC 7279。它们能够证明设计、主机要求、DHCP 共存与废弃，却不测量历史或当前部署，不认定某个被捕获的发送者有权威，也不验证厂商遵从或某枚实际掩码正确。