Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Internet centralization and the original sin of NAT

dreamstation.systems

Post reply on HN
Print view View original

71–80 of 197 posts

Re: Internet centralization and the original sin of NAT

#71

Post by TZubiri »

Hizonner wrote: post #68
TZubiri wrote: post #55

Earlier quoted context omitted.

Do you have any example where leasing an ipv4 block from a NIC directly costs more than 5$ per IPv4 address per year?

Counting the cost of creating the company so you can actually deal directly with a NIC? Every. Single. Individual. End. User. Device. Should. Be. Addressable. Given that there are more such devices out there then there are IPv4 addresses to begin with, cost doesn't even come into it.

>Counting the cost of creating the company so you can actually deal directly with a NIC?

No, the question was taking the price that the NIC sells the IP blocks at. Understanding that in order to get 1 IPv4 address you will be buying from a distributor at a markup, but still, with Wholesale prices at 0.6$ (LACNIC) to 2.5$ (ARIN) per IP address per year, even with a markup of 300%, we are still at filthy cheap prices (2.4$/year to 10$/year)

>Every. Single. Individual. End. User. Device. Should. Be. Addressable. Given that there are more such devices out there then there are IPv4 addresses to begin with, cost doesn't even come into it.

Oh, ok, I was writing mostly about server side IPv4 assignment. I guess your position is a much stronger stance than mine, I argue that all servers should have an IP(v4) adress, you argue that every client device should. In that sense, consider that there's a lot of users, on this website even, that insist on running hosts without a dedicated IP address. There's lower hanging fruit.

Re: Internet centralization and the original sin of NAT

#72

Post by icedchai »

preisschild wrote: post #33
elric wrote: post #23

Calling NAT the original sin is a serious exaggeration. Carrier Grade NAT (CGNAT) is a truly evil concept that restricts the freedoms of the CGNATed users. But regular NAT is fine as long as you can control it. "No one wanting to bother with port forwarding" is largely a matter of shitty UX on the home gateway side and laziness on the side of the operator. Same with UPnP. If anything, NAT has saved millions of wildly…

> If anything, NAT has saved millions of wildly insecure devices running unpatched old Windows versions from getting pwned the second they connect to the open internet. Its definitely the opposite. People started ignoring security because its "natted" anyways, even though NAT was never supposed to be security-critical. Thats what firewalls are for.

The typical NAT implementation ("PAT", single public IP, RFC-1918 network) gives you an implicit stateful firewall denying unsoliticed inbound traffic. Most people don't need anything else.

Re: Internet centralization and the original sin of NAT

#73

Post by TZubiri »

parasyte wrote: post #70
TZubiri wrote: post #40

Earlier quoted context omitted.

You are describing the product technically, but I find how it is used more important. Do you use it? What do you use it for? If empirically most users use it to host a server on a machine with firewalled IP, then that's more descriptive than its technical featureset as listed on the tin.

i personally have used it * to provide access to my home network, as though i am on the home network, while outside of said network * to connect several locations to the same business network the first lets me provide locally hosted services without exposing them to the internet, by allowing members of the VPN ("tailnet" in their parlance) to connect to those services the second was very handy to move a few users fro…

Quite legitimate, a common use case of VPNs, an L3 encryption tunnel to provide virtual LAN access. It's kind of a hack usually, but it might work as a second redundant layer of security (the other usually being HTTPs, and in the case of there being no other layer of encryption that's where VPN wrapping is kind of a hacky solution).

The other common but completely distinct usecase of VPNs being residential usage to encrypt traffic and even more distinct, with the purpose of masking the true origin of a request.

In the former type of usage, which is the one you use, I think any VPN system would fulfill your purposes, of course you have to use something, but I'd venture a guess that you are using the generic features of tailscale, not its commercially distinguishing features. But they are still very on brand, generic or not.

fwiw, the author/founder seems to have made a career out of building post-hoc hacks in one layer to fix the shortcoming of other layers, to take memcached as an example. I don't think my thesis is novel, that these types of hacks are subpar when compared to solving the issue at the appropriate layer, it's part of the tradeoff of the technologies, but I'm just particulary opposed to any hack that allows server admins to skip the step where they get a dedicated IP address, I'm less opposed (but still) to other types of hacks.

Re: Internet centralization and the original sin of NAT

#74

Post by TZubiri »

rcxdude wrote: post #43
TZubiri wrote: post #4

Related comment from another thread https://news.ycombinator.com/item?id=49454785 > 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. That tracks. I briefly looked into the Tailscale website and I thought maybe I was wrong, maybe it's not a NAT/ddns toolchain, maybe it's something more comple…

The fact that it's a VPN is also pretty important, despite the utility of it also dealing with NAT headaches for you. The main selling point is acting as a relatively efficient private overlay network, giving you a consistent private network even as devices move between different internet connections. (Something that NAT makes a bit harder but you don't get for free even if NAT isn't a factor)

I see it now, it's a bundle of both the practical and security aspects. I think the security aspects serve mostly as a marketing tool, potentially serving users who truly need a VPN.

But if I see a user that exposes a server without a dedicated IP address, and they use tailscale for this, the way I would describe it is that they are adding a third party node that routes traffic for them (just to provide multiplexing), so in terms of security, it's an additional unnecessary man in the middle. It's a testament to the marketing team that they are able to sell it as 'added security'. It's hard to know exactly how such open infra technologies are used, but I get the feeling that a good part of the customer base is buying tailscale to patch up a bad infra decision, while being (self) deluded into thinking that their system is very bleeding edge and secure.

Props to tailscale actually, lots to learn here, the lesson is to let the client save face and sell your tech not as something that fixes an embarassing mistake, but as something that's a bit opaque, high tech and implements security protocols, even if performatively.

Bonus points if there is upsell or onramp into actually sound technologies, like eventually you have to drop the whole tailscale thing and help the client actually get an IP address right? Or maybe even onboard the rogue ddnsed service onto the organization's existing ASN. It's a hard sell because the best solution in that case actually removes the product from the organization altogether, but I can imagine ways were the product stays in a non-central, QA-like sidechannel.

Re: Internet centralization and the original sin of NAT

#75

Post by grumbel »

eru wrote: post #13
mittensc wrote: post #8

I remember times before NAT and SSL You could share things easily, sure, but anyone could get hacked pretty easily and very targetted. After NAT, sharing was still easy lots of 'piracy' apps, various messengers with NAT passthrough Both before and after you needed to be technical, you can't ask someone that doesnt know about computers to set up an FTP server, and if they did it would be a nightmare and they'd likely…

> Anyway, we'll get the whole non-nat with IPv6, let's see what that brings I'll believe it when I see it. So far it doesn't look like IPv6 will win anytime soon.

And even if it wins, it won't matter much, since it is only one of many issues with the current Internet that prevents people from connecting to each other. Even with IPv6 you'd still have no way to find the other person and the moment they hop between networks, their IPv6 address won't stay the same either.

Ultimately I think none of this will be solved at the low level, it needs something like Iroh or libp2p where you build a new network on top of the Internet infrastructure, so that you can have things like persistent cryptographic identities and addresses that you can carry with you, largely independent of the underlying network architecture.

Re: Internet centralization and the original sin of NAT

#76

Post by 9x39 »

sedivy94 wrote: post #19
vbezhenar wrote: post #10

I'm still not convinced that IPv6 is a good thing. I think that we should have doubled down on sharing IP addresses. Both for consumbers (NAT) and for servers (NAT, TLS/HTTP reverse-proxying). It just solves all problems with IP address exhaustion. And the fact that consumers can't just directly connect to each other is a feature.

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 else: https://en.wikipedia.org/wiki/Protocol_Wars

They emerged with a decent answer: L2 crosses intranetwork, L3 crosses internetwork. Their separation allows L3 addressing to be completely unaware of multiple changing L2 (lower level) intranetwork switches, which is immensely useful.

Trying to solve everything with One Master Protocol to solve it all turned out like this: https://xkcd.com/927/

Re: Internet centralization and the original sin of NAT

#77

Post by ironhaven »

elric wrote: post #23

Calling NAT the original sin is a serious exaggeration. Carrier Grade NAT (CGNAT) is a truly evil concept that restricts the freedoms of the CGNATed users. But regular NAT is fine as long as you can control it. "No one wanting to bother with port forwarding" is largely a matter of shitty UX on the home gateway side and laziness on the side of the operator. Same with UPnP. If anything, NAT has saved millions of wildly…

I don't think that you can draw the line between NAT and CGNAT. The fact that single NAT works as well as it does is an argument for why it is ok to double NAT with CGNAT.

The conceit behind NAT is that 99% of traffic over the router will be client-server and the last 1% can get away with separately negotiating with the router to get inbound traffic.

For example my ISP Xfinity by default will put your router in CGNAT space (and ipv6) but if you request port forwarding from a mobile app the upstream router will assign you a ipv4 address and it all works. NAT is considered fine because adding roadblocks to server hosting is a acceptable tradeoff.

The reason they i think they can be so flexible is that they likey have a ipv6 backbone to route to all the customers and ipv4 is not used for routing but as a extra service layered on top with packing the 48 bits of ipv4 and port inside a ipv6 address via MAP-T

Re: Internet centralization and the original sin of NAT

#78

Post by 9x39 »

vbezhenar wrote: post #10

I'm still not convinced that IPv6 is a good thing. I think that we should have doubled down on sharing IP addresses. Both for consumbers (NAT) and for servers (NAT, TLS/HTTP reverse-proxying). It just solves all problems with IP address exhaustion. And the fact that consumers can't just directly connect to each other is a feature.

Easier just to say it's a thing, like a force of nature.

New network growth (mobile, Africa, Asia) uses it, old growth stays on v4 and will eventually roll over. People with address space usually don't need much more, but the IPv6 space better reflects how connected the world is - we're gonna need a bigger address space than v4, that's for sure.

New protocols shipped quickly on rough consensus and working code and weren't perfect - some left all kinds of undefined behavior, or lacked clear advantages over predecessors and competing protocols.

Re: Internet centralization and the original sin of NAT

#79

Post by tsimionescu »

Uptrenda wrote: post #27

Author is right about everything. Also: IPv6 doesn't fix this, it just introduces a new problem. IPv6 machines end up with local firewalls + stateful firewalls on the router. That router doesn't let in inbound cons. There is a part of UPnP that lets you add "pin holes" (it works like you expect) -- but the drawbacks are its kind of obscure, poorly implemented, and not guaranteed to be enabled. The idea of router soun…

What consumer routers implement DPI in their default firmware? What type of traffic are you claiming they are dropping?

I've never heard of a claim like this, so I'm really curious. Note that I'm not talking about the huge DPI market for corporate/state networks.

Re: Internet centralization and the original sin of NAT

#80

Post by warkdarrior »

solatic wrote: 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…

> Running a server used to be trivial: run an executable, tell people your address, done...

This works, until you have more than one person accessing your server. Then you need to worry about accounts, credentials, data isolation, etc. And then if a couple of people connect to your server and start using it, you have to worry about staying online, staying updated, backing up the data. But other than that... yes, trivial.

And just to be really explicit, you always have more than one person accessing your server, and most of the time they are unwanted users trying to break in.

Post reply on HN