NAT: How the Legacy of the Old Internet Hinders the Future

Why NAT Was Needed in the First Place

IPv4 was designed in an era when computers were considered a luxury. With a 32-bit address space, the protocol provided approximately 4.3 billion IP addresses. However, by the 1990s it became clear this wasn't enough, as every device — from smart speakers to smartwatches — requires its own address.

NAT (Network Address Translation) emerged as a temporary solution to conserve the limited pool of IPv4 addresses. The technology allows multiple devices on a local network to share a single public IP address. Each device inside the network is assigned a private address from reserved ranges (RFC 1918), which are not routed on the global internet. The router translates internal addresses and port numbers into one external address, allowing hundreds of clients to share a single public IP.

This solution saved addresses and simplified routing, since the external network only saw one address while internal devices remained hidden. This approach proved critically important for internet growth in the 1990s and 2000s. However, the workaround became the de facto standard: most networks continue to operate through NAT even with IPv6 support, guided by inertia and the principle of "if it works, don't touch it."

The Dark Side of Workarounds

Double NAT — a situation where two levels of address translation overlap (for example, a home router connected to an ISP modem operating in NAT mode) — causes serious problems. Online games, voice chats, and P2P applications begin functioning intermittently. The IP address is hidden behind a double mask, preventing direct connections to servers. Users receive a "hard" NAT type, resulting in unstable connections with increased latency.

CGNAT (Carrier-Grade NAT) at the provider level is even more problematic. This technology distributes a single public IP among hundreds or thousands of subscribers, allowing providers to save addresses. The result: it's impossible to host a service (ports don't belong to the user), geolocation services give incorrect results, and VoIP calls lose stability.

Regarding security: many consider NAT a protective mechanism that hides devices. In reality, this is an "illusion of security." NAT doesn't encrypt traffic, doesn't authenticate users, and doesn't prevent application-layer attacks. It only masks IP addresses.

IoT devices are especially vulnerable. Connected behind CGNAT and lacking their own security mechanisms, they can be hijacked and used to create powerful botnets capable of launching massive DDoS attacks.

IPv6: The Transition Doesn't Happen with a Click

IPv6 promised an internet without tricks: a unique address for every device, no NAT, direct routing. Reality is different. In 2025, only about 40% of hosts globally can operate on IPv6. In Russia, the situation is worse: only about 10% of users have the ability to connect natively via IPv6.

Although most modern devices and operating systems have supported IPv6 for years, the key barrier is provider inertia. Many ISPs, especially regional ones, are in no hurry to implement IPv6, preferring to conserve resources and use NAT to extend IPv4's lifespan. Upgrading infrastructure, replacing routers, and training staff require significant investment with no direct incentives.

Even when providers offer IPv6, half-measures are common: home routers contain bugs in ICMPv6 processing or packet fragmentation, and firewalls incorrectly filter traffic.

The main brake is the enormous amount of legacy content and services without IPv6 versions. Tens of billions of devices (IoT, industrial systems, old servers) and thousands of web services operate only on IPv4. This forces maintaining dual-stack networks and renting expensive IPv4 addresses, sustaining demand and slowing the abandonment of the old protocol.

Major players — Google, Cloudflare — transitioned to IPv6 long ago, reducing latency and simplifying routing. Asia has reached 50% IPv6 capability thanks to active investment and government initiatives.

Between Two Worlds: Hybrid Solutions

Dual-stack support requires every router, server, and device to "speak" both protocols, duplicating configurations, monitoring, logging, and administration.

At European cloud providers, renting one IPv4 address costs up to €3 monthly (floating) or €0.50 (static), while IPv6 is allocated for free or €1 per /64 subnet. IPv4 costs 3-10 times more than IPv6.

DS-Lite (Dual-Stack Lite) encapsulates IPv4 packets in an IPv6 tunnel and performs centralized Carrier-Grade NAT on the provider side (AFTR), while the CPE device (B4) only tunnels. Advantages: no need to allocate a public IPv4 to each subscriber. Disadvantages: 40-byte overhead per tunnel (MTU issues), no multicast support, dependence on AFTR stability.

NAT64/DNS64 is the standard for mobile operators. DNS64 synthesizes AAAA records for IPv6 clients based on A records from legacy services; NAT64 on the border router translates IPv6 packets to IPv4 and back. Advantages: IPv6-only hosts gain access to most IPv4 services without tunnels. Disadvantages: doesn't work with protocols containing IPv4 literals in the payload (SIP, FTP without ALG), requires precise MTU configuration.

464XLAT extends NAT64: on the client (CLAT), stateless SIIT (RFC 6145) converts IPv4 traffic to IPv6; on the provider side (PLAT), stateful NAT64 (RFC 6146) converts back to IPv4. Advantages: supports applications bound to IPv4 sockets; actively used in mobile networks (3GPP). Disadvantages: double translation adds latency, harder to debug in enterprise networks.

The Path to Pure IPv6

For a provider, the first step is registering their own IPv6 prefixes in BGP for global routing. Then implementing automatic addressing: SLAAC (Stateless Address Autoconfiguration) or DHCPv6, so subscribers receive unique IPv6 addresses without manual configuration.

Proper organization of Router Advertisement (RA) for local networks and PDP (Packet Data Protocol) support for mobile clients is important. Security is built in at every stage: RA filtering, protection against rogue DHCPv6, IPv6 firewall configuration. Equipment and software updates are critically important, otherwise some subscribers will be left behind.

For developers, next-generation applications must be natively ready for IPv6: no hardcoded IPv4 addresses, only universal calls, IPv6 socket support, and proper socket.bind() implementation for dual-stack or IPv6-only. WebSockets, REST APIs, and peer-to-peer must work in an environment where IPv4 is unavailable. Testing on IPv6-only test benches and using modern libraries supporting both protocols is necessary.

Users can check their IPv6 readiness in a few minutes:

1. Verify that your provider supports IPv6 (for example, via test-ipv6.com)
2. Access your router's web interface (usually 192.168.0.1 or 192.168.1.1) and enable IPv6 in settings with a single toggle
3. Choose connection type: Native for native IPv6 or tunneling (6to4, 6in4) if your provider doesn't support it
4. Verify that devices receive global IPv6 addresses and have access to IPv6 sites (ipv6.google.com)
5. If problems arise, update router firmware or contact your provider

In modern routers (TP-Link, ASUS, Netgear, Huawei, etc.), setup is as simple as possible with instructions from manufacturers and operators.

Looking to the Future: IPv6-Only and the Decentralized Network

The transition to IPv6-only will eliminate the NAT barrier and restore the internet's true end-to-end architecture. In such clean networks, every node receives a global address and can initiate a direct connection without CGNAT or port forwarding. This will open the door to WebRTC peering without TURN servers, stable P2P applications, and mesh services based on BATMAN or Babel, where every router has a "sticky" address and participates in equal exchange.

Leaders in IPv6 traffic share — Saudi Arabia (65.5%) and Japan (57.7%) — where operators enable IPv6 by default and have abandoned CGNAT. These countries have recorded a twofold reduction in latency in P2P scenarios and a complete abandonment of complex overlay solutions for multicast.

Key technologies of the future are already built into IPv6:

SLAAC + CGA allow nodes to auto-configure and prove address ownership through cryptographic keys, which is important for decentralized PKI and secure addressing.

Secure Neighbor Discovery (SEND) protects against ARP spoofing and rogue announcements, ensuring authentication of Neighbor Discovery messages at the hardware level.

If by 2030, 60-70% of new IoT devices end up on IPv6-only networks, there will be an explosive growth of distributed systems: edge computing clusters, blockchains without central nodes, and P2P storage with native encryption at the network level. It's important to adapt security systems in advance: scale DDoS protection, update IDS/IPS for ICMPv6 and SEND support, and automate IPv6 ACL auditing.