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

171–180 of 197 posts

Re: Internet centralization and the original sin of NAT

#171

Post by vel0city »

TZubiri wrote: post #71
Hizonner wrote: post #68

Earlier quoted context omitted.

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 (…

> I argue that all servers should have an IP(v4) adress, you argue that every client device should.

In the IP world, there is no difference between an "client" and a "server". There are just two things communicating. Things which may be clients may also behave like servers from time to time and from circumstance to circumstance.

My home PC is sometimes a "client". Its a "client" when I'm talking to this website. Its also a "server" when I'm connecting to its file shares. Its also a "server" when I'm wanting to stream games from it. A game console is sometimes a "client" when its downloading games and updates, its also sometimes a "server" when I play games online and do matchmaking. My phone is a "client" when its talking to the messaging app servers, it is also a "peer" when I make a phone call to my friend.

Thinking that things are only ever "clients" or only ever "servers" is an overly simplistic view of the world. Devices aren't purely "servers" or "clients", applications/services are what make such a distinction, and even then that can change depending on the context.

Re: Internet centralization and the original sin of NAT

#172

Post by unethical_ban »

tptacek wrote: post #154
unethical_ban wrote: post #105

Earlier quoted context omitted.

You are correct. The reason NAT is seen as security on home networks is that, absent a firewall, it acts as a default deny to inbound traffic.

In other words, the reason NAT is seen as security is that it provides security (imperfectly, like almost everything else).

In such a way that it can partially break connectivity and in a way that fails to have users think about security explicitly, yes. Imperfectly.

Re: Internet centralization and the original sin of NAT

#173

Post by tptacek »

unethical_ban wrote: post #172
tptacek wrote: post #154

Earlier quoted context omitted.

In other words, the reason NAT is seen as security is that it provides security (imperfectly, like almost everything else).

In such a way that it can partially break connectivity and in a way that fails to have users think about security explicitly, yes. Imperfectly.

Yes when has a security mechanism ever pissed off Unix-on-the-desktop nerds like us before.

Re: Internet centralization and the original sin of NAT

#174

Post by icedchai »

tptacek wrote: post #151

NAT wasn't so much normalized as a security feature as it was introduced as one. The flagship NAT product of the 1990s was the Cisco PIX, a firewall. It resulted from Cisco's acquisition of the company that originated NAT.

Yes, I remember the PIX! After my time at a few early ISPs, I briefly had a corporate networking job and a PIX was one of the first hardware firewalls I deployed.

Re: Internet centralization and the original sin of NAT

#175

Post by TZubiri »

vel0city wrote: post #171
TZubiri wrote: post #71

Earlier quoted context omitted.

>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 (…

> I argue that all servers should have an IP(v4) adress, you argue that every client device should. In the IP world, there is no difference between an "client" and a "server". There are just two things communicating. Things which may be clients may also behave like servers from time to time and from circumstance to circumstance. My home PC is sometimes a "client". Its a "client" when I'm talking to this website. Its…

I agree that there is no technical difference in the original ipv4 standard.

There is one in the og tcp standard though. Server, listening, ports are well known, and they uhh listen. Might be semantical, but it's in the spec. Listening port is dedicated to an application type.

Furthermore the newer protocols like NAT make an even clearer technical distinction, clients can have no dedicated ipv4, but servers must retain that property. See? They are different in technical nature.

That's without even getting into empirical protocol semantics. Your device is not a server, it never opens permanent ports associated with a specific process for non-local connections. Nor does the router even do that by proxy, the natting router may provide a listening pseudoport, but it does so in an ephemeral per-connection fashion.

Re: Internet centralization and the original sin of NAT

#176

Post by vel0city »

TZubiri wrote: post #175
vel0city wrote: post #171

Earlier quoted context omitted.

> I argue that all servers should have an IP(v4) adress, you argue that every client device should. In the IP world, there is no difference between an "client" and a "server". There are just two things communicating. Things which may be clients may also behave like servers from time to time and from circumstance to circumstance. My home PC is sometimes a "client". Its a "client" when I'm talking to this website. Its…

I agree that there is no technical difference in the original ipv4 standard. There is one in the og tcp standard though. Server, listening, ports are well known, and they uhh listen. Might be semantical, but it's in the spec. Listening port is dedicated to an application type. Furthermore the newer protocols like NAT make an even clearer technical distinction, clients can have no dedicated ipv4, but servers must reta…

> There is one in the og tcp standard though

TCP isn't IP.

> Server, listening, ports are well known, and they uhh listen

Sure, but that's the application not the device. A device can have outbound connections and can be listening.

> clients can have no dedicated ipv4, but servers must retain that property. See?

My desktop at home has no public dedicated IPv4 (technically neither does my router, it's DHCP and subject to change), and yet still has listening ports.

If I've got httpd running on multiple things on my LAN which get IP addresses from DHCP, and I've got a reverse proxy that's getting NAT'd traffic from the router and proxying those requests, what is the "server" in this setup to you? These devices don't necessarily have dedicated RFC1918 IPv4 addresses, they're all just DHCP and register those IP addresses in the DNS which is referenced by the proxy. They'll change constantly for this example. (Note: this is extremely common in containerized or autoscaling deployments, not entirely a hypothetical!)

> Your device is not a server, it never opens permanent ports associated with a specific process for non-local connections

Sure it does. It's got dozens of ports permanently opened. That's my point. It's not like I have to go to the server store and buy a server to have ports open. I just launch a process and make a change to my device firewall, and now I'm a "server". The same device I'm using as a client to talk to you right now. Incredible! I can even use the same application, like a videogame, to be both a client and a server at the same time! I can start a match, join it at the same time, and allow outside players come join, and that might all technically be in the same executable!

> Nor does the router even do that by proxy, the natting router may provide a listening pseudoport, but it does so in an ephemeral per-connection fashion.

The router is just routing packets. It is not opening a listening port. It gets a packet delivered, it applies a set of rules to it, and passes it out an interface. If you think a router has to be "listening" on a specific port to receive that packet, you're misunderstanding what a router is doing. Sometimes you might even NAT without taking into account a port or a protocol at all!

Re: Internet centralization and the original sin of NAT

#177

Post by hdgvhicv »

litoE wrote: post #58
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?

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.

So change ISP. Your isp is making a fortune from you as part of price segregation, nothing to do with demand.

Re: Internet centralization and the original sin of NAT

#178

Post by hdgvhicv »

vel0city wrote: post #170
TZubiri wrote: post #69

Earlier quoted context omitted.

> 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 th…

An ISP should be giving you a /56. If they are giving you a /60 that the sign of a terrible ISP anyway.

Re: Internet centralization and the original sin of NAT

#179

Post by vel0city »

hdgvhicv wrote: post #178
vel0city wrote: post #170

Earlier quoted context omitted.

> 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 th…

An ISP should be giving you a /56. If they are giving you a /60 that the sign of a terrible ISP anyway.

No argument from me here on the /56 vs a /60, I play the cards I'm dealt. AT&T being the same shitbags they've always been. But its multi-gigabit fiber from them or questionable DOCSIS from Spectrum, and I've never met an honest Spectrum representative. I refuse to do business with them after all the fraud they've given me over the years.

In the end its still a bajillion-ish IPv6 addresses I have to play with versus the one-ish I have with IPv4.

Re: Internet centralization and the original sin of NAT

#180

Post by Sha1rholder »

TZubiri wrote: post #175
vel0city wrote: post #171

Earlier quoted context omitted.

> I argue that all servers should have an IP(v4) adress, you argue that every client device should. In the IP world, there is no difference between an "client" and a "server". There are just two things communicating. Things which may be clients may also behave like servers from time to time and from circumstance to circumstance. My home PC is sometimes a "client". Its a "client" when I'm talking to this website. Its…

I agree that there is no technical difference in the original ipv4 standard. There is one in the og tcp standard though. Server, listening, ports are well known, and they uhh listen. Might be semantical, but it's in the spec. Listening port is dedicated to an application type. Furthermore the newer protocols like NAT make an even clearer technical distinction, clients can have no dedicated ipv4, but servers must reta…

> Furthermore the newer protocols like NAT make an even clearer technical distinction, clients can have no dedicated ipv4, but servers must retain that property. See? They are different in technical nature.

No. Both servers and clients can have no public ipv4

Post reply on HN