Knowledge base IPv4 management plans
Obviously, with the demise of the legacy IPv4 internet we have to consider our plans for how we will manage IPv4 address space over the coming years. These plans are not set in stone and will depend on take up of IPv6, the technology to support that (routers and so on) and growth in customer numbers, etc.
Basically, as an ISP, we will be able to get a final 1024 address block from RIPE at some time when we need it. We are at least months away from needing this. However, we will eventually get to a point where we have no more IPv4 addresses coming our way and have to consider steps to make best use of the addresses we have. We are very keen to avoid any sort of carrier level NAT on IPv4 for a wide variety of reasons.
Read about our plans for World IPv6 Launch 2012
The good news is that we have a plan, and that we have IPv4 addresses at present, so no need to panic right now. We have been running IPv6 for a long time and have services running on IPv6 as well as IPv4.
Recovery of our unused space
We have already been auditing internal usage of IP space and have some blocks we can now recover and re-use for customers. In some cases some final machines being relocated from one data centre to another, and similar work, mean we can free up some blocks.
Recovery of customer unused space
We suspect some customers with IPv4 allocations are not using them or not using the full allocations. We plan to audit usage and find such allocations, and talk to the customers. If they are happily using NAT or a proxy, and can reduce or release blocks, we will take them back.
Not giving IPv4 blocks out
At present we are still assigning IPv4 blocks where needed by customers, though this is no longer on the order form. The time will come when we stop offering IPv4 blocks, only the single static external (WAN) IPv4 address on your line.
Recovering /29s, /30s and /32s
Customers currently using routers and firewalls (such as the older FireBrick FB105) often have a /30 or /29 interlink block between the external broadband routers and their firewall. We are encouraging customers to upgrade to systems that use PPPoE directly from their firewall (e.g. the FireBrick FB2700). This will free up the /30 and /29 blocks used for interlink.
We normally assign a separate public IPv4 WAN address where customers have an internal IPv4 block. We plan to change this where customer routers can cope to be an address from the assigned range (network address, typically). Also, where customers have multiple lines with separate WAN addresses for each, use of newer PPPoE based firewalls can allow a single WAN to be shared by all of the lines.
Saving /29s, /30s and /32s may not seem much, but each address saved is an address we can use for a new customer WAN address.
Now that RIPE have finally run out, PI space is no longer available. However, a number of customers did obtain PI space and so freed up previous assignments they had from us. Thank you.
Customers using lots of IPv4 space will be encouraged to take up IPv6 and switch their global IP usage to IPv6 if possible. We aim to work with customers to help them make the transition as seamlessly as possible. Once their usage of the global IP space is all IPv6 they will be able to switch to proxies or NAT for IPv4 access to the legacy internet and free up addresses.
Charging for IPv4
In spite of our best efforts the day will come when we have to start charging for IPv4. This will be a motivator for companies to consider the options above and take on IPv6 as a solution to their networking requirements. This is something we will not do until necessary and will be notified well in advance. Hopefully this will not be needed as we should have convinced people to move to IPv6 properly and no longer need blocks of IPv4.
It may be many years before we have to consider this, but ultimately we would rather that we are giving every customer a fixed WAN IPv4 address than maintaining IPv4 routed blocks to customers that refuse to switch to IPv6. Ultimately we can reclaim IPv4 space from such customers. This would be a very last resort and should never be needed as all of the previous steps should have amicably migrated businesses to IPv6 usage.
Non IPv4 connections
Eventually we may have customers that do not need any IPv4 addresses at all. We already have support for NAT64 to allow IPv6 only networks to access Legacy IPv4 machines on the internet, and we will prefer this as a solution than doing carrier IPv4 NAT. This is something people can try now, and by the time it is needed, some years in the future, the technology should be mature. However, we expect more and more of the services on the internet to be IPv6 by then and legacy IPv4 access to be an niche requirement.