Summary

  • RFC 950 added ICMP Address Mask Request and Reply so a booting host could learn the 32-bit mask governing its local subnet; a missing reply led only to a classful fallback that the RFC admitted might be wrong.
  • RFC 1122 confined reply authority to explicitly configured agents: receiving a mask never made a host entitled to answer others, and the first accepted reply fixed the local mask while later replies were ignored.
  • DHCP later carried the mask together with broader configuration and could explicitly enable or disable the old discovery and supplier roles; RFC 6918 eventually deprecated ICMP types 17 and 18 as superseded.

A host knew its address but not its neighborhood

An IPv4 address does not by itself tell an early host how a particular organization divided its assigned network into subnets. RFC 950 chose a 32-bit address mask precisely because the organization needed flexibility over which local-address bits represented a subnet.

The mask affected an immediate forwarding decision. The host compared a destination, under the mask, with its own address under the same mask. Equality meant the destination was local and could be reached directly; inequality meant a gateway was needed. A wrong mask therefore did not merely display the wrong prefix length. It changed which packets the host tried to deliver on the attached LAN and which it sent toward a router.

Static files could provide the value, but a diskless workstation booting from the LAN might have no durable local configuration. RFC 950 observed that a new host often needed several facts—its address, a gateway, a name server and a mask—and preferred obtaining them together from a boot server. It nevertheless standardized a separate fallback for the mask.

That fallback extended ICMP with Address Mask Request and Address Mask Reply. The exchange turned one piece of local topology into boot-time configuration without pretending the public Internet could infer it from the address.

The question went to everyone on the wire

RFC 950's intended sequence began with a broadcast request. A gateway, or a host acting in place of one, answered with the 32-bit mask for the subnet on which it received the request. If the requester did not yet know its own IP address and used zero as the source, the reply was broadcast too.

The message format was compact. Type distinguished request from reply; Code was zero; checksum protected the ICMP message; Identifier and Sequence Number could help match an exchange; the final field carried the 32-bit mask. Later registry terminology identifies these as ICMP types 17 and 18.

Yet RFC 950 said matching could be ignored. Its reasoning was architectural, not a claim that identifiers were absent: on a given LAN there was assumed to be only one correct mask. More than one gateway could answer without creating a conflict, and even broadcast replies did not need to be associated with the particular request that caused them.

That assumption reveals the protocol's trust boundary. A mask was treated as shared configuration of the attached medium, not as a per-client lease or negotiated preference. The Identifier and Sequence fields correlated messages, but did not establish which answer was entitled to govern the LAN.

Silence collapsed three states into one observation

After a reasonable number of requests, the host might still hear nothing. RFC 950 listed three possible realities: the local network was permanently isolated; subnets were not in use and no agent existed; or all gateways on the LAN were temporarily down.

The observation was identical in every case. No reply could not distinguish stable topology from temporary unavailability. The standard therefore chose the Internet network-number mask—the old unsubnetted, classful interpretation—as the safest operational fallback.

The safety claim was bounded. RFC 950 reasoned that this choice would not prevent transmissions that would otherwise succeed, but explicitly admitted that the mask could later prove wrong. Silence supported a provisional action, not a factual conclusion that no subnetting existed.

This is a disciplined use of negative evidence. The host had to run, so it selected a conservative default. It did not elevate the absence of a message into proof about the administrator's design.

The returning agent could repair the guess

The fallback was made reversible. When a gateway came up, RFC 950 said it should broadcast an unsolicited Address Mask Reply. A host that received a value disagreeing with its guess should change its mask to conform.

The unsolicited message mattered because a host might already have stopped retransmitting. Repair did not require the agent to reconstruct an old request or the host to remain in a special discovery window. Reappearance of the configuration authority produced a new local fact visible to everyone on the medium.

But the repair channel depended on an important prohibition: no host or gateway should send a reply based on a guessed mask. Otherwise, every node that timed out could repeat its provisional inference as though it were authoritative. A temporary outage would manufacture many confident but possibly wrong publishers.

The protocol therefore separated use from publication. A host could use a fallback to keep operating. It could not export that fallback as configuration for others.

RFC 1122 made authority an explicit administrative act

RFC 1122 tightened the boundary. A system must not send an Address Mask Reply unless it is an authoritative agent, and that role must be explicitly configured. The agent could be a host or a gateway; its machine type did not create the authority.

Most importantly, receiving a valid Address Mask Reply did not confer authority. The receiver was forbidden to use the received mask as the basis for issuing replies. Truth could be consumed without granting a licence to republish it as an official answer.

The discussion explained why. Hosts that casually answered with invalid masks had been a serious nuisance. The remedy was not only a syntactic reasonableness test. It was selection by explicit administrative action.

That distinction cannot authenticate a packet on its own. The ICMP format contains no cryptographic proof that the sender was configured correctly. RFC 1122 specifies which systems are entitled to speak; a deployment still needs a protected LAN and implementation controls to make the entitlement reliable.

The first answer closed the discovery window

RFC 1122 allowed static configuration or dynamic discovery and required the choice to be configurable. If discovery was enabled, the host retransmitted as needed. The first Address Mask Reply for the local address—solicited or unsolicited—set the mask. Later replies were silently ignored.

That rule limited instability. Without it, a late or duplicated reply could repeatedly alter the host's view. But first-wins was not authentication. A false first reply could still be structurally valid and arrive before the configured agent.

The host was advised to perform a reasonableness check. Suggested bounds rejected an all-ones mask and required either zero or the eight highest-order bits to be set. This caught some impossible or implausible values; it could not prove that a plausible mask represented the administrator's actual subnet.

If discovery was disabled, the host sent no requests and silently ignored replies. The same packet therefore had effect only when local policy had opened a discovery window. Protocol recognition alone did not authorize a configuration change.

One mask per LAN was both simplification and liability

RFC 950 assumed that a physical LAN had one possible mask. The assumption made multiple replies harmless and request correlation unnecessary. It also made the mask a collective property whose corruption affected every discovering host.

The system is easiest to understand as a local configuration bulletin. Identifier and Sequence can label a request, but the content's legitimacy comes from the authorized bulletin source. A host with several LAN attachments might need a separate mask for each, reinforcing that the value belonged to an interface context rather than the host as a whole.

As subnet practice became more flexible, the one-value broadcast model also showed its age. It could not express a rich bundle of client-specific settings, lease state or server selection. Nor could it make the answer transactional with the assignment of the address to which the mask applied.

The weakness was not merely that ICMP was old. The mask question was isolated from the other facts needed to start a host, so ordering, provenance and consistency had to be supplied by convention.

DHCP bundled the answer with a broader configuration act

RFC 2131 surveyed the earlier bootstrapping landscape. RARP could help discover an address, ICMP could supply mask or router information, BOOTP could transport a collection of parameters, and other systems served other fragments. DHCP brought address allocation and configuration into one stateful exchange.

This did not mean every old mechanism vanished on the publication date. The DHCP specification still listed ICMP mask request among the available tools. It also treated the subnet mask as a per-interface host configuration parameter.

RFC 2132 shows the transition in unusually explicit form. Option 1 carries a four-octet Subnet Mask. If supplied with a Router option, the mask must precede the routers so the client can interpret addresses consistently.

DHCP could also govern the old mechanism. Option 29, Perform Mask Discovery, tells the client whether to use ICMP discovery. Option 30, Mask Supplier, tells it whether to answer ICMP mask requests. A newer configuration channel could thus distribute the value and control whether the older questioner and publisher roles remained active.

Supersession was a process, not an instant deletion

Those control options complicate a simple replacement story. DHCP did not merely arrive and make types 17 and 18 impossible. It provided a migration surface: an administrator could give the mask directly, disable redundant discovery, or deliberately retain an ICMP role for a client.

The older protocol's authority model remained relevant during that coexistence. A DHCP-delivered instruction to act as a mask supplier was still an explicit configuration decision. Merely hearing an ICMP reply remained insufficient.

Over time, bundling reduced the value of a separate broadcast exchange. A server that assigned or confirmed an address could supply the mask within the same configuration context. Silence in one auxiliary protocol no longer needed to carry the burden of deciding whether subnetting existed.

The institutional improvement was not that DHCP made answers infallible. It made the mask part of a wider, identifiable configuration relationship and gave policy a direct way to disable the legacy discovery path.

Deprecation recorded that the replacement had won

RFC 6918 formally deprecated several ICMPv4 message types. Its explanation for Address Mask Request and Reply is concise: they were meant to obtain the subnet mask, but mechanisms such as DHCP had superseded them for host configuration.

The document did not claim that every implementation stopped in one moment or that the message numbers ceased to exist. Deprecation told designers not to build new dependence on them and aligned the registry with an already changed configuration practice.

RFC 7279, which defines policy for new ICMP allocations, lists types 17 and 18 as deprecated. The values remain historical coordinates. Keeping the numbers visible prevents reassignment from making old traffic ambiguous while withholding endorsement for new use.

The path from Standard-era mechanism to deprecated type was therefore gradual: separate broadcast discovery, stronger host requirements, coexistence governed by DHCP switches, then formal recognition that DHCP had superseded the purpose.

What an observed reply can prove

A captured type-18 message can establish a checksum-valid ICMP structure, a stated 32-bit mask and the addresses and timing visible at the capture point. Identifier and Sequence may relate it to a request even though early operation did not require that match.

It cannot prove the sender was an explicitly configured agent, the mask matched administrative intent, the requester installed it, or no earlier reply won the first-answer race. A syntactically reasonable value is not administrative authority.

Conversely, an unanswered request proves only that no reply was observed at that point during that interval. The agent might not exist, might be down, might be filtered, or the reply might be lost. Treating silence as a classful mask is evidence of the host's fallback rule, not evidence that the LAN was un-subnetted.

The history of ICMP mask discovery is thus a history of bounded claims. A local answer could guide forwarding; a missing answer could justify a reversible guess; neither observation alone could create the authority to configure everyone else.

Sources and evidence limits

The closed evidence set is RFC 950, RFC 1122, RFC 2131, RFC 2132, RFC 6918 and RFC 7279. It establishes design, host requirements, DHCP coexistence and deprecation. It does not measure historical or current deployment, identify one captured sender as authoritative, verify vendor conformance or show that a particular accepted mask was correct.