Introduction: two-IPv4s framing, dependency stack, segment tiering

[remcovanmook]

The Introduction rework, built from the worked prose in A Farewell to ARPs and What's ARP Got To Do With It. Last of the wg-00 document issues.

The Introduction used to open with the mechanism, leaving the argument for it implicit. It now makes the architectural case first and arrives at the mechanism as a consequence.

1.1 Two Kinds of IPv4

The central separation: the IPv4 applications require is reachability past the first hop, where demand is real and durable; the IPv4 networks deploy to satisfy it is subnet, broadcast domain, ARP and an on-link gateway, which no application asks for. Needing to reach IPv4 has been taken to entail being attached to an IPv4 network, and that conflation is the document's actual subject.

Then the observation that on access and hosting segments the local part was never used - lateral traffic is suppressed by design, so the only on-link destination ever resolved is the gateway - and RFC 3021 as the standing precedent that a subnet may contain nothing but the ends of a link. The netmask as compression scheme, ARP as decompressor.

1.2 The Local IPv4 Dependency Stack

subnet → ARP → FHRP → carved pools → IPv4 host, with the policing apparatus (snooping, DAI, binding tables) as a side stratum rather than a layer, since it exists only because the base is an unauthenticated broadcast feeding a single-answer table. Includes the before/after layer cake figure.

Closes on the history: ARP was specified in 1982 on the assumption it was alone on the wire, which was true at the time. What did not follow was revision - IPv6 arrived on the same links with a complete resolution service and IPv4 resolution was never reconsidered, the dual-stack model holding the two deliberately independent.

1.3 Removing the Base Layer

The demolition in order: /32 is subnet deletion and Hetzner/OVH/Scaleway have shipped it for years (each with a different address and per-OS recipe, in no RFC); the sentinel deletes ARP's last remaining job; FHRP loses its object, since there is no longer an address to elect an owner for; pools go flat; policing collapses to one rule.

Ends on the precedent that lands best with sceptics: every mainstream OS already runs subnet-less IPv4 on tunnel interfaces daily, closed platforms included. What changes is not whether a host can work this way, but how it is told to.

1.4 The Mechanism

The former opening material, now arriving after the case for it. Content from #8, #10 and #11 is preserved intact.

6.1 Applicability - segment tiering

The tiering the issue lists went here rather than into the Introduction, since 6.1 previously said only that hosts without IPv6 are out of scope, and this is applicability. The test is the one 1.1 sets up - does lateral IPv4 exist, and can it be enumerated:

• Access and hosting - clearest case, removing the subnet costs nothing that was in use.
• Enterprise and campus - managed estate, on-link IPv4 can be inventoried; IPv4-only remnants are already statically administered and can be enclaved.
• Residential - out of scope, unauditable local-IPv4 assumptions and hosts that genuinely do address each other.
• IXP peering LANs - out of scope, from the second article. No default gateway, every destination a peer, all traffic lateral by design. A mechanism for resolving the way off a segment has nothing to offer one that is nothing but exits. Worth having explicitly, since it is the obvious "what about..." from the room.

New informative reference: RFC 3021.

One note on register: the articles argue conversationally and the draft cannot, so the arguments and analogies carry over but the voice does not. If any of it reads as too polemical for a standards-track Introduction, the layer-cake material in 1.2 is the most compressible.

Closes #12

🤖 Generated with Claude Code

[remcovanmook]

Superseded by #42.