title: "Internet centralization and the original sin of NAT"
url: "https://dreamstation.systems/personal/ntppost.html"

File Transfer, Randall Munroe, https://xkcd.com/949, Creative Commons Attribution-NonCommercial 2.5

In this comic, the concept of an ordinary person having an FTP server is quickly dismissed. And yes, it’s not common. To the average computer user, the idea that someone could just… connect to your computer feels exotic, or even dangerous — see the very common ironic fear of your IP address being known to other people on the internet.

If you take someone who’s “good with computers” but not a networking person, their mental model of The Internet probably involves a definition of “servers” or “the cloud” that distinguishes them from personal computers in some meaningful way. True peer‐to‐peer, if they ever think about it, is an endeavor: WebRTC, STUN, TURN, ICE, what have you. Given that we live in a world of NAT, CGNAT, and restrictive ISPs, this isn’t entirely wrong, but it breaks the elegant design of the original Internet.

Why you don’t have an FTP server

Network address translation (NAT) was first formally proposed in RFC 1631 in 1994. In its abstract, it says:

The two most compelling problems facing the IP Internet are IP address depletion and scaling in routing. Long‐term and short‐term solutions to these problems are being developed. The short‐term solution is CIDR (Classless InterDomain Routing). The long‐term solutions consist of various proposals for new internet protocols with larger addresses.

Classless interdomain routing is not the point of this post, but basically we started giving people more options for network sizes, and while complex in implementation, it was philosophically virtually uncontroversial.

RFC 1631 proposed a second short‐term solution to IP address depletion and scaling in routing: NAT. While it is not exactly the same type of NAT omnipresent on home routers today, the basic idea is the same: it allows multiple devices to share an IP address (from the perspective of a device on the other end of a routing device) by modifying the network address information in the IP packet headers while transferring the packet across a traffic routing device. We then later reserved certain addresses for private use, and these things are used in conjunction on most IP networks — private addresses within the network, NATing to one public address at the router. On your typical home router, here’s how you usually connect to an external server with NAT 1:

1. Your computer sends a packet like this:

   | Source IP | 10.11.70.21 |
   | Source Port | 50413 |
   | Destination IP | 67.215.249.229 |
   | Destination Port | 70 |

2. It hits your router, and it modifies it to this:

   | Source IP | 146.7.15.85 |
   | Source Port | 60612 |
   | Destination IP | 67.215.249.229 |
   | Destination Port | 70 |

3. The server replies:

   | Destination IP | 146.7.15.85 |
   | Destination Port | 60612 |

4. Your router rewrites it back:

   | Destination IP | 10.11.70.21 |
   | Destination Port | 50413 |

If you’ve thought this through, you might be asking: in the situation that an external server wants to talk to you first, how does that happen? It sends a packet to 146.7.15.85, and your router…

Oh no. It has no idea where to send it.

Working around it

Naturally, people noticed this was a problem almost immediately, because people have wanted to run game servers, FTP servers, and web servers from their bedrooms since roughly the beginning of time. So a whole ecosystem of workarounds grew up around NAT, none of which restore the fundamental intention of the internet, and none of which work for everything.

Port forwarding

The most direct fix is to just tell your router “hey, when a packet comes in on port 60612, send it to 10.11.70.21 on port 50413, no questions asked.” This is port forwarding, and it’s the workaround to NAT that the most people are aware of. One of the problems with port forwarding, conceptually, is that one public IP+port can still only map to one device at a time, which means that two devices can’t operate a service on the same public IP+port at the same time. This is more of a problem than it sounds like; on big enterprise or university networks that choke down to a small number or even just one private IP, this basically kills on‐prem hosting without doing even more complicated shit. And sometimes, your ISP has put your external IP behind NAT too — which is called carrier‐grade NAT (CGNAT) — and now you don’t control the device doing the translation, so you can’t forward a port. You’re getting a fraction of a fraction of an IP address.

Also, another problem with NAT is that nobody wants to bother with it, which is why we invented:

UPnP

UPnP, and its modern cousins NAT‐PMP and PCP, tried to solve the “nobody wants to bother with it” problem by letting software ask the router directly to forward ports. Like manual port forwarding, it’s a request to your router — if your ISP is screwing with you, you’re out of luck. It’s also frequently disabled because of misguided security thinking — partially because of a couple buggy early implementations, and partially because the idea that someone could just connect to your computer feels exotic or even dangerous to a lot of people. There are plenty of valid reasons to want a firewall, but if you do, intentionally implement one instead of relying on NAT just not knowing where to send packets.

STUN, TURN, and ICE

STUN

Session Traversal Utilities for NAT (STUN), instead of trying to get cooperation from the firewall, simply asks a server on the public internet “what does my packet look like by the time it gets to you?” The STUN server hands back the public IP and port your NAT assigned, say, 146.7.15.85:60612. Under a “cone NAT”, where the router uses an identical external port mapping for all outbound connections, this works great. You can tell this mapping to a peer, and then they can send packets directly to you. This technique is known as hole punching. However, under a “symmetric NAT” — common on CGNAT and institutional networks — you get a different public port for every distinct destination. In this case, the STUN mapping is useless for connecting to a peer, since they'll see you differently than the STUN server..

TURN: giving up

Traversal Using Relays around NAT (TURN) is simply just passing traffic through a relay server, with both sides speaking to it outbound. This works mostly everywhere, but since someone has to run a server that should be unnecessary and you have to eat the added latency of every packet detouring through a third party, this really sucks.

ICE: trying everything

Interactive Connectivity Establishment (ICE) accepts that no technique is reliable and tries all of them in order of preference. Consider everything: direct connect, STUN‐discovered external address, a TURN relay), exchange the list with the other side, and throw shit at the wall until something works. This is what WebRTC does, and it’s the best you’ll get on today’s internet. But we’ve replaced a simple direct connection with, mostly, external infrastructure.

The long‐term solution that wasn’t

The principal “long-term solution” in the works that RFC 1631 was referring to was IPv6, and it was supposed to fix this; give everyone a real globally unique address and obviate NAT. However, the sigmoid function of IPv6 adoption seems to be stalling out too early, and even where it is implemented, many ISPs and institutional networks keep doing NATy stuff out of inertia and even more misguided security thinking: firewalls that refuse inbound because that’s we’re used to NAT doing that, or completely unnecessarily applying actual NAT to IPv6  — often deploying Unique Local Addresses (fc00::/7) the way they use private RFC1918 space on IPv4 — which is baffling to me.

The consequences for the Internet

There’s lots of things you can blame for killing the open Internet, but I think NAT was one of the earliest. Running a server used to be trivial: run an executable, tell people your address, done. Now, if you’re lucky, you probably have to configure port forwarding, which you often can’t even do if you’re behind CGNAT or on an institutional network.

It also trained everyone to think client‐server is natural. “My device talks to The Cloud which talks to other devices” feels normal, when that feeling originated as an artifact of address scarcity. The problem the people in the XKCD comic at the top are facing is the absurdity of trying to establish a one-to-one communication using only outbound connections on both sides. Even more ironic is that NAT got normalized as a security feature  — “your devices are hidden!” — which is one of the things that made people resist the thing that would fix it.

NAT certainly isn’t the only reason why the modern internet is full of centralized walled gardens, but it was the first — it’s why it’s hard to send a file to someone, it’s why you don’t run your email on your own computer, and why running your own services at all is difficult and often expensive (if you can’t port forward from your own internet connection, you have to buy a VPS instead of using hardware you already have).

Some day we'll just have to stop routing people who misuse our common protocols.

I already stopped caring about my IP being on blocklists because it only ever ends up on those for the dumbest reasons. If someone can't connect to me then it's their problem. I can't perform remote IT support for every person who bought a Unify firewall and clicked "block bad IPs".

I reckon in my life time I will also turn off IPv4 and just stop dealing with it's bullshit.

I hear a lot of chatter about CGNAT. How common is that? Anecdotally, I'll have to say, I've never encountered it... ever.

Like literally all mobile (4/5G) internet connections are behind CGNAT, as is Starlink for example.

For landline internet connections it is indeed uncommon.

If you're in the US, it's because all of the major ISPs siphoned up much of the ipv4 address space so they can still offer it to everyone.

In Australia, on the other hand, most ISPs provide CGNAT by default, although most of them offer a free opt-out and have ipv6. Mobile services are also typically CGNAT, although many offer ipv6 + 464XLAT (an ipv4 compatibility mode using ipv6).

In developing countries some sort of ipv6 solution is almost universal, particularly those with higher populations such as India, since it would cost an absurd amount of money to buy up that amount of ipv4 address space today.

You absolutely shouldn't be exposing service on your computer to the internet

Firewalls (not NAT) exist for a reason

All starlink residential service is behind cgnat. They have IPv6 but it’s not well documented.

When my ISP switched from cable to fiber this year I got put behind one.

I'll add some color to this post.

The original FTP is, frankly, a monster of a protocol. Very useful, but an anomalous protocol that even without NAT breaking the end-to-end principle, it is unlikely to have survived modern corporate firewall rulesets in any case. The fact that FTP was even ported for TCP is its own historical quirk.

BTW, that is the term which this post is missing: the end-to-end principle is the design philosophy that the network itself should not have to perform work on payloads transmitted, except to carry it towards the destination. This also implies that no fields or bits should be modified in transit, once it leaves the sender; encap/decap restores the fields so that the receiver is none the wiser.

NAT breaks end-to-end in two respects: corruption of the original sender, and corruption of L4 port numbers. Note that Legacy IP also violated end-to-end, when packets are fragmented due to MTU issues. With IPv6, fragmentation by the network is disallowed outright, and the technical case for NAT is non-existent.

There's something to be said about adopters of NAT, that they were facing a Hobson's choice: use NAT so that they could connect early dial-up users to the emerging Internet, or reinvent the 20 year experiment of the Internet so that it could scale properly. In 1995, IPv6 did not exist so they made the only real choice available.

In the year 2026 though, that argument doesn't hold water: it is a choice to continue to ignore the dual-stack and IPv6-only internet. There's a quote that all sufficiently complex technical problems are in-fact political, and this is that: the modern case for Legacy IP and NAT is rooted in inertia, resource scarcity (eg hyperscale cloud companies buying up IP subnets), and recalcitrance by professionals that abdicate their responsibility to their clients to pursue the available technology.

There is no colorable technical rationale for why IPv6 best practices cannot be adopted today for most organizations, when all network hardware, all major consumer and enterprise OS's, and all mobile phones support v6. Note that I said "best practices", because a minority of orgs such as certain American ISPs have undertaken truly bonkers decisions that are putting us on track for the very same sins as Legacy IP.

The fact that some ISPs assign nothing but a single /128 via DHCP6 is absurd: this malpractice perpetuates the same problem as NAT44, except that there's no good excuse for it. Even the most delusional of ISPs will never run out of /128 addresses in their assigned /32. Per best practice, even handing out /48's to customers is not a problem either, because that's 65536 customers and if that's really a problem, just ask the RIR for another /32, which they can do as RIR dues-paying members. There is no practical limit, except that some people just cannot math properly to see that there's no practical limit. When a technical solution to a technical problem fails because of innumeracy by those tasked with implementing it, then that's so much worse than any 1990s workaround.

I've harped a lot about IPv6 because its strength today is that it's technically competent, future-proofed, and most importantly, practitioners that saw the first travesty of NAT will not allow a redux to play out with IPv6. The technical reasons to deploy NAT66 are non-existent: it is always a workaround for political issues.

I can (just barely) accept NPTv6 as a like subnet-for-subnet mapping that does not harm L4, but that's still glossing over a political issue. IPv6 gave network engineers real choices in numbers and administering their networks, and while some will squander it, I will be encouraging people to not let that happen.

Starlink has supported IPv6 for years. You have to put their router in bypass mode and connect your own to open ports in the firewall though. They delegate a /56 prefix and it's stable. Mine hasn't changed in over 3 years. Since my cell carrier also provides IPv6, I can access my SFTP server remotely without dealing with any NAT.

I'm in the US and my ISP gives everyone CGNAT by default. On the lower tier plans, we have the option to buy a semi-static IP for an extra fee. The higher tier plans include the semi-static IP for free upon request.

I have also been talking with them about IPv6. They will only grant customers a /64 prefix because their pool of v6 addresses is so small, they would run out of their allocation if they granted customers a /60.

By only giving customers a single /64 I cannot implement v6 on my VLANs. This is incredibly frustrating considering v6 has like so many addresses it's not even like a number most people know. Like a trillion trillion or whatever. And you're telling me I can only have one (subnet)?

Ford has the entire 19.x.x.x ip address space, Benz has all of 53.x.x.x

Why?

Early adopters. I work at a university that owns multiple /24 blocks (and probably an entire /16, but no concrete evidence) because they were assigned during the internet's infancy.

Some ISPs in India provide dynamic public IP, which is way better than CGNAT. You just need to run a DDNS client on your router.

Yes, I am aware. But that is not very helpful if you want to host something publicly or even just want it accessible from the random wifi hotspot you might use that more likely than not is IPv4 only.

I believe the smallest range you can announce over BGP is a /24. So it's not really anything special (I'm even authorised to use one), a /16 is less common these days though.

Classless interdomain routing is not the point of this post, but basically we started giving people more options for network sizes, and while complex in implementation, it was philosophically virtually uncontroversial.

You're talking about 2 different things here. Bit masking part of what is now CIDR was implementable since the mid 90s on network segments, it's the logic to route packets based on CIDR that was integrated into RIP, GRIP, and BGP.

Also, CIDR can't alleviate multi-hop routing address exhaustion.

NAT is not a firewall (as you mention) but the premise that it should be trivial to run an internet connected service isn’t realistic when there are so many bad actors on the network

People think hosting their own services is unsafe are correct for them because they don't know how the internet works or anything.

This was an extremely interesting and informative read. I have been fascinated by computer networks and recently started reading about them. I was surprised that I was able to understand almost the entirety of the article despite my limited knowledge of networks.

Are there recommendations for textbooks or resources that explain computer networks in a manner similar to that of this article?

I am one of few people who runs a proper dual-stack with a single static IPv4 and a static IPv6 subnet.

Nevertheless I also participate in experimental network overlays like https://yggdrasil-network.github.io/ and distributed storage like IPFS.

In the same way that the XKCD hand-waved FTP, this article hand-waves the idea that we shouldn't be concerned about who can access our self-hosted services.

I'm not saying it's wrong, but I'd like more of an explanation on why we shouldn't be concerned about allowing anybody on the internet having direct communication with our computers.

I read "Networking for Dummies" in 2005, and it gave me a GREAT baseline understanding. I don't recall how much it discussed ipv6 at that time, but I imagine the newer editions cover it.

it presents firewalls like some useless burden, I don't get how can one see it like that in this age

Saw the title and I already knew IPv6 was still gonna be "not enough adoption" lol.

The overly aggressive lockdown from NAT is not entirely misplaced though. Windows is already notorious for default hosting an atrocious level of protocols that are anywhere between "I can get your NetNTLMv2 hash for free" to "gg ez RCE as SYSTEM user".

Linux and Unix were also not magically protected either, like every FTP server implementation has had several RCE vulns and it was so bad that Linus himself pointed out how easy it was to abuse buffer overflow vulns even after the addition of NX mem protection with return to libc, several years before ASLR finally landed in Linux and Windows.

Seriously, the early 2000s was the wild west of vulns because everything was still written in C++ so you could just waltz into any binary, find some stack/heap overflow, and you're on your way to an RCE.

NAT (and firewall) most definitely did prevent millions of users from getting rekt by a metric ton of malware that operated on the ability to connect to those services.

They will only grant customers a /64 prefix because their pool of v6 addresses is so small, they would run out of their allocation if they granted customers a /60.

This is an absurd excuse, IPv6 blocks are cheap. buy more.

https://www.arin.net/resources/fees/fee_schedule/

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:

[Thread #94 for this comm, first seen 2nd Sep 2026, 22:50]
[FAQ] [Full list] [Contact] [Source code]

@mlg @leanleft otoh, it could be argued that widespread usage of NATs kept people from actually hardening their software stacks. For servers, admins moved from hole-ridden garbage like sendmail to stuff that was designed with security in mind like postfix. However, for desktop software and home stuff, there was never much of a need, so a lot of the biggest companies have cultures of extremely sloppy security practices in shipped software. And it's slated to get worse with AI adoption...

As usual, nuances have layers.
Security is not just 1 layer and done.
So just saying fuck it, no security at all, the program is the single layer is, IMHO, a bit misguided.

Sure nooe is focussing on OS security if all is behind a NAT anyway. Cause and effect might be reversed here. Also since basicall, every server is running linux today, this cannot be so bad, right?

This and the comment it replies to make the categorical error which is to assume that NAT exists as part-and-parcel to firewalling. This is not the case. Many American university and corporate networks do still adhere to the end-to-end principle by giving every device a public IP address. They can do this because they are among the few legacy entities that actually have enough for their needs, such as a Class A (aka /8) subnet on Legacy IP. At the same time, these entities employ firewalls that don't allow unsolicited inbound traffic (and sometimes also block disallowed outbound traffic).

NAT is not a firewall, and the OP correctly points out that by using NAT or CGNAT, the end to end principle is demolished, with no way for the victims to recover. OP mentions "firewalls" exactly twice, to compare how they are not firewalls and are still necessary in spite of NAT. Nobody is credibly suggesting that everyone should switch to IPv6 without a firewall. Every single domestic router for the past two decades has included a firewall, and that would not change in an all IPv6 world.

I wish to reiterate an example I've used in the past, which is that the most famous address in the USA is 1600 Pennsylvania Ave, Washington DC. Anyone can send letters and parcels directly to this address as-written, with no need to rewrite the address to first arrive at the Secret Service. And yet, all such parcels and letters will be thoroughly scrutinized by the Secret Service anyway at an off-site facility, and some indeed will be let through to the occupants of the residence. NAT is address mutilation, and the United States Postal Service does not require nor allow that.

Nobody is credibly suggesting that everyone should switch to IPv6 without a firewall.

OP writes:

many ISPs and institutional networks keep doing NATy stuff out of inertia and even more misguided security thinking: firewalls that refuse inbound

Every single domestic router for the past two decades has included a firewall, and that would not change in an all IPv6 world.

my ISP router does not have firewall settings, despite supporting IPv6. it has a DMZ setting, able to forward all incoming traffic to a specific internal IP, and that's it. I have a similar experience with cheap consumer routers too.

My comment, which you refer to, said nothing about NAT -or- firewalls. Rather, it's a direct response to the second sentence in the article's opening paragraph: "To the average computer user, the idea that someone could just… connect to your computer feels exotic, or even dangerous..."

You may be correct that nobody would recommend implementing IPv6 without a firewall. But this article avoids the subject of firewalls completely, which in combination with that opening paragraph leaves the distinct impression that we shouldn't be concerned about it because that's the way the internet was meant to be.

Of course this has nothing to do with NAT or IPv6, and the value of IPv6 can't be overstated. But to ignore the security part of the equation is going to have one of two effects: 1) people who don't know better will think they can use IPv6 without a firewall, or 2) people who understand the risks will be skeptical of the claims that IPv6 is better because you are leaving out an important part of the equation.

Depends