Live data from Hacker News

Internet centralization and the original sin of NAT

dreamstation.systems

161–170 of 197 posts

Re: Internet centralization and the original sin of NAT

#161
post #76

Earlier quoted context omitted.

IPv6, in a way, takes the concept of a MAC address and puts it on steroids. This became evident to me when I learned about EUI-64 addresses. And then my brain melted when I learned that any interface can be assigned an arbitrary number of unique addresses with varying purposes or contexts because the address space is truly *that big*. When I consider that quality of IPv6’s design, it communicates to me an old and ide…

The 'why' behind all of these protocols and decisions is left out in favor of the cert exams. Being able to implement is usually what gets you paid. >mere fact that Layer 2 and Layer 3 addresses are distinct concepts. The logical separation between the ideas allows for a lot of flexibility, and there were some wrong answers on how scalable vs flexible things should be. Ethernet and IP beat the shit out of everything…

I am doing a little facepalm over the L2-L3 distinction, thanks for being gentle and thoughtful. Sometimes I interrogate how things are, imagine what another paradigm would look like, but always end up where I started... I see that and think, hm, maybe the design of networks as we know them are expressing some sort of structure in the Platonic space.

I took a course called “Introduction to Internet Architecture” back in 2017 with a wonderful professor. The course opened with a prompt, “What is communication?” We started with smoke signals and worked our way up the OSI layers (including voltage-level encodings on the wire). I remember drawing those layers and asking, “What problem is each layer trying to solve?”

Also that XKCD comic is a classic. Love it. I don’t see any value in overhauling the protocols of today. It seems like the future (or present) of networking is overlays. When this recent cert covered SDN, it really abstracted away everything I had just learned and I felt a little sad about it honestly - as if switch/router configuration would some day be ubiquitously software-defined, getting totally buried by the application layer and becoming almost apocryphal like assembly or machine code… something we know exists but rarely touch.

Re: Internet centralization and the original sin of NAT

#162

Sorry. I implemented the current NAT system in Linux. In particular, avoiding port reservation in favor of squishing more connections into one IP address, as long as the remote address allowed us to differentiate. This, in turn, means incoming traffic from a different address is unroutable. You no longer have a public endpoint . This is "poor man's firewall", but erodes our ability to have a server the way we used to…

What do you think is the best road to a decentralized net from here? Any specific solutions you like?

[dead]

Re: Internet centralization and the original sin of NAT

#163
post #85

NATs are also firewalls. I think people forget that before NATs, when you would install Windows, the minute you connected it to the internet, you had to rush to update it before a virus would infect it. The OS of the 90s weren't secure enough to be exposed to the WAN.

NATs are not firewalls. Any firewall-like functionality provided by NAT is entirely accidental and better provides by an actual NAT.

s/actual NAT/actual firewall/

Re: Internet centralization and the original sin of NAT

#164

Sorry. I implemented the current NAT system in Linux. In particular, avoiding port reservation in favor of squishing more connections into one IP address, as long as the remote address allowed us to differentiate. This, in turn, means incoming traffic from a different address is unroutable. You no longer have a public endpoint . This is "poor man's firewall", but erodes our ability to have a server the way we used to…

Sorry, i am not very much into kernel/netstack development, but a question. So does it mean that even if an alternative NAT system will be available in Linux (kernel module with a switch or whatever) - it will not be adopted by industry because everyone (and every device) is used to how it works now?

NAT itself was a hack to let everything keep working like it already was despite there being more computers than IPv4 addresses.

The Internet Protocol only concerns itself with IP addresses. The idea is that each computer has an IP address, so computers can communicate by sending IP packets; each IP packet says, "Message from computer with IP address X to computer with IP address Y".

But computers have multiple processes, so there's a need to know which process at the receiving computer is the recipient and which process on the sending computer is the sender. This is why transport protocols (TCP and UDP) add a port field. A port uniquely identifies a particular socket opened by a particular process on a computer. So a TCP or UDP message sent via the Internet Protocol contains the information, "From the socket with port 41590 on the computer with IP address X, to the socket with port 443 on the computer with IP address Y".

NAT is a giant hack which is primarily implemented in routers. It makes a whole household (or office building, or university campus) look to the outside world like one big computer with one IP address.

Say we have a computer with IP address L, a router with public IP address X, and a public server with IP address Y. The computer will send a message to the router which says, "From port 41590 @ L, to port 443 @ Y". The router will invent a new random port number (say 41200), add an entry to its NAT table which says "port 41200 means port 41590 @ L", then send a message to the public Internet: "From port 41200 @ X to port 443 @ Y".

When someone then sends back a message "to port 41200 @ X", the router looks that up in its NAT table and rewrites the packet to say "to port 41590 @ L", then sends it to the computer with that local IP address.

The computer doesn't really know that it's speaking through a router. It needs to know that "packets to the public Internet should be sent via the router" but that's it, the packets it sends and receives looks the same as if the router wasn't there. The rest of the world doesn't know that it's speaking to the computer behind the router; from their perspective, it looks like they're just speaking directly to the router. All the special network address translation logic lives only within the router.

Already back then, you couldn't easily deploy solutions which required all computers and middle-boxes on the Internet to change. That's why NAT exists in the first place.

You could deploy a new NAT implementation, but the problem NAT solves is fundamentally that there aren't enough IPv4 addresses for every computer to have an IPv4 address so you need multiple computers to share. I don't think there's a better solution to that problem other than switching everything over to IPv6 (which has been in progress for the past 30 years and has barely reached 50%).

As an aside, you see the term "CGNAT" sometimes as well. This stands for Carrier-Grade NAT and is an evolution of the NAT concept to much bigger contexts; a whole city could share a handful of public IP addresses, making large regions effectively one "local network" behind a "router". Multiple streets could look to the outside world like they're just one gigantic computer. Each household in that area will then probably do its own layer of NAT, making it look to the CGNAT router like the household is one big one computer. This configuration can be called "double NAT". Since each router doing NAT only needs to know about its own NAT, there's really no limit to how deeply you can nest it.

Re: Internet centralization and the original sin of NAT

#165

Sorry. I implemented the current NAT system in Linux. In particular, avoiding port reservation in favor of squishing more connections into one IP address, as long as the remote address allowed us to differentiate. This, in turn, means incoming traffic from a different address is unroutable. You no longer have a public endpoint . This is "poor man's firewall", but erodes our ability to have a server the way we used to…

If it's any consolation, I don't think NAT did anything particularly harmful other than making the adoption of IPv6 less urgent. It's CGNAT that's the real problem, not NAT.

Re: Internet centralization and the original sin of NAT

#166

Earlier quoted context omitted.

Not saying this is what’s going on, but you can ABSOLUTELY have nostalgia for a time that wasn’t your own, too.

I suppose I could ask elsewhere but do you (or does anyone else) have a word/term for this?

Anemoia is the term, I believe, and an almost perfect fit (nostalgia for a time you have never experienced)

Re: Internet centralization and the original sin of NAT

#167
post #47

> 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... 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. A lot of this feels…

> But we'd still end up with server-client cloud architectures, even if we had started with IPv6 in the beginning. Skype was originally peer-to-peer for comms, but ended up with "super-nodes" because of NAT limitations (not sure if STUN/TURN/ICE had been invented by that point). BitTorrent is still peer-to-peer. A number of folks ran Mincecraft servers at home, but you'd only be able to have one on the default port.…

> A number of folks ran Mincecraft servers at home, but you'd only be able to have one on the default port.

This is such a common and stupid problem. It's the same with SSH; if you want to run your own git host, you need to either reserve public port 22 to git, or use it on a non-default port.

More protocols should have some kind of header to tell the server what name was used to connect, just like HTTP's Host header. If SSH clients told the server, "hey I connected via git.example.org", you could have an SSH proxy behind the NAT forward that connection to your git host. If the Minecraft client told the server, "hey I connected via survival.example.org" or "hey I connected via creative.example.org", you could have a Minecraft proxy server route the traffic to the right local address/port.

(I'm actually implementing multiplayer in a game right now and I'm adding this information to the initial connection handshake message, with the intention that you could make a proxy server.)

Re: Internet centralization and the original sin of NAT

#168
post #122

Earlier quoted context omitted.

Yeah I feel like a lot of the people criticizing this are still being client-server brained. There's a lot of use cases that "everyone is a server" would open up without turning everyone into a sysadmin and they'd likely get turned into user-friendly software like BitTorrent or Skype or early Spotify.

"Client-server" thinking may in general be a 'hobbled' way of thinking of things.

It's sadly the only practical way to do things now. For client/server, you only need one party (the server) to not be behind CGNAT. For p2p, you need both parties to not be behind CGNAT. It's typically only possible to guarantee that one party isn't behind CGNAT.

All practical solutions for p2p these days require NAT hole punching through STUN and signaling servers anyway, so even p2p has to be bootstrapped via client/server. Easier to just keep the protocol client/server then.

Re: Internet centralization and the original sin of NAT

#169
post #168

Earlier quoted context omitted.

"Client-server" thinking may in general be a 'hobbled' way of thinking of things.

It's sadly the only practical way to do things now. For client/server, you only need one party (the server) to not be behind CGNAT. For p2p, you need both parties to not be behind CGNAT. It's typically only possible to guarantee that one party isn't behind CGNAT. All practical solutions for p2p these days require NAT hole punching through STUN and signaling servers anyway, so even p2p has to be bootstrapped via clien…

[dead]

Re: Internet centralization and the original sin of NAT

#170
post #69
post #58

Earlier quoted context omitted.

Yes. My ISP will rent me a single IPv4 address for $10 per month. Or I can use DHCP, where my IPv4 address can change at their whim.

> Yes. My ISP will rent me a single IPv4 address for $10 per month. At that price point you can get a small vm, but if you have a dedicated server you want to use on-prem, 10$/mo seems like a reasonable price. > Or I can use DHCP, where my IPv4 address can change at their whim. Check the dhcp.lease to make sure, I used to think that, then I looked at the dhcp lease and the IP was being reserved for up to 48 hours of…

> or learn DHCP

There's nothing to learn here in the end. Its just rules imposed by the ISP. I've had places where the leases expired weekly, and I'd often get a different public IP address when renewed. No amount of learning will change this. If I want out of that, I'd have to pay extra money every month.

I've also had ISPs where I've had the same IPv4 address for years. So long as I was online around the time of the lease renewal, I was pretty much guaranteed to get the same IP. YMMV.

> At that price point you can get a small vm, but if you have a dedicated server you want to use on-prem, 10$/mo seems like a reasonable price.

So I can spend $10/mo for each IP address I want, or I can just use IPv6 where my ISP gives me 295,147,905,179,352,825,856 IP addresses (a /60) by default for free. Hmm...which to choose...

Post reply on HN