IPv6-First, IPv4-Enough

A Transition Architecture for Greenfield Subsidized Builds

Network administrators planning subsidized builds hear two confident claims about IPv6, and both are wrong. The first says IPv6 makes IPv4 acquisition unnecessary: deploy the new protocol and the transfer-market line item disappears. The second says transition mechanisms are science-fair projects, too fragile for a production access network, so build IPv4-with-CGNAT like everyone else and treat IPv6 as a checkbox. A BEAD subgrantee or UBF recipient who believes the first hits activation with no translation pools, no business statics, and no plan. One who believes the second spends a decade running a heavier, more expensive NAT tier than the traffic ever justified.

The truth sits between them, and a greenfield subsidized build is the rare place where that middle architecture is genuinely practical: native IPv6 to every subscriber, IPv4 delivered as a service at the edge, and a public IPv4 footprint much smaller than a conventional design’s but emphatically not zero. This piece lays out what that looks like for a mid-size operator and puts a number on the “not zero.”

Why Greenfield Changes the Calculus

Established operators rarely get to choose IPv6-first. Their obstacle is not the core network, upgrading a BNG is a project, not a moonshot. Instead, it’s the installed base: thousands of subscriber-owned routers of unknown capability, business customers with a decade of static assignments, monitoring and provisioning systems with IPv4 assumptions baked in. Transition architectures live or die at the CPE, and a brownfield operator does not control the CPE.

A funded greenfield build does. The operator selects and supplies the ONT and gateway fleet, controls its firmware, and provisions every subscriber from a clean addressing plan with no legacy statics to honor. These are exactly the conditions under which 464XLAT or MAP-T stop being risky and become ordinary engineering. Add the multi-year construction and operating horizon public broadband funding imposes because these networks remain in service long after their grant-funded construction periods end. What’s more, the architecture chosen at activation is the one you will still be running in the mid-2030s, when the IPv4-only share of traffic likely will be smaller still. Our sizing piece (“How Many Addresses Does a Subgrant Actually Require?”) argued that dual-stack is the deployment standard for new construction. This piece takes the next step: for a greenfield build, IPv6 should be the network, and IPv4 a service the network provides.

The Architecture in One Paragraph

Every subscriber gets native IPv6: a delegated prefix, typically a /56 per home via DHCPv6-PD, drawn from an ARIN IPv6 allocation that requires no transfer-market purchase and is not subject to IPv4-style scarcity or waiting-list acquisition. Ordinary registration fees apply, but the economics resemble nothing on the IPv4 side, and since both the U.S. and Canada sit in the ARIN region, this holds on either side of the border. The access and aggregation layers run IPv6-only or IPv6-mostly, and IPv4 reaches the subscriber not as a native WAN address but as a translation service at the network edge. The payoff is structural: once subscribers have native IPv6, the major content, video, social, and CDN destinations flow natively and never touch the translation tier. On many IPv6-enabled residential networks that is a large majority of traffic (figures in the 70–80% range are commonly reported) but the share depends on operator, peering, and subscriber mix, so treat it as a planning assumption to validate against your own flow data, not an industry constant. One limit to internalize before the design hardens: no translation mechanism provides ordinary inbound IPv4 connectivity (RFC 6877 is explicit that 464XLAT is not a one-for-one replacement for native IPv4) so a dedicated-address product for customers who must be reachable over IPv4 is a permanent part of the architecture, not a transitional concession. The mechanism you choose only ever carries the shrinking outbound residue.

Three Mechanisms, One Real Decision

The candidate mechanisms differ mostly in one dimension: where the NAT state lives.

464XLAT (RFC 6877).

A stateless translator (the CLAT) on the CPE presents a private IPv4 address to the home network and translates outbound IPv4 flows into IPv6; a stateful NAT64 translator (the PLAT) at the network edge translates them to public IPv4. DNS64 may also be deployed so IPv6-capable applications can reach IPv4-only destinations directly through NAT64 and skip the double translation, but 464XLAT does not depend on it. The CLAT carries IPv4 literals and IPv4-only applications regardless, which is why subscriber experience is close to transparent. It is the most production-proven mechanism here: mobile operators have run IPv6-only 464XLAT networks for over a decade, carrying hundreds of millions of devices daily. The cost is a stateful PLAT, per-session capacity, and the same lawful-process logging obligations as CGNAT, though applied only to residual IPv4 traffic. Port usage is elastic: heavy households borrow from the pool rather than hitting a fixed ceiling.

MAP-T (RFC 7599).

Mapping of Address and Port moves the state to the CPE. Each subscriber’s delegated IPv6 prefix algorithmically encodes a shared public IPv4 address and a fixed port set; the CPE performs NAT44 into that port budget and translates into IPv6, while the border relay in the core is stateless. This is cheap to scale, trivial to make redundant, and, most interesting for a small operator, needs no carrier-side per-session NAT logging for subscriber attribution the way stateful CGNAT and PLAT designs typically do. Attribution is deterministic: given an address, port, and timestamp, the responsible subscriber falls out of the mapping rules and subscriber-assignment records rather than a per-session log pipeline. These are records that must still be kept current and time-valid. We made the point in “BEAD: CGNAT or Buy?” that the logging stack is the CGNAT cost item tested by legal deadlines rather than monitoring systems; MAP-T designs most of that cost out. The tradeoffs: a fixed port budget per subscriber, with each shared address’s roughly 64,000-port space divided by the sharing ratio, less reserved ports, so about 4,000 ports at 16:1 and 1,000 at 64:1. This is less forgiving of session-hungry households, addresses are consumed by the sharing design whether ports are used or not, and CPE support is narrower than 464XLAT’s, though OpenWrt and the major gateway vendors now cover it. Public deployments exist across several continents, including a NANOG-documented rollout at a major U.S. cable operator and a European greenfield fiber build.

DS-Lite (RFC 6333).

The elder of the family: the CPE tunnels private IPv4 straight to a carrier-side stateful translator (the AFTR), performing no NAT itself. It works and remains widely supported, particularly in cable ecosystems. But for a new build it concentrates all state and logging in the core while giving up 464XLAT’s transparency advantages, which is why most greenfield designs now reach for one of the other two.

The selection logic for a mid-size operator: choose 464XLAT when subscriber-experience transparency and CPE flexibility matter most and you are prepared to run a stateful, logged PLAT; choose MAP-T when a lean NOC wants a stateless core and a subpoena response built on mapping rules and assignment records instead of NAT session logs. Both are defensible. Neither is fragile.

What Still Consumes Public IPv4

Now the honest accounting, because “IPv4 as a service” still runs on public IPv4. Four consumers remain.

Translation pools.

The PLAT or border relay needs public addresses shared across subscribers. Because only residual IPv4 traffic arrives here, sharing ratios that would be reckless for conventional CGNAT become workable. Where a classic deployment runs 8:1 to 32:1, a reasonable initial planning range for an IPv6-first network is 32:1 to 64:1, subject to validation against expected concurrent sessions, port-allocation policy, and timeout behavior, because the ratio alone guarantees nothing about port exhaustion. For 10,000 subscribers that models to roughly 150–350 pool addresses; reserving a /23 (512) is an illustrative design choice with expansion room, not a rule.

Business and static customers.

No translation mechanism serves the customer hosting services, terminating site-to-site VPNs, or writing a static address into a contract. How much this tier consumes depends on your market, not on protocol arithmetic, so model it as two explicit populations rather than one percentage. First, single-address statics such as farms with telemetry, work-from-home professionals, small offices: assume around 5% of a 10,000-subscriber base takes a one-address product, a market assumption to replace with your own product forecast, yields roughly 500 addresses. Second, routed-subnet customers (the smaller set of businesses, schools, and municipal sites needing a routed get /29 (8 addresses) or /28 (16): 100–150 such customers consume another 800–1,600. The subnet customers, few in number, dominate the count, and here is the uncomfortable arithmetic: the static tier, not the translation pool, is the largest IPv4 consumer on an IPv6-first network. Translation shrinks the pool to a rounding error; it cannot touch this floor, and your business-product mix, not your transition mechanism, sets its height.

Infrastructure.

The externally reachable IPv4 services: authoritative DNS, mail if you run it, customer portals, interconnection, and the on-net test endpoints subsidized networks need for performance-reporting obligations. These apply to both address families, so measure both. Much of the management plane can be IPv6-native or privately addressed, so the public IPv4 count here is design-dependent rather than formulaic; a /26 to /25 (64–128 addresses) is a common landing zone at this size. Treat it as a planning allocation derived from your own design, reserved in its own aggregate so subscriber growth never forces infrastructure renumbering.

Headroom.

The long tail of IPv4-only destinations, the enterprise customer you have not signed yet, translation-pool expansion if validation pushes your ratio down, the acquisition that changes your mix. Small, but not nothing.

Now separate three numbers that the phrase “needs a /21” dangerously collapses. Modeled consumption, that is pool reservation, both static populations, infrastructure, lands around 1,500–2,000 addresses for the worked example, the routed-subnet share of the business tier being the swing variable. Operational reserve sits on top: growth, fragmentation, and product changes. The procurement prefix is what you actually buy, and requirements rarely map neatly onto CIDR boundaries: a /21 (2,048) is the lean answer if the static tier skews single-address, while a subnet-heavy business mix pushes toward a /21 plus /23, or a /20 (4,096) bought once. Set that against the same network’s alternatives from our sizing table: a /18 for public-per-subscriber, and on the order of a /21 for a conventional 16:1 CGNAT design. The comparison clarifies in both directions. Against public addressing, IPv6-first cuts the requirement several-fold, approaching an order of magnitude on a lean mix. Against well-run CGNAT, it saves fewer addresses than advocates imply, because statics and infrastructure dominate both. But it converts the translation tier from a large, stateful, heavily logged chokepoint into a small residual service, which is where the real hardware, logging, and support savings live.

Countering the Two Extremes

The claim that IPv6 eliminates IPv4 acquisition fails on the floor just calculated. Translation pools, business statics, and infrastructure are not transitional artifacts; they persist as long as any customer or destination requires IPv4. Which is to say, for the operating life of anything funded today. The operators furthest along the IPv6-only path, the large mobile carriers, still hold and use substantial public IPv4 estates at their edges. A greenfield build that budgets zero dollars for IPv4 has not achieved IPv6 purity; it has scheduled an emergency purchase.

The fragility claim fails on the deployment record. 464XLAT has carried mainstream consumer traffic at continental scale for a decade; MAP-T runs in production on multiple continents, including greenfield fiber. What remains true is that the failure modes are specific, and a greenfield operator can engineer around every one. CPE support is the binding constraint, and the one place a subsidized builder holds every card, since it chooses the gateway fleet and validates CLAT or MAP function before the first install rather than across an inherited zoo of retail routers. If you deploy optional DNS64 alongside 464XLAT, synthesized AAAA records interact poorly with client-side DNSSEC validation; since 464XLAT works without DNS64, treat that as a deployment choice to test, not an inherent cost. Port-limited households exist under MAP-T; size the port budget for consoles and cameras, not for averages. Inbound hosting breaks behind any translator, exactly as behind CGNAT; the dedicated-address product already in the design covers it. None of this is exotic. It is the normal work of qualifying an access architecture, done once, on equipment you control.

Design the Escape Hatch Before Activation

A production IPv6-first network also needs a defined exception path, specified before the first subscriber activates rather than improvised at the help desk. That means a dedicated-IPv4 product a business can simply order; a documented procedure for moving a residential subscriber whose application genuinely fails under translation (e.g. the odd VPN client, the stubborn camera NVR, the game with a hostile NAT implementation) onto a static address or a larger port budget; and a troubleshooting bypass that lets an engineer hand a session native IPv4 temporarily, to isolate whether translation is even the problem. None of this is an admission of fragility. It is the difference between an architecture with a pressure-relief valve and one where every exception becomes an argument about the architecture itself.

The Records Problem Moves Into the IPAM

An IPv6-first network shifts complexity from the data plane into the records. The authoritative dataset now spans an IPv6 delegation plan in the millions of prefixes, a compressed IPv4 estate carved into pools, static assignments, and infrastructure aggregates, and, under MAP-T, mapping rules and port budgets that are themselves attribution records. Spreadsheets were a bad idea at /18 scale; they are disqualifying here, because the address plan is now also the lawful-process answer and the compliance evidence. This is work for an IPAM/DDI platform that treats IPv6 planning and IPv4 automation as one workflow. Our ProVision platform is built for exactly that, with automated subnetting and API-driven provisioning so the delegation plan, translation pools, and static carve-outs live in one authoritative dataset instead of three tools. And if the build participates in an open-access arrangement, the translation architecture becomes a per-tenant decision on shared plant (who runs the PLAT, whose port budgets apply) a wrinkle we covered in “Open Access Means Multi-Tenant Addressing.”

Buy IPv4-Enough, Early

The procurement conclusion is smaller than a conventional build’s, not different in kind. A /21-scale requirement cannot be satisfied through a single ARIN waiting-list request, whose maximum approved size is currently a /22. So an operator needing the space on a deployment schedule should plan on transfer-market purchase, leasing, upstream-provided space, or a combination. However sourced, it belongs in the budget as a planned line item, secured ahead of activation with routing history and reputation vetted, exactly as we’ve argued before. It is simply a much smaller number, and one a lease-then-buy structure covers easily while take rate matures. A smaller portfolio also deserves the same registration, RPKI, and documentation hygiene as a large one (“IPv4 in the Deal”); a /21 with clean records is an asset, at any scale.

The posture worth carrying into a greenfield subsidized build has two halves that only work together. Build IPv6-first, because you will never again have a CPE fleet you fully control, an empty addressing plan, and a funding mandate that rewards doing it right the first time. And buy IPv4-enough (the pools, the statics, the infrastructure) because the internet your subscribers pay to reach still requires it, in a quantity you can now forecast to within a prefix length or two. Neither extreme survives contact with the worked numbers. The architecture between them does.