IPv6 Allocation and Billing for Hosting Providers

IPv4 is the constraint every hosting provider plans around. IPv6 is the one most treat as a checkbox — allocated once, documented nowhere, never billed, and quietly mismanaged until something needs it. Both of those are billing problems as much as network ones, because address space is inventory, and inventory that nothing tracks is inventory you lose.

Here is how to treat IP space as a billable, tracked resource.

IPv4 is inventory, and it leaks

Treat your address space the way you treat rack units: a finite pool, allocated to services, returned on termination. The failure mode is always the same and it is always discovered at the worst time — you run out of addresses while holding hundreds that are assigned to services that no longer exist.

Three causes, in order of how much space they waste:

Termination that does not release. A service is destroyed and its addresses stay allocated because release was never wired to termination. This is the big one, and it compounds silently over years.

Manual assignment. Somebody picks an address from a spreadsheet, and the spreadsheet is one edit behind reality. Every manual step is a future duplicate assignment.

Failed provisioning that reserved first. The address was allocated, the machine never came up, and nothing unwound it. See when provisioning fails after payment.

The audit that finds all three is a query, not a project: list every allocated address whose service is terminated, cancelled or nonexistent. If your IP records live in a different system from your service records, that query is a comparison between two databases and nobody runs it. If they live in the same schema, it is a join and you can run it weekly.

Selling IPv4 without gouging

Additional IPv4 addresses are a legitimate recurring product, and they are increasingly priced as one because the addresses genuinely cost money now. Three things make that defensible rather than resented.

Justification. Regional registries expect addresses to be used, and asking a customer what they need a /29 for is a normal part of the process rather than an obstruction. Build the justification into the order flow so it is captured once rather than chased later.

Reclaim policy. Say in the terms what happens to unused addresses on an active service. A customer holding sixteen addresses and using two is your inventory problem, and it is much easier to address if the policy predates the conversation.

Portability expectations. Be clear that the addresses are yours, assigned for the duration of the service, and do not travel with the customer when they leave.

IPv6 is not scarce, which creates a different problem

You will not run out. That is exactly why IPv6 allocation goes undocumented — there is no pressure forcing discipline, so nothing enforces it, and two years later nobody can say which prefix belongs to which customer.

The practical guidance:

• Allocate a prefix, not an address. A single /128 to a VPS is the IPv4 mindset applied to a protocol that does not need it. A /64 per interface is the normal unit; a /56 or /48 per customer is normal for anyone who will subnet.
• Track it in the same system as your IPv4. Two systems means one of them is wrong.
• Do not bill per address. Charging per IPv6 address makes no sense and reads as rent-seeking. If you monetise IPv6 at all, it is by prefix size at the larger end, and most providers include it.
• Plan the hierarchy once. Which prefix serves which location, which rack, which customer class. Retrofitting a scheme onto an allocated network is far harder than choosing one badly and consistently.
• Release on termination, the same as IPv4. Not because you need the space back, but because a customer record that still holds a prefix is a record that is wrong.

Where IP space meets the invoice

Three connections that matter, and that most stacks leave to a person.

Allocation on provisioning. When a paid order provisions, addresses should come from the correct pool for that location automatically. Manual assignment at this step is where duplicates and mistakes enter.

Release on termination. The single most valuable automation in this whole area, and the one most likely to be missing.

Overage and transit. If you sell IP transit or bill bandwidth commitments, the overage calculation has to run on a schedule and produce an invoice rather than a report somebody reads. A number nobody bills is not revenue.

There is also a location trap worth naming: addresses are not fungible across sites. A pool belonging to one datacenter cannot serve a machine in another, and a system that picks the first free address globally rather than the first free address in the right location will hand out an address that cannot route. If you run more than one site, confirm your platform scopes pools to locations.

How FluxBilling fits

IPAM is included on every FluxBilling tier from €4.95/month — subnets, VLANs, IPv4 and IPv6, with allocation on provisioning and release on termination handled through the same service records that drive billing rather than through a separate DCIM product. Because the addresses and the services are in one schema, "which allocated addresses belong to dead services" is a query rather than a reconciliation exercise between two systems.

Address pools are scoped to deployment locations, so a machine in one site draws from that site's pool. IP transit overage invoicing runs as a scheduled step in the daily billing pass, so committed-rate overages become invoices rather than a report. Additional addresses can be sold as billable products against the same pool they are allocated from.

See IPAM, DCIM and current pricing.

Closing thoughts

Run one query this week: every IP address your system considers allocated, joined to the service that holds it, filtered to services that are terminated or missing. Whatever comes back is address space you already own and cannot use. For most providers who have never looked, it is a larger number than expected — and it is the cheapest capacity you will ever recover.