IPv6: A Better World Without NAT

Frequent CAPTCHAs, a location that is reported in the wrong city, game consoles that display “Strict NAT,” and self-hosted services that cannot be reached from outside the home are commonly regarded as unrelated annoyances. In many cases, however, the same cause lies behind all of them: Network Address Translation (NAT).

Why NAT Exists and What It Costs

The Internet Protocol version 4 (IPv4) was standardized in 1981 with 32-bit addresses, allowing for roughly 4.3 billion unique addresses. At the time, this number was considered more than sufficient. However, by the early 1990s, the rapid growth of the Internet made it clear that the available address space would eventually be exhausted.

Network Address Translation (NAT) was proposed as a short-term solution to this problem. It was described in RFC 1631 in 1994 and was intended to be used until a permanent replacement became available. NAT allowed many devices on a private network to share a single public IP address, reducing the number of public IPv4 addresses required. Private address ranges, reserved by RFC 1918 (such as 192.168.0.0/16 and 10.0.0.0/8), could be used inside a network, while the router translated these addresses into a public address when communicating with the Internet.

Because many devices could share the same public address, the router also needed a way to distinguish their connections. It did this by translating port numbers as well as IP addresses and keeping a table of active connections. This form of NAT, commonly called Port Address Translation (PAT), is what is used in most home networks. The router uses this table to make sure that replies from the Internet are returned to the correct device.

However, this solution came with an important trade-off. A device behind NAT could easily initiate a connection to the Internet, but an outside device could not normally initiate a connection back to it. In other words, the device was no longer directly reachable from the Internet. Applications that depended on direct connections between devices therefore needed additional techniques to work around NAT.

Despite this limitation, NAT worked well enough to reduce the immediate pressure on IPv4 addresses. This helped delay the need for a permanent replacement. IPv6, which provides a vastly larger address space, was standardized in the late 1990s, but adoption remained slow, partly because NAT made it possible to continue using IPv4 with fewer public addresses. The shortage had not been solved; its effects had simply been postponed.

Eventually, the global pool of unallocated IPv4 addresses was depleted. IANA allocated its final blocks in 2011, and the regional Internet registries later reached their own exhaustion points or were left with limited reserves. Internet service providers then faced a problem of their own: they could no longer obtain enough public IPv4 addresses to give every customer a unique address.

The solution was Carrier-Grade NAT (CGNAT), which took the original idea of address sharing one step further. Instead of giving each customer a unique public IP address, an ISP could place many customers behind the same public address. A special address range, 100.64.0.0/10, was reserved for this purpose by RFC 6598. It is used between the customer’s router and the provider’s CGNAT equipment.

CGNAT introduced new costs for Internet service providers. When many customers share the same public IP address, the provider must be able to determine which customer was using that address at a particular time. This can require recording the public IP address, port information, and timestamps for connections. The resulting data can be very large, creating additional storage, processing, and operational costs while also raising privacy concerns. The CGNAT equipment itself requires additional infrastructure and maintenance and becomes another point of failure. If too many customers compete for the available ports on a shared public IP address, port exhaustion can also cause connections to fail.

The effects are also visible to users. Because many customers share the same public IP address, users may experience frequent CAPTCHAs, since the reputation of everyone behind the address is affected by the behavior of the others. Websites may also report a location in the wrong city, because the address points to the provider’s equipment instead of the user’s home. In addition, incoming connections are usually blocked, and users often cannot change this themselves.

There is also a significant cost for application developers. Since many users can appear to come from the same IP address, an IP address can no longer reliably represent a single user. This complicates rate limiting, abuse detection, and IP-based blocking, because the activity of one user can affect other users sharing the same address. Applications that require direct communication between users may also need additional technologies such as STUN, TURN, and ICE to establish connections through NAT. These workarounds can require additional servers and development effort and may sometimes introduce extra latency.

The cost of NAT therefore extends beyond translating addresses. What began as a way to conserve IPv4 addresses created a chain of requirements: routers maintain translation state, ISPs operate large-scale translation systems, developers build workarounds for limited connectivity, and users share the identity and reputation of a public address with others. NAT did not eliminate the IPv4 shortage; it changed where the cost of that shortage is paid.

Introduced in the 1990s as a temporary solution, NAT has now been in use for more than three decades. It extended the life of IPv4, but it also helped delay the transition to IPv6, and the limitations and costs it introduced are spread across users, developers, and Internet service providers.

How an IPv6 Address Is Built

Every IP address is made of two parts: a network part, called the prefix, and a device part, called the suffix. A street address works in much the same way: the prefix corresponds to the street, which is shared by every house on it, and the suffix corresponds to the house number, which identifies one building on that street. Together they identify exactly one device.

The prefix is assigned by the internet service provider, while the suffix is chosen inside the network. The length of the prefix is written with a slash, in a notation known as CIDR: in 2001:db8:1234:5678::/64, the number 64 indicates that the first 64 bits of the address belong to the network.

This division is not new. IPv4 uses the same structure, and a home network such as 192.168.1.0/24 has a prefix (192.168.1) and device numbers (.1, .23, and so on). What differs is visibility. Because of NAT, the device numbers in IPv4 remain inside the home, and the internet sees only the router’s single public address. In IPv6, the address is not translated, so both parts are visible from outside. Instead of one public address per home, each home receives an entire prefix, commonly a /56 or /48, which contains enough room for every device to have its own address.

Two consequences follow, and both are examined in the sections below. The suffix can be changed freely by the device, and modern systems rotate it regularly for privacy. The prefix, however, usually stays the same, so it becomes the part of the address that identifies a household or an organization.

A Better World

Reachability is restored. Packets are delivered without being rewritten, so the address that a device uses is the same address that the other side sees. A device is therefore directly reachable again: connections can be initiated in either direction, subject only to the firewall policy that has been chosen. The translation table is no longer needed, and whether unsolicited inbound traffic is allowed becomes a firewall policy decision instead of a side effect of NAT.

Providers no longer need large-scale translation. Since an address or prefix belongs to a single customer, CGNAT equipment, port-block allocation, and port exhaustion are no longer part of the network. The very large connection logs that accompany shared addresses are also no longer required, because one customer maps to one prefix and the question of who used an address at a given moment is answered with a simple lookup.

Users regain their own identity and control. Reputation is no longer shared with strangers behind the same public address, so frequent CAPTCHAs caused by other users’ behavior are largely avoided. Geolocation is tied to the customer’s actual network instead of the provider’s gateway, although IPv6 geolocation databases are still maturing.

Incoming connections are no longer blocked as a side effect of translation, which makes self-hosting practical again. Self-hosting means running a service on equipment that is owned and controlled by the user, such as a home computer or a network storage device, instead of relying on a large company’s platform. Typical examples are a private photo library, a personal file store reachable from a phone, a media server, or a game server for friends. Under NAT, reaching such a service from outside the home requires port forwarding, and behind CGNAT it is impossible. With IPv6, access is controlled by a firewall rule that allows outside connections to one specific device and service. The same openness carries a responsibility: a reachable device must be kept updated and protected, and the firewall should remain closed by default.

Developers can remove the workarounds. The effect is most visible in peer-to-peer (P2P) applications, where two devices communicate directly instead of routing everything through a company’s servers. Video calls, online games, and file-sharing tools work this way. Behind NAT, a chain of workarounds is required: a STUN server reports each device’s public address, both devices send packets toward each other to create matching translation entries (hole punching), and, when that fails, all traffic is relayed through a TURN server. With IPv6, the address-discovery step provides no new information, translation entries are no longer needed, and relaying is avoided in the large majority of cases. The result is lower latency, better call and game quality, and lower infrastructure costs for the providers of such services.

With NAT

Without NAT

Two qualifications apply: a firewall may still require both sides to send traffic first, and TURN remains an occasional fallback for restrictive networks and for connections where one side is still IPv4-only.

Other workarounds, such as keepalive packets and application-layer gateways, can be removed as well, and troubleshooting is easier because the client address in logs is the real one from end to end. An address can also represent a single customer again, which makes rate limiting and blocking fairer than when many users appear behind one address, although the limits of this improvement are covered in the next section.

Networks become simpler to operate. With stateless address autoconfiguration (SLAAC), devices build their own addresses from the prefix advertised by the router, and renumbering a network after a change of provider is simpler. Overlapping private ranges, which cause problems when networks are merged or VPNs are connected, are avoided because addresses are globally unique.

In this sense, IPv6 does not add another layer to work around the shortage. It removes the shortage, and with it most of the machinery that was built to hide it.

The Limits

Removing NAT solves the problems that translation itself caused. It does not solve problems that were never caused by translation, and some of them are changed by IPv6 in ways that must be handled deliberately.

The size of the address space is not a security measure. It is sometimes claimed that IPv6 networks cannot be scanned because the space is too large. Brute-force scanning of a /64 is indeed impractical, but addresses can still be discovered through DNS, logs, certificate transparency data, predictable address patterns, and traffic observation. Obscurity should therefore not be relied upon, and protection should come from firewalls and patched software.

Reachability becomes a security decision. Unsolicited inbound traffic is blocked under NAT only as a side effect of the missing translation entry. When every device is globally reachable, that protection disappears unless it is replaced deliberately. A stateful firewall with a default-deny policy for inbound traffic provides the same protection, and most home routers enable it by default, but it must be confirmed and configured correctly. The security of individual devices, particularly IoT equipment that is rarely updated, also becomes more important, since direct reachability is possible from anywhere. Guidance on this subject is provided in RFC 4864.

The transition is uneven. IPv6 is not yet available on every network, so most services and users operate in a dual-stack arrangement in which both protocols are present. The benefits described above are fully realized only when both ends of a connection use IPv6, and some of the old problems, including CGNAT, remain for IPv4 traffic until the transition is complete. Providers also take on new tasks, such as managing prefix delegation and ensuring that customer equipment is configured correctly.

Prefixes become the unit of identity. As described earlier, every device in a home or office shares the same prefix, while the suffix identifies the individual device. Privacy extensions (RFC 4941), enabled by default on modern operating systems, cause the interface identifier to be randomized and rotated so that a single device cannot be tracked by its address alone. The prefix, however, typically remains stable, so a household or organization can still be recognized over time. The anonymity that was provided incidentally by sharing one IPv4 address among many users is therefore reduced, and trackers are able to key on the prefix instead. Some providers rotate delegated prefixes periodically, which reduces this effect.

Geolocation and reputation data are affected as well. The databases for IPv6 are less mature than their IPv4 counterparts, so some of the improvements in accuracy are still developing.

Address rotation is cheap, so rate limiting moves to the prefix level. A single /64 contains 2^64 addresses, and a device may use any of them without requesting anything from the provider. A script can bind each outgoing connection to a different address inside the same /64, at no cost and without a VPN. Limits or blocks applied to individual addresses are therefore ineffective, since the same client appears as an unlimited number of different ones.

The practical response is to aggregate addresses before counting them. A /64 is the usual unit for a single network, and wider aggregation, such as a /56 or /48, is applied where a customer may have been delegated several /64 networks. Tiered limits at several prefix lengths, combined with limits per provider or autonomous system, are commonly used. Two complications remain. The size of a customer’s allocation is not visible from the address itself, since delegation sizes differ between providers, so the correct aggregation level has to be estimated from observed behavior, routing data, or registry records. Additionally, an attacker who controls many separate prefixes, such as a botnet spread across many homes or a cloud provider that hands out many networks, cannot be stopped by IP-based limits alone.

The nature of the problem changes between the two protocols. In IPv4 behind CGNAT, the problem is sharing: many users appear behind one public address, so a block or a limit applied to that address may affect an unknown number of unrelated people. In IPv6, sharing is no longer necessary, because each customer has a prefix of their own, and a block applied to that prefix usually affects one household or one network. A different problem appears in its place: one user can appear as many addresses, because the interface identifier (the suffix) can be rotated freely inside the prefix. The first problem causes collateral damage, while the second makes evasion cheap, and the prefix-level aggregation described above is the response to it.

The improvement is therefore fairness, not precision. A single device or a single person still cannot be isolated by address, in IPv6 or in IPv4. For that purpose, something that is costly to change is required, such as an account, an API key, a session token, device attestation, or a challenge mechanism. IP-based limits remain a coarse first layer, and behavior-based detection and authentication remain the more accurate tools.

In summary, IPv6 removes the connectivity and sharing problems that translation created, while the identity, abuse, and security problems are shifted to new forms and remain the responsibility of operators and users.