Network address translation let the internet keep growing after IPv4 addresses ran short, but it also broke the assumption that any machine could talk directly to any other. That trade-off still shapes debates about who controls online infrastructure.
Key takeaways
- Network address translation, usually shortened to NAT, allows many devices behind a single public IP address to share that address when reaching the wider internet.
- NAT was adopted widely as a practical response to the limited size of the IPv4 address space, not as a deliberate redesign of the internet’s architecture.
- Because devices behind NAT are not directly reachable from outside, peer-to-peer connections generally require a third party to help set them up.
- Critics argue that this dependence on intermediaries pushed ordinary users into the role of clients and made large centralised services the default place where connections meet.
- Defenders of NAT point out that it kept IPv4 usable for decades and that centralisation has commercial and social causes that have little to do with addressing.
What is actually being discussed
The discussion concerns a piece of plumbing most internet users never see. Every device that speaks the internet protocol needs an address. In the older and still dominant version of the protocol, IPv4, those addresses are drawn from a fixed and comparatively small pool. NAT is the technique that lets a home or office network use a set of private addresses internally while presenting a single public address to the outside world. A router rewrites the address and port information on packets as they pass through, keeping a table of which internal conversation corresponds to which outward-facing port.
The consequence that matters for the argument is asymmetry. A device behind NAT can start a conversation with a server on the public internet, because the router creates a table entry when the outbound packet leaves and knows where to send the reply. A machine elsewhere on the internet cannot simply start a conversation with that device, because there is no entry telling the router where an unsolicited packet should go. Connections in one direction are easy; connections in the other are not.
The phrase “original sin” is a framing used by critics rather than a technical term. It expresses the claim that a workaround adopted for one problem quietly changed the character of the network, and that the change was never fully examined because the workaround was so useful.
Why the topic is circulating now
Arguments about NAT surface periodically rather than in response to a single event. They tend to be prompted by broader unease about the concentration of internet infrastructure: dependence on a small number of cloud providers, content delivery networks and platform intermediaries, and the visible effects when one of them has an outage. When people look for structural explanations rather than commercial ones, addressing and reachability are among the first places they look.
Interest is also sustained by the slow, uneven progress of IPv6, the successor protocol with a vastly larger address space that in principle removes the scarcity that made NAT necessary. Adoption has advanced over many years but has not displaced IPv4, and the mixed environment that results keeps the practical problems of reachability alive. The specific occasion for the current round of discussion is not something that can be verified from the signal itself.
The background a newcomer needs
The early internet was built around the idea that every connected host had a globally unique address and could, in principle, exchange packets with every other host. Applications were written on that assumption. Protocols for file transfer, real-time voice and direct messaging often expected either end to be able to open a connection.
As the number of connected devices grew, the IPv4 address pool proved too small to give every device its own public address. Several responses were pursued in parallel: more efficient allocation of existing addresses, private address ranges reserved for internal use, NAT to bridge between them, and the design of IPv6 as a long-term replacement. NAT spread quickly because it worked immediately, required no coordination beyond the local network, and could be built into consumer routers.
Over time, the workarounds for NAT became their own layer of engineering. Techniques exist to punch holes through NAT devices, to relay traffic through an intermediate server when hole-punching fails, and to negotiate which method a given pair of endpoints should use. These are standard components of real-time communication systems today. They work, but they add complexity and, crucially, they usually require a server that both endpoints can reach.
Who is affected and in what way
Ordinary users are affected mostly in ways they do not notice. Services are designed around the assumption that the user’s device cannot be reached directly, so applications poll or hold open connections to a central server. Anyone who has tried to run a small service from a home connection, host a game for friends or expose a device on a home network to the outside has met the friction directly, typically through port forwarding configuration or a hosted tunnelling service.
Developers of peer-to-peer, real-time or decentralised software are affected most sharply. Building such systems means building or renting the signalling and relay infrastructure that NAT makes necessary, which is an ongoing cost and a point of dependence. Small projects often find it easier to route everything through a central service.
Network operators face a different set of pressures. Carrier-grade NAT, where an internet provider places many subscribers behind shared public addresses, extends the same technique further up the network and reduces reachability further, while easing address scarcity for the operator. Its use varies by operator and region and is not something that can be summarised with a single figure.
Where informed people disagree
There is genuine disagreement about causation. One view holds that NAT is a structural cause of centralisation: by making users unreachable, it made them clients by default, and the client-server pattern then became the natural business shape of the web. On this reading, restoring end-to-end reachability would remove a barrier to decentralised alternatives.
The opposing view holds that this overstates a technical detail. Centralisation, on this account, is driven by economics: scale advantages, the cost and difficulty of running reliable services, the convenience of managed platforms, and network effects among users. Home connections are typically asymmetric in bandwidth and unreliable in uptime, and most people do not want to administer a server. Give everyone a public address, this argument runs, and most would still use hosted services.
A third position treats NAT as neither cause nor coincidence but as one factor among several that reinforced each other. There is also disagreement about security. NAT is sometimes described as a firewall, which it is not, though its side effect of blocking unsolicited inbound traffic has been widely treated as a security benefit. Some argue this has encouraged weaker host security; others regard the default of not being reachable as valuable regardless of how it arose.
What follows in practice
For engineering teams, the practical implication is that any design involving direct device-to-device communication should assume NAT traversal will be needed and budget for the infrastructure it requires. For anyone assessing decentralisation claims, it is worth asking where the coordination servers are, because a system can be decentralised in its data flows while depending on a small number of well-known rendezvous points.
For users, the implications are modest but real: the difficulty of self-hosting is partly a matter of addressing rather than of software, and services that promise to expose a home device to the internet are usually solving a reachability problem rather than a computing one.
What to watch next
The clearest thing to follow is IPv6 deployment, particularly on mobile and residential networks, and whether wider availability of end-to-end addressing changes what applications are built. A second is the evolution of NAT traversal and tunnelling tools, which are increasingly packaged as products rather than assembled by hand. A third is regulatory and policy attention to infrastructure concentration, which so far has focused on platforms and cloud services rather than on addressing. Whether the technical layer enters that conversation is not yet clear.
Frequently asked questions
What does NAT actually do?
Network address translation allows several devices on a private network to share one public internet address. A router rewrites the source address and port on outgoing packets and records the mapping, so that when a reply arrives it can be sent back to the right internal device. This lets a household or office with many devices operate behind a single address obtained from an internet provider.
Why was NAT introduced in the first place?
It was a practical response to address scarcity. The IPv4 address space is fixed and finite, and as connected devices multiplied there were not enough public addresses to assign one to each. NAT allowed existing addresses to serve many more devices without changing anything outside the local network, which made it easy to deploy and helped IPv4 remain workable for far longer than expected.
Does NAT cause internet centralisation?
That is exactly what is disputed. NAT makes devices behind it hard to reach directly, which pushes applications towards central servers that both sides can contact. Critics see this as a structural driver of centralisation. Others argue that economics, reliability and convenience explain the concentration of services far better, and that removing NAT would not by itself change how most people use the internet.
Is NAT the same thing as a firewall?
No. A firewall applies a policy about which traffic is allowed. NAT translates addresses, and blocking unsolicited inbound traffic is a side effect of not having a mapping for it rather than an enforced rule. In practice the side effect has often been relied on as protection, but it is not a substitute for a firewall or for securing the devices on a network.
Does IPv6 remove the need for NAT?
IPv6 provides enough addresses that scarcity is no longer the reason to use NAT, so devices can in principle have globally reachable addresses. Reachability still depends on firewall policy, which commonly blocks unsolicited inbound connections by default. IPv6 also has to coexist with IPv4 for as long as IPv4 remains in use, so NAT and its workarounds persist in mixed environments.
What is NAT traversal?
NAT traversal refers to the techniques applications use to establish direct connections between devices that both sit behind NAT. These typically involve a server that both endpoints can reach, which helps them discover their external addresses and coordinate an attempt to connect. If a direct connection cannot be established, traffic is usually relayed through an intermediate server instead.
Sources and further reading
- Internet Engineering Task Force: published specifications describing address translation, private address ranges and NAT traversal methods.
- Internet Society: explanatory material on IPv6 deployment and the transition away from IPv4-only networks.
- Regional internet registries: general documentation on how address space is allocated and why IPv4 became scarce.
- Technical discussion forums and engineering blogs: the setting in which the “original sin” framing and the counterarguments to it are debated.
Surfaced from the hackernews signal “debate on network address translation”. AI-assisted draft, editorially reviewed.
