Summary
- RFC 3021 cut a numbered IPv4 point-to-point link from four addresses to two by requiring both values in a
/31to be interpreted as host addresses. - The saving depended on a real two-endpoint link and bilateral implementation support; the prefix itself did not prove topology, compatibility, reachability or delivery.
In December 2000, address conservation was usually discussed at Internet scale: allocation policy, private address space, NAT and the still-long transition to IPv6. RFC 3021 found a smaller lever inside the infrastructure. A conventional /30 consumed four addresses to number two router interfaces. Two identified the routers. The all-zero host value named the subnet, and the all-one value served as its directed broadcast. A point-to-point link, however, could have only two endpoints. Every packet sent by one end reached the other; there was no population of hosts for a directed broadcast to select.
The RFC proposed a narrow reinterpretation. A 31-bit mask leaves one host bit and therefore two possible values. On this particular kind of link, both MUST be host addresses. The old subnet-shaped value became one endpoint. The old broadcast-shaped value became the other. The bit patterns did not change. The link property changed the rule applied to them.
That distinction is the history. RFC 3021 was not simply an arithmetic optimization. It made address semantics conditional on evidence about the interface.
Two addresses saved, not two questions answered
The accounting was attractive. A network with 500 point-to-point links would use 1,000 addresses under /31 rather than 2,000 under /30, recovering the equivalent of four class-C-sized blocks in the terminology of the period. Unlike an unnumbered link, each interface retained an address for management and debugging. Unlike assigning unrelated host routes to PPP endpoints, both addresses remained inside one ordinary prefix.
But the mask did not manufacture the conditions that justified it. An operator still had to know that the interface was point-to-point. Both devices had to support the special treatment. RFC 3021 warned directly that a link might not operate correctly when only one end implemented 31-bit prefixes.
Consider the upper address in a pair. A compatible router attached to a /31 must deliver a packet for that value to its local interface. An older or incompatible peer might still classify the same value through the general broadcast rule. The configuration text could match while the running interpretations diverged.
Directed broadcast disappeared because there was no spare value
A /31 has no third symbol to reserve for a directed broadcast. RFC 3021 therefore eliminated directed broadcast to that link. Limited broadcast remained available where broadcast traffic was required. Remote routing did not need a new global convention: the router directly attached to the destination segment decided whether the address was a broadcast or an endpoint.
The removal had a security side effect. A link without a directed-broadcast address offered no such target for packet-replication attacks of the smurf era. RFC 2644 had already changed router defaults around directed broadcasts. RFC 3021 reduced the number of physical links on which that specific mechanism could exist. It did not authenticate peers, protect routing exchanges or eliminate denial-of-service risk.
The exception amended older rules without erasing them
Earlier host and router requirements treated all-zero and all-one host fields as special. RFC 950 had noted the possibility of a one-bit host field while explaining why the two available values were normally unusable as hosts. RFC 3021 did not declare those older meanings wrong. It added a scoped exception to RFC 1122 and RFC 1812: the values could be sourced, received and delivered as endpoints when the originator or destination was on a point-to-point link carrying a 31-bit mask. On other link types, the established discard or broadcast rules remained.
This is why /31 should not be described as “using the network and broadcast addresses” without the qualifier. It was not an operator ignoring reserved meanings. It was a standards-track change to the meanings under a defined interface condition.
Routing adjacency was necessary evidence, not final proof
RFC 3021 said classless routing protocols were not disrupted and reported positive beta experience involving OSPF, IS-IS, BGP and EIGRP at at least three ISPs. That is useful contemporaneous evidence, but bounded evidence. It does not establish universal vendor support then, current deployment now or successful traffic on any named link.
A routing adjacency can show that two control planes exchanged messages. It does not by itself prove that each endpoint handles both /31 values correctly in every local path, that management tools accept the notation, that filters preserve the addresses, or that an application received useful data. Those claims require their own receipts.
Sources
- RFC Editor record for RFC 3021
- RFC 3021 in HTML
- RFC 3021 in text
- RFC Editor record for RFC 950
- RFC 950 in HTML
- RFC Editor record for RFC 1122
- RFC 1122 in HTML
- RFC Editor record for RFC 1812
- RFC 1812 in HTML
- RFC Editor record for RFC 2644
- RFC 2644 in HTML
- RFC Editor record for RFC 6164
- RFC 6164 in HTML
- Lu Heng on Running-Code Primacy
- Lu Heng on Minimum Initial Specification
- Lu Heng on Reality Layers
Lu Heng did not author or endorse RFC 3021. His essays are used here as disclosed analytical lenses.
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
