Five Ways to Stretch Your IPv4 Space (and What Each One Costs You)

July 15, 2026 · by Maddie Beaton

Every new customer needs an IP address, but the cost of IP addresses can really add up (~$7000 USD for a /24 of 256 IPs in 2026). Long gone are the days where you could just make a request for more from ARIN and get free ones delivered within months. This means that how you assign the addresses you already have is now a business decision with consequences for support load, gaming performance, abuse handling, and even how you respond to law enforcement requests.

Here’s how the strategies we see in the field stack up, including the trade-offs vendors don’t always mention.

Public subnets per AP: the old way

This was the original approach, carving your space into small subnets and assigning one to each access point, or bridging a subnet across the APs on a site router. DHCP hands every customer a real, public, routable IP.

When it works, it’s great. No NAT anywhere. Customers can host servers, run VPNs, game, and do anything the internet was designed for, with zero NAT weirdness. Troubleshooting is simple because what the customer sees is what the internet sees, and it’s how everything is designed to work.

The problem is it’s very wasteful of IP addresses. Every subnet loses addresses to the network, broadcast, and gateway definitions: a tiny /29 gives you five usable customer addresses out of eight. Worse, utilization is never even: one AP fills its subnet while the next sits half-empty, and resizing subnets to chase actual usage is a constant, disruptive chore.

Back when you could always get more space from ARIN, nobody really cared - but today this design isn’t feasible cost-wise for a lot of smaller WISPs, so it’s very rarely seen.

PPPoE: centralize the pool

PPPoE solves the fragmentation problem by moving address assignment off the towers entirely. Sessions terminate on a concentrator (usually a core router), and addresses come from one centralized pool that serves the whole network. Utilization is nearly perfect: no per-AP subnet math, no stranded addresses sitting in unused pools. If the session lands on the customer’s own router, they still get a real public IP with no NAT issues, and server hosting works fine.

The costs show up in operations. Customer equipment has to support PPPoE, so you’re now managing a second set of credentials alongside everything else, and every time a customer buys a new router at the store, there’s a support call to walk them through PPPoE setup — username, password, and the inevitable typos. You can work around that by terminating PPPoE in the customer’s radio instead, but then you’ve reintroduced NAT between the radio and the customer’s router, or the radio has to become the customer’s router, which brings its own support burden (now you’re helping troubleshoot port forwarding rules and UPnP).

PPPoE is still a solid choice, but it has a lot of infrastructure (layer 2 tunnels to the concentrator) and a lot of support issues, which makes it fairly onerous to set up and maintain.

Traditional NAT: simple, but with a lot of drawbacks

Plain NAT (or a pooled NAT across a few public IPs) is the path of least resistance: customers get private addresses, a router at the edge translates, it’s basically a single firewall rule and you’re done. This is often how a lot of small ISPs get their start, by just using the handoff IPs they get from their upstream provider.

The downsides start to build up once you scale though. Nearly every customer has their own router, and with you running NAT at the edge, they end up double-NATed. A lot of gaming consoles misbehave behind double NAT, reporting “Strict NAT” and failing to join sessions or use voice chat. UPnP can’t punch through a NAT layer the customer doesn’t control.

There are also some bigger administrative issues as well. If one customer gets your shared IP banned from a game server or mail provider for abuse, everyone behind that IP is banned with them, and identifying the responsible party after the fact is guesswork. And if law enforcement serves you a warrant asking who was using a given IP at a given time, the only answer is “someone on our network”, which doesn’t tend to be very helpful to anyone.

CGNAT: a scalable compromise

Carrier-grade NAT is basically like traditional NAT, but with some improvements so that it can work with larger networks. The main differences are that when deployed properly, customer routers sit in the shared address space set aside for exactly this purpose (RFC 6598, 100.64.0.0/10, so it never collides with the private ranges customers use at home), and NAT happens with deterministic rules: each customer maps to the same public IP and the same block of ports, every time, and customers are spread evenly across your public pool so as few as possible share any single address.

This deterministic approach solves a few issues:

Warrants. If a request includes the IP and port, the mapping identifies the exact customer. If it includes only the IP, you can at least narrow it to the handful of customers on that address.
Abuse. If an IP gets banned or blacklisted, you can identify which customers were behind it, find the responsible one, and pull that IP from the pool so it stops affecting anyone.
DDoS. When a CGNAT IP gets targeted, it can be removed from the pool automatically and its customers reassigned to clean addresses; the attack keeps hammering an IP nobody is using anymore and you can safely BGP blackhole it without affecting any customers.
Gaming. If the CGNAT system is configured with EIM (RFC 4787 endpoint-independent mapping, or “full cone NAT”), then the UDP ports that are used outbound become reachable by inbound traffic regardless of their original destination. This is often enough to get voice chat and game matchmaking working on many consoles and move them from “Strict NAT” to “Moderate NAT” status.

Swift Fox automates all of this: pool management, deterministic mapping, abuse-driven pool removal, DDoS reassignment, and EIM for UDP traffic are all built in, so CGNAT is as easy to set up as basic NAT was.

The downside: it’s still NAT, and customers with their own routers are still double-NATed, with some of the same issues as traditional NAT. For customers that need true inbound connectivity (server hosts, some VPN setups), the practical answer is a static public IP as a paid add-on, and pulling IPs out of your CGNAT pool to assign to individual customers is very easy to do.

An aside: DHCP Option 121, the best of both worlds (eventually)

There’s a technique that theoretically beats everything above: use DHCP Option 121 (classless static routes, RFC 3442) to hand each customer router a single public /32, routed individually through the network like a loopback with a point-to-point path back. You get PPPoE’s perfect pool utilization and per-customer inbound-capable assignment, with no PPPoE credentials, no NAT, and no subnet losses. Every address in your pool is a usable customer address.

The catch is the consumer router market. Option 121 support in off-the-shelf home routers is inconsistent enough that you can’t really rely on it yet. We’re watching this one closely, and if consumer router support reaches critical mass, automated Option 121 assignment is on our feature list to build into Swift Fox. If you’re running it successfully on your network, we’d love to hear about it!

Isn’t IPv6 supposed to solve this?

In theory yes, as IPv6 IPs are practically unlimited and are real public addresses that don’t need any NAT at all. But unfortunately, much of the Internet still only supports IPv4 and even if you deploy IPv6, you still need to give customers a way to reach (and be reached by) the IPv4 Internet.

That said, every device and service that can talk IPv6 natively is a session that never touches your CGNAT, never consumes a port block, and never double-NATs. Modern consoles and the biggest traffic sources — streaming, CDNs, major platforms — prefer IPv6 when it’s available, so rolling out dual-stack here (assuming customer routers support it properly) can sometimes mitigate a lot of the common gaming complaints out there. It doesn’t make the IPv4 problem go away, but it makes every IPv4 strategy on this page work better.

Where this leaves most networks

For a growing WISP in 2026, the realistic shortlist is CGNAT with deterministic mapping for the general subscriber base, static public IPs as a paid add-on for the customers who need them, and dual-stack IPv6 everywhere you can manage it. It’s the combination that stretches your address space furthest while keeping you able to handle the edge cases — from game servers, from blocklists, and from the police.

If you’re running per-site subnets or wrestling with PPPoE support calls today, the migration is less painful than it looks, and it’s the kind of thing we help operators through directly. Reach out and we’ll walk through what it would look like on your network.