5 ms·

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.

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.

TZubiri 16d ago
>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.
- vel0city 15d ago
  > 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.
  - TZubiri 15d ago
    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.
    - vel0city 15d ago
      > 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!

TZubiri 16d ago

>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.

vel0city 15d ago
> 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.
- TZubiri 15d ago
  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.
  - vel0city 15d ago
    > 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!