It just happened, RIPE-NCC, the organisation responsible for allocating IP addresses in the EU region, allocated its last IPv4 /22 (1024 unique IPs). On Monday the 25th of November at 15:35 RIPE NCC allocated the last of the available /22’s to a new LIR (Local internet registry).
The time we all knew would arrive at some point, just arrived. On Monday the 25th of November at 15:35 RIPE NCC allocated the last of the available /22’s to a new LIR.
In the days leading up to the IPv4 run-out, RIPE-NCC released a new IPv4 waiting list for new LIR’s. In this list new LIR’s will be queued, waiting for their own /22 to become available. According to RIPE-NCC, reclaiming IPv4 subnets will still continue and given back to the pool of IPv4 subnets, at which point it will be assigned to a new LIR:
Even though we have run out, we will continue to recover IPv4 addresses in the future. These will come from organisations that have gone out of business or are closed, or from networks that return addresses they no longer need.
This IPv4 run-out will force network operators of new AS networks to re-think their relation to IPv4 and hopefully make IPv6 even more important within their network setup. Hopefully we also see some more eye-ball networks (networks providing Internet access to end-users) getting IPv6 ready, because of the lack of IPv4 addresses for new companies.
What have you done to save IPv4 addresses within your network?
Our look on IPv4 and IPv6
Starting 2019 we accepted a challenge: merging 2 companies in a single one. Each with its own infrastructure and own AS network. This did not go without hiccups, but after a lot of careful planning and the fast approaching run-out of IPv4 addresses – we decided to go IPv6 all the way. This gave us another reason to fully start from scratch and re-think our networks available thus far.
As a result, the Cloudbear network is IPv6 only, with only IPv4 being available for critical endpoints exposed to the Internet (for example, load balancers and our authoritive nameservers). This enables us to save a ton of IPv4 addreses and only use them when necessary, because we only have 1,280 IPv4 addresses in total.
We invested a lot of time in developing IPv6, as a lot of software we use in our infrastructure (from Kubernetes, Ceph, MySQL to.. yes.. DirectAdmin) is not optimized to run on IPv6-only environments. But in the end, by running a combination of 464XLAT, NAT64, some custom made scripts and custom microservices – we eventually got everything up-and-running just fine and maybe even better then legacy networks with IPv4, because of the advantages of IPv6.
Interested in our DevOps services ready for the future, with IPv6 and multi-datacenter Kubernetes clusters? Shoot us a message!
