Public IPv6 addressing in the cloud: the end of NAT, but not of the firewall

WebDisk Blog · category: Cloud computing · reading time: ~8 minutes

In brief:- In Europe the pool of free IPv4 addresses ran out in 2019 – a public IPv4 address became a scarce resource, traded on the secondary market and increasingly billed as a separate item.- IPv6 restores the original model of the internet: every virtual machine can have its own public address and communicate directly, without address translation (NAT).- A public address is not an open door – what is visible from the internet is decided by the firewall; the sensible standard today is dual-stack, meaning IPv4 and IPv6 in parallel. >Not working with a terminal? You can skip the section with commands – the rest of the article reads fine without it.

Every year billions of new devices connect to the internet: phones, sensors, cameras, and in clouds – virtual machines and containers, often with a lifetime measured in minutes. Meanwhile the IPv4 protocol, on which the internet has run since the 1980s, offers just under 4.3 billion addresses. That has been too few for a long time – and this is not a distant forecast but a fact: in 2019 RIPE NCC, the registry that allocates addresses in Europe, handed out the last free blocks from its main pool.

The technical answer has existed for over two decades and is called IPv6. It is not “IPv4 with more addresses”, but a return to the original idea of the internet, in which every device has its own unique address and communicates with others directly – without intermediaries translating addresses on the fly.

In this article we explain where the address shortage came from and why it drives up costs, what public IPv6 addressing gives you in practice in the cloud, why a public address does not excuse you from configuring a firewall – and how to check in a few minutes whether your machine really uses IPv6. The conceptual sections are for anyone who decides on IT architecture in a company; the practical section is for administrators.

Why is there a shortage of IPv4 addresses and how much does it cost?

An IPv4 address is a 32-bit number, so there are about 4.3 billion possible addresses in total – fewer than there are people on Earth, let alone devices. The internet did not grind to a halt thanks to a workaround called NAT (Network Address Translation): one public address is shared by many devices, and the router translates traffic in both directions. Operators went a step further and use CGNAT – NAT on the scale of entire neighbourhoods, where hundreds of customers share the same public address.

NAT works, but it has its price. A service hidden behind translation is not reachable from outside until we configure port forwarding; direct connections (internet telephony, video conferencing, games, P2P networks) require workarounds; diagnosing “who is actually connecting to us” gets complicated when hundreds of devices hide behind a single address.

The shortage is also visible in costs. There are practically no free IPv4 addresses left in the registries, so they are traded on the secondary market, and some large cloud providers bill a public IPv4 address as a separate line item. We have already written on the blog about what makes up the price of a public cloud – public addressing is one of those components you do not see in the specification table until it starts to cost.

IPv6: not “more of the same”, but a different network model

An IPv6 address has 128 bits. The number of possible addresses is so large (39 digits) that it stops being intuitive, so a different measure is more practical: the standard single network in IPv6 is a /64 block, which on its own contains over 18 quintillion addresses – a pool over four billion times larger than the entire IPv4 internet. This extravagance is deliberate: such a large subnet enables stateless autoconfiguration (SLAAC), in which a machine derives its own address from the prefix advertised by the router – without a DHCP server and without manual address assignment.

The most important change, however, is architectural. Since there are enough addresses for every device, NAT stops being necessary: a virtual machine, a container or a sensor can have its own globally unique address and communicate with any other device directly. Gone is port forwarding, gone is the juggling of one public address between services, gone is a whole class of “it does not work through double NAT” problems. The network topology becomes simpler to design and – equally important – to understand a year later, when it has to be changed.

What does public IPv6 addressing give you in the cloud?

In a cloud environment the difference is especially noticeable, because that is where the number of addressable entities grows fastest: every virtual machine, every container and every service may need to be reachable from outside.

With public IPv6 addressing:

• you expose a service directly – without reserving another IPv4 address and without port mapping; the address of the service is its address, not “port 8443 on a shared address”;
• the architecture is clearer – traffic does not pass through a translation layer, so logs and diagnostics show the real addresses of both ends of the communication;
• scaling does not exhaust the pool – the tenth, hundredth and thousandth machine get addresses just as easily as the first.

In WebDisk Cloud – a public cloud built on the Apache CloudStack platform – public IPv4 and IPv6 addressing is part of the networking offer, alongside VPC networks, NAT/SNAT, the firewall, port forwarding and load balancers. Which machines and services are reachable from the internet is decided by firewall rules set by the customer, not by the limits of the address pool. You will find the details on the WebDisk public cloud page, and if you are moving an existing environment – take a look at the guide to migration from VMware to WebDisk Cloud as well.

A public address ≠ an open door: the firewall is mandatory

The most common concern about IPv6 goes like this: “if every machine has a public address, then every machine is exposed to attack”. This concern confuses two things: addressability and reachability.

NAT was never designed as a security mechanism – it merely happened to have the side effect that machines without port forwarding were hard to reach from outside. In the IPv6 world the same (and better) control is provided by the firewall: by default we block incoming traffic and open only what we deliberately expose. The difference is that the decision is explicit and auditable, instead of resulting from an accidental property of address translation.

In the cloud it is worth maintaining rules at two levels: the firewall at the platform level (network rules defined in the cloud panel) and the firewall in the machine's operating system itself. Two layers are not overkill – they are protection against a mistake in one of them.

Two pitfalls deserve a mention of their own. First, services can listen on IPv6 even though they were configured “for IPv4 only” – many servers bind by default to the :: address, which covers both protocols; it is worth checking this (we will show how). Second, you should not count on “nobody will find us in a /64” – scanning 18 quintillion addresses is admittedly impractical, but the addresses come to light anyway: through DNS, logs, headers, certificates. Hiding does not replace a firewall or updates. And since the machine is publicly reachable, it is all the more important to know what is happening on it – we wrote about monitoring the state of a VM yourself in the article on the Watchdog.

What is dual-stack and why do you still need IPv4?

Although the share of IPv6 has been growing for years, part of the internet still communicates over IPv4 only. That is why the transitional standard – “transitional” for a decade already and probably for years to come – is dual-stack: a machine has an IPv4 and an IPv6 address at the same time, and the operating system chooses the protocol for each connection.

For a service exposed on the internet this means in practice: we publish in DNS both an A record (IPv4 address) and an AAAA record (IPv6 address). Modern clients use the Happy Eyeballs mechanism – they try IPv6 and quickly fall back to IPv4 if that path does not respond. That is good news with one caveat: broken IPv6 can be worse than no IPv6 at all. If you publish an AAAA record while the firewall blocks IPv6 traffic or the route does not work, some clients will experience delays. The conclusion: after enabling IPv6 we test and monitor the service on both protocols, not just on the one our own computer happens to connect with.

How do you check whether your machine uses IPv6?

The commands below work on a typical Linux machine and change nothing in the configuration – they only read the state.

# 1. Does the machine have a global IPv6 address?
# (we look for the "global" scope; fe80::... alone is a link-local address – that is not enough)
ip -6 addr show scope global

# 2. Is there a default route for IPv6?
ip -6 route show default

# 3. Does traffic actually reach the outside world over IPv6?
ping -6 -c 3 2001:4860:4860::8888 # Google public DNS resolver
curl -6 https://ifconfig.co # prints your public IPv6 address

# 4. What is listening on IPv6 – that is, what the internet will see once the firewall is opened
ss -6tulnp

# 5. Does the firewall in the system cover IPv6?
sudo nft list ruleset # tables of type "inet" cover both IPv4 and IPv6
sudo ip6tables -L -n # older systems based on iptables

If point 1 or 2 returns nothing, look for IPv6 addressing in the cloud panel's network configuration first – a machine will not conjure up an address that the network does not advertise to it. If the commands from point 3 work and the service still does not answer over IPv6 from outside, the firewall is almost always to blame (at one of the two levels), or a missing AAAA record in DNS.

What will IPv6 not solve?

To complete the picture, let us also list what public IPv6 addressing does not give you:

• It will not automatically speed up applications. A path without NAT can be simpler, but real performance depends on the routes between network operators – over IPv6 it is sometimes faster and sometimes slower.
• It will not improve security by itself. A firewall, updates and monitoring are needed exactly as much as with IPv4.
• It will not let you switch off IPv4 today. As long as some clients and services live on IPv4 only, dual-stack remains a necessity.
• It requires a review of your tools. Logs, address allowlists, banning mechanisms, database fields for IP addresses (the text form of IPv6 is up to 45 characters), geolocation and monitoring have to understand the new format – these are usually small but numerous fixes.

Frequently asked questions

Will IPv6 replace IPv4? Eventually yes, but the horizon is counted in years, not months. That is why the practical question is not “IPv4 or IPv6”, but “does my environment support both”.

Isn't a public address on every machine a risk? The risk is the lack of a firewall, not the address. The rule is the same as always: block incoming traffic by default, open it deliberately and selectively, maintain rules at the platform level and at the operating system level.

Is IPv6 faster than IPv4? The protocol itself gives no such guarantee. The absence of translation simplifies the packet path, but latency is decided mainly by the routes between network operators. Treat any gain as a pleasant surprise, not a business argument.

Why does a public IPv4 address cost extra? The pool of free IPv4 addresses in the European registry RIPE NCC ran out in 2019, so addresses are obtained on the secondary market. That is why some cloud providers bill a public IPv4 address as a separate line item. IPv6 does not have this problem – there are enough addresses for every machine.

My application stores users' IP addresses. Do I have to change anything? Probably yes: check field lengths (text IPv6 is up to 45 characters), format validation and every place where an address is compared or filtered. Remember also that an IP address – regardless of version – remains information that you process in line with data protection rules.

Where do I start in an existing environment? With an inventory: which services are to be reachable from the internet and which only internally. Then dual-stack on edge services, tests from outside on both protocols, and finally the AAAA records in DNS. The DNS record is deliberately last – from the moment it is published, clients really do start using that path.

Summary

The IPv4 address shortage is permanent and increasingly just costs money. IPv6 solves it at the source: it restores a model in which every machine can have its own public address, and the availability of services is decided by explicit firewall rules, not by acrobatics with address translation. The sensible path today is dual-stack – deployed deliberately, with tests of both paths. And if along the way you are wondering where to put such an environment, we write about the strengths of a local provider in the article on Polish cloud computing.

If you are planning an environment with public IPv6 addressing, check out the WebDisk public cloud offer or write to us – we will help you plan the addressing and the firewall rules.