The Internet was designed in the 1980s on a 32-bit address space that seemed infinite: 4.3 billion IPv4 addresses. Four decades later, that pool has been completely exhausted. IANA allocated its last /8 block in February 2011 and RIPE NCC (the European regional registry) declared effective exhaustion in November 2019. Today, obtaining new IPv4 addresses is virtually impossible without resorting to the secondary market, where a single /24 block (256 addresses) can cost tens of thousands of euros.
The solution designed over 25 years ago for this problem is IPv6, a protocol with a 128-bit address space that provides 340 undecillion unique addresses. Despite its technical maturity, IPv6 adoption has been slow: many organisations still rely exclusively on IPv4 with NAT, CGN and patched solutions that add complexity and limit connectivity. This article explains why the transition to IPv6 is inevitable, how the migration mechanisms work and how to prepare your servers and networks for a dual-stack world.
IPv4 Exhaustion: Timeline and Consequences
The IPv4 protocol, defined in RFC 791 (1981), uses 32-bit addresses that allow a theoretical maximum of 2^32 (4,294,967,296) addresses. In practice, after reserving ranges for multicast, loopback, private networks and special uses, the available public addresses are significantly fewer. The explosion of connected devices (smartphones, IoT, cloud) accelerated consumption until the model became unsustainable.
- event February 2011: IANA allocates the last five /8 blocks to the five Regional Internet Registries (RIRs). The central pool is officially exhausted.
- event September 2015: ARIN (North America) exhausts its free pool and begins operating with a waiting list.
- event November 2019: RIPE NCC allocates its last /22 block. New requests enter a waiting list with no allocation date.
The consequences are direct: ISPs must share addresses through Carrier-Grade NAT (CGN), cloud providers pay increasing prices for each public IP, and services that need end-to-end connectivity (VoIP, P2P, gaming, IoT) suffer from latency, incompatibility and impossible debugging.
IPv6 Basics: 128-Bit Addressing
IPv6 uses 128-bit addresses represented in hexadecimal notation separated by colons: 2001:0db8:85a3:0000:0000:8a2e:0370:7334. Compression rules allow abbreviating consecutive groups of zeros with ::, resulting in 2001:db8:85a3::8a2e:370:7334.
- public Global Unicast (GUA): equivalent to IPv4 public IPs. Prefix 2000::/3. They are globally routable and each device can have one or more.
- lan Link-Local (fe80::/10): auto-configured on every interface and allows communication within the L2 segment without DHCP or manual configuration. Essential for NDP operation.
- vpn_lock Unique Local (ULA, fc00::/7): equivalent to IPv4's 10.x, 172.16.x, 192.168.x ranges. For internal networks without global routing.
With 128 bits, IPv6 provides 3.4 x 10^38 addresses: enough to assign billions of IPs to every square metre of the Earth's surface. The standard allocation for an end site is a /48 prefix (65,536 subnets, each with 2^64 hosts), which fundamentally eliminates the need for NAT and restores the Internet's original principle of end-to-end connectivity.
IPv4 vs IPv6: Comparison Table
The differences between the two protocols go far beyond address size:
| Criterion | IPv4 | IPv6 |
|---|---|---|
| Address size | 32 bits (4 octets) | 128 bits (16 octets) |
| Total space | ~4.3 billion | ~340 undecillion |
| Format | Dotted decimal (192.168.1.1) | Colon hexadecimal (2001:db8::1) |
| NAT | Ubiquitous, required | Not required, native end-to-end |
| Configuration | DHCP or manual | SLAAC, DHCPv6 or manual |
| Header | Variable, with options | Fixed 40 bytes, extension headers |
| IPsec | Optional | Built into the standard |
The NAT Problem: CGN, Port Exhaustion and P2P
NAT (Network Address Translation) was the emergency solution that allowed IPv4 to survive beyond its natural capacity. By sharing a public IP among multiple private devices, NAT delayed exhaustion, but it introduced fundamental problems that worsen over time.
Carrier-Grade NAT (CGN) takes this problem to the extreme: hundreds or thousands of subscribers share a single public IP. This causes TCP/UDP port exhaustion (each IP has only 65,535 ports), breaks protocols that depend on end-to-end connectivity (SIP, IPsec, some online games), hinders geolocation and means that blocking an IP for abuse affects thousands of innocent users.
IPv6 eliminates NAT by design. Each device has its own globally unique address, restoring the end-to-end connectivity that the Internet needs to function correctly. Security is implemented with stateful firewalls, not with the obscurity that NAT provides.
Key concept:
NAT is not a security layer: it is an addressing patch. IPv6 restores end-to-end connectivity and delegates security to properly configured firewalls, which is where it should have always been.
Transition Mechanisms: Dual-Stack, 6to4, NAT64 and 464XLAT
The transition from IPv4 to IPv6 is not a switch that gets flipped all at once. Several mechanisms have been designed to facilitate coexistence during the migration period:
- swap_horiz Dual-Stack: the recommended method. Each network interface is assigned both an IPv4 and an IPv6 address. Applications use whichever protocol best connects to the destination. It is the strategy that enables a gradual transition without breaking anything.
- tunnel 6to4 / 6in4: encapsulates IPv6 packets inside IPv4 to transport them over networks that do not yet support native IPv6. Useful in early phases but introduces latency and complexity. It is gradually being deprecated today.
- translate NAT64 + DNS64: allows IPv6-only clients to communicate with IPv4 servers. DNS64 synthesises fake AAAA records for IPv4 destinations and NAT64 translates packets in transit. Ideal for IPv6-only mobile networks.
- sync_alt 464XLAT: combines translation on the client (CLAT, IPv4 to IPv6) and on the network (PLAT, IPv6 to IPv4) so that legacy IPv4 applications work over IPv6-only networks. It is the mechanism used by most mobile carriers.
IPv6 for Servers: AAAA Records, Dual-Stack Hosting and Firewall
Enabling IPv6 on a server involves three fundamental steps. First, configure the IPv6 address on the network interface (assigned by the provider or via SLAAC/DHCPv6). Second, create an AAAA record in DNS pointing to the server. Third, configure the firewall to accept IPv6 traffic on the required ports.
In dual-stack hosting environments, the server listens simultaneously on IPv4 and IPv6. Clients that support IPv6 will connect via IPv6 (the Happy Eyeballs algorithm prioritises the fastest path), while legacy clients will continue using IPv4. This guarantees full compatibility without losing the advantages of IPv6 for those who already support it.
The firewall requires special attention. Unlike IPv4 where NAT provided an accidental layer of protection, in IPv6 every server is directly reachable from the Internet. ip6tables (or nftables) rules must replicate the IPv4 security policy: deny everything by default and open only the required ports. It is critical not to block ICMPv6, which is essential for NDP, PMTUD and neighbour auto-detection to function correctly.
IPv6 Adoption Statistics
According to Google's data, global IPv6 adoption exceeds 45% in 2026. Some countries lead with over 60%: India, France, Germany, the United States and Brazil. Mobile carriers are the main drivers, with predominantly IPv6-only networks that use 464XLAT for IPv4 compatibility.
In the hosting and datacentre world, adoption is more uneven. Major cloud providers (AWS, Azure, GCP) offer full IPv6 support, but many dedicated hosting and VPS providers still deliver only IPv4 by default. For web services, not offering IPv6 means that a growing proportion of users (especially mobile ones) need to pass through additional translation layers, adding unnecessary latency.
IPv6 Security: Myths and Realities
One of the most persistent myths is that NAT provides security. In reality, NAT only hides internal addresses; it does not inspect traffic, does not detect malware and does not replace a firewall. IPv6 removes NAT but does not remove security: security is implemented with stateful firewalls, which work equally well or better on IPv6.
- shield ICMPv6: essential for IPv6 to function. Unlike ICMP in IPv4 (which is often blocked without consequences), blocking ICMPv6 breaks Path MTU Discovery, Neighbour Discovery and Router Advertisement. Best practices always permit ICMPv6 types 1-4, 128, 129, 133-137.
- devices NDP (Neighbour Discovery Protocol): replaces IPv4's ARP. It uses ICMPv6 messages to discover neighbours, routers and perform duplicate address detection. Vulnerable to spoofing on local networks; RA Guard and SEND are the countermeasures.
- visibility_off Privacy Extensions (RFC 8981): generate random temporary IPv6 addresses for outbound connections, preventing tracking by interface address. Enabled by default on most modern operating systems.
Common Mistakes During Transition
Experience from thousands of migrations reveals repeated error patterns that can be avoided with proper planning:
- warning Enabling IPv6 without a firewall: activating IPv6 on servers without configuring filtering rules exposes internal services directly to the Internet. Every public IPv6 address is globally reachable.
- warning Blocking ICMPv6: breaks critical functions like PMTUD and Neighbour Discovery. TCP connections will fail silently with oversized packets.
- warning Forgetting reverse DNS: many services (email, BGP peering) validate the PTR record. Without IPv6 reverse DNS configured, emails may be rejected and BGP sessions may fail.
- warning Hardcoding IPs in applications: applications should use DNS names, not literal IP addresses. IPv6 addresses in brackets in URLs ([::1]) require explicit support in many libraries.
Planning Your IPv6 Transition
A successful migration requires a structured plan. These are the recommended steps for organisations operating their own infrastructure or in the cloud:
- checklist Compatibility audit: verify that all components (firewalls, load balancers, applications, libraries, monitoring) support IPv6.
- checklist Request an IPv6 prefix: obtain a /48 or /32 block from the provider or the RIR. Design the subnetting scheme (one /64 per VLAN/segment).
- checklist Deploy dual-stack: activate IPv6 in parallel with IPv4 on all servers, routers and critical services. Start with public-facing services (web, DNS, mail).
- checklist Update DNS: create AAAA records for all public services. Configure reverse DNS (PTR) for IPv6 addresses.
- checklist Monitor and validate: verify that IPv6 traffic flows correctly, that firewalls filter properly and that there are no security leaks.
EasyDataHost and IPv6
All EasyDataHost servers include native dual-stack IPv4 + IPv6 connectivity. Every dedicated server, VPS and cloud virtual machine receives at least a /64 IPv6 block, providing a virtually unlimited address space for each customer.
EasyDataHost's network supports IPv6 natively across all its interconnections, BGP sessions and peering points. Reverse DNS records (PTR) are automatically configured for assigned IPv6 addresses, and the managed services team assists with firewall configuration, AAAA records and dual-stack migration.
- check_circle Native dual-stack: IPv4 + IPv6 on all servers at no additional cost.
- check_circle /64 block per server: 2^64 IPv6 addresses per machine.
- check_circle Automatic reverse DNS: PTR records configured for both IPv4 and IPv6.
- check_circle Migration support: assistance with IPv6 firewall configuration, AAAA records and dual-stack transition.
Conclusion
IPv4 exhaustion is not a future problem: it is a present reality that makes public IPs more expensive, forces increasingly complex NAT solutions and limits the Internet's capacity to grow. IPv6 is the definitive solution, with a virtually infinite address space and an architecture designed for the end-to-end connectivity that the Internet requires.
- arrow_right IPv4 is exhausted: IANA in 2011, RIPE in 2019. Public IPs are a scarce and expensive resource.
- arrow_right IPv6 offers 128 bits: virtually unlimited addresses and end-to-end connectivity without NAT.
- arrow_right Dual-stack is the recommended strategy: IPv4 and IPv6 coexist during the transition.
- arrow_right IPv6 security depends on stateful firewalls, not NAT. Do not block ICMPv6.
- arrow_right EasyDataHost offers native dual-stack with a /64 IPv6 block on all servers.
If you need to enable IPv6 on your infrastructure or plan a dual-stack transition, contact our team to help you design a migration plan tailored to your requirements.