Summary
- RFC 6164 did not say RFC 3627 had imagined the Subnet-Router-anycast collision. It said the earlier analysis was correct, then changed the operative guidance for links with exactly two routers, no hosts and explicit point-to-point behavior.
- A standards status routes present authority; it does not erase observations. Operators still have to prove that a real link satisfies the later document's scope before
/127becomes the right rule.
A correct warning can lose authority
RFC 3627 entered the archive in 2003 with a title designed to stop a habit: using /127 between routers was “considered harmful.” Its example was concrete. Give Router A the odd address in a two-address prefix and the IPv6 architecture could also make it claim the even address as Subnet-Router anycast. Configure Router B with that even address as unicast and Duplicate Address Detection could reject it. One router had consumed both names before the second router could join.
The memo also admitted the awkward part. Subnet-Router anycast had little obvious utility on a link containing only two routers. The failure might not have appeared widely because implementations did not all claim the address. Yet the architecture required support, and an operator could not safely assume that every implementation had chosen the same exception. RFC 3627 therefore preferred /64, or in constrained designs /126, two /128s, /112 or /120.
That was evidence about a real specification collision. RFC 6164 said so explicitly in 2011: the earlier analyses were correct. Its disagreement was not with the existence of the collision. It was with which risk should govern, and under what operating contract.
This distinction matters. A standards process becomes brittle if revision requires declaring yesterday's observation fraudulent. It becomes more useful when it can preserve the observation, narrow its domain and move the decision edge.
The later rule came with a boundary
RFC 6164 does not recommend /127 for “IPv6 links” in general. Its scope is an inter-router point-to-point link with exactly two routers and no hosts. Ethernet qualifies only when it is configured to behave as point-to-point. Router-to-host and mixed links are excluded. Link-local addressing is outside the recommendation. The use case is a numbered infrastructure link whose addresses support monitoring, reverse DNS, traceroute interpretation, management and EBGP.
Within that boundary, the document changes two things together. Routers must support assigning /127, and they must disable Subnet-Router anycast for that prefix. The second requirement is not an incidental footnote. It removes the mechanism that made the all-zero endpoint ambiguous in RFC 3627.
The compatibility set is therefore not “anything configured with a 127-bit mask.” It is a pair of router implementations, a two-party topology, a point-to-point operating mode and a special anycast rule. Remove any one of those conditions and the citation no longer proves the design fits.
RFC 6164 keeps additional exclusions. When operators carve many /127s from a /64, they should not use an address whose low 64 bits are all zero as unicast. Nor should they use the highest 128 interface-identifier values reserved for other subnet anycast purposes. The later rule did not abolish address semantics. It made one narrowly defined exception safe while protecting adjacent reservations.
Empty space had become an attack surface
Why take the trouble? Address conservation was not the decisive argument. A /64 is cheap in IPv6. But the unused values on an infrastructure link can be expensive to defend.
On an Ethernet link using Neighbor Discovery, a packet aimed at an unassigned on-link address can make a router create an INCOMPLETE cache entry, send Neighbor Solicitations and start timers. Repeat that process across a vast /64 and the empty address field becomes a memory and CPU workload. RFC 6164 notes that rate limiting and garbage collection can reduce the damage without necessarily restoring a legitimate BGP session while the pressure continues. A /127 leaves no unused address inside the link prefix once the two endpoints are assigned.
Another risk exists on some point-to-point media that do not use Neighbor Discovery. If a packet targets an unused address covered by a shorter on-link prefix, defective forwarding can send it back and forth between the endpoints. RFC 4443 requires a router not to return such a packet to the same point-to-point link and recommends an ICMPv6 unreachable response. RFC 6164 nevertheless treats /127 as a structural way to remove the unused destination, including protection where older behavior survives.
The risk order had changed. The earlier document guarded against a collision created by mandatory anycast semantics. The later one disabled that semantic in a precise context and ranked neighbor-cache exhaustion and ping-pong exposure above the lost anycast function. Running code did not overrule analysis by charisma. It supplied a different failure distribution and a practicable implementation contract.
Historic is a routing instruction
RFC 6547 completed the authority change in 2012. It moved RFC 3627 to Historic status and explained that Standards Track RFC 6164 superseded the Informational document where they conflict. The status change helps a reader decide which instruction to follow now.
It does not travel backward through time. RFC 3627 still records the architecture it examined, the collision it derived, the deployment uncertainty it saw and the workarounds it considered. Its verified erratum even remains relevant: a reference label should have said ICMPv6 rather than ICMPv3. Archival repair and operative authority are separate jobs.
This is the cleaner model for technical institutions. A record may describe what was believed, observed or required in one compatibility set. A later record may gain authority because implementations, scope and risk have changed. Neither record can, by status alone, author the state of a live link.
A mask is not proof of a medium
An inventory can show /127. A configuration can call an interface point-to-point. A vendor manual can claim RFC 6164 support. None of those records proves there are exactly two active routers and no host on the actual segment. They do not prove that a tunnel, exchange fabric or Ethernet service cannot admit a third participant. They do not prove that both endpoints disabled Subnet-Router anycast or avoided reserved values in the parent allocation.
Nor does a successful BGP session close the chain. It proves a session existed under observed conditions. It does not permanently certify Neighbor Discovery, ICMPv6 forwarding, physical isolation, failover behavior or packet delivery after the next software change.
The useful evidence chain is layered: intended topology, observed attachment, endpoint capabilities, active anycast behavior, address-plan validation, neighbor-cache behavior, control adjacency, route installation and traffic result. RFC 6164 supplies the rule for one layer. Operators still have to produce the receipts for the rest.
The durable lesson
RFC 3627 became Historic because a narrower, tested rule took its place. That is not institutional embarrassment. It is what a technical record should allow: preservation without worship, revision without amnesia and authority without pretending that a document generated the network it describes.
The dangerous shortcut is to replace one slogan with another. “Never use /127” was too broad. “Always use /127” is equally broad. The current rule is conditional, and its conditions are operational facts.
The standard can define the compatibility set. Only running systems can show that a link belongs to it.
Sources
- RFC 3627 — canonical text
- RFC 3627 — plain text
- RFC 3627 — status
- RFC 3627 — Datatracker
- RFC 3627 — errata
- RFC 6164 — canonical text
- RFC 6164 — status
- RFC 6164 — Datatracker
- RFC 6164 — errata
- RFC 6547
- RFC 6547 — status
- RFC 2526
- RFC 4291
- RFC 4443
- RFC 4861
- RFC 5375
- RFC 7404
- RFC 7421
- RFC 9099
- Running-Code Primacy
- Minimum Initial Specification
- Reality layers
- Authority belief
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
