IPv4 Exhaustion Date Calculator for Network Planners

But here’s the thing: you don’t run out of IPv4 addresses, you run out of a way to get enough continuous addresses to satisfy what you need today. And why does it matter? We are not all hitting the end of line at once. Running out isn’t an event; it’s a local issue and it come in waves. How fast each wave hits you depend on how you cut up your remaining inventory. That’s the bit the calculation do for you (above), but that’s where doing the planning comes into play.

You need to know what goes into that input. The problem with most people’s left-over IPv4 pool is that they consider it a bank account. They have X, they use some, now they has fewer. Engineering networks are much more than numbers. The struggle around how many addresses is usable and how they are allocated matter.

How to Plan Your IP Address Use

Carving a /24 out for a new customer doesn’t just remove 256 addresses from your pool; it removes a contiguous block. Your pool might have enough physical address left over to handle ten more customers. But it might only have room to accommodate one of them somewhere within its fragments. Overhead include the unusable fragments, such as policy-held ranges and the slack for route aggregation. It uses these fragments when calculating size of your pool. Not accounting for the overhead is the quickest path to painting an overly rosy picture, and when you attempt to allocate an IP, that picture shatters.

Finally there’s growth. Growth isn’t a straight line either; it’s not just consumption. When you assume a constant burn rate, you’re assuming you’ll continue to burn through addresses at a constant rate over time. But the network grow exponentially. Each new customer or service create more demand for address space, which in turn typically demands more infrastructure. That infrastructure has its own set of addresses which need to be allocated. Redundant links, monitoring agents, management interfaces… They all consumes from the pool. That growth rate represent this compounding demand.

Because the curve gets steeper as you grow, a few percent points higher in your growth rate can remove months from your runway. Negative growth rates reflect two factors: One is active IPv6 migration. But the other is address reclamation. How fast are you removing older addresses? If you have an aggressive cleanup program, you’ll see a reduction in amount burned, and thus a negative growth rate.

Most people forget about this one. They calculate their gross rate of address allocation; however, they fail to include rate of recovery. This is why net burn is so important. The reserves are just as important: you don’t want to run dry either. You want to end up at a comfortabley floor that leaves you enough room to make emergency patches. And you’d like some buffer to test your migrations or handle vendor exception. If you put a reserve floor at 5% or 10%, that shifts your exhaustion date dramaticly.

That begins making you consider conservative addressing. You’ll talk about buying from the market sooner then if you’re thinking about depleting absolutely everything. This table of references on page shows what happens to various pool sizes when they get different levels of buffer. Even if you’re burning low, a small /20 pool is going to exhaust quickly. But a big /8 may well last years… Though often it’s the policy constraints that overwhelms the total number.

Management of IPv4 is a logistics issue more than a mathematics issue. You’re shipping product in a limited space. Visualization is tool. And the strategy is what you do with the visualization.

Is this a six year timeline or a six month timeline? That’s where your policy becomes tight. That’s where you start acquiring addresses on the open market. What you don’t want to do is run out. You would of wanted to run out when you want to run out. And you want to give yourself some time to prepare for next part of building your network.