3 ms·

What will happen is that IPv4 addresses won't be free anymore, and you'll have to pay a surcharge. This is already happening with some providers. Also, inste

What will happen is that IPv4 addresses won't be free anymore, and you'll have to pay a surcharge. This is already happening with some providers. Also, instead of being given a /29, providers will start handing out /32s. I'm not suggesting this is a good thing, but "calamity" isn't the word that comes to mind.

loup-vaillant 11y ago
I'm not sure you comprehend the magnitude of the disaster. Right now, many people, mostly in countries that are lacking in IPv4 allocation, do not have an internet connection. An internet connection is a public IP. If you're behind a NAT, or something like it, you don't have a public IP, therefore you are not connnected to the internet. You are connected to a private network, which forwards some of your packets to the open internet. And that server thing. No public IP, no server. Not such a big problem when you control the NAT (assuming it's in your router), and can forward some ports. But if you share the same public IP with 50 other customers, it is theoretically impossible to have more than one HTTP server for those 50 people. The practical limit, of course, is zero.
- ghshephard 11y ago
  "Magnitude of the Disaster" is the type of hyperbole that doesn't bring clarity to the situation. I've spent the majority of my working life in the last three years happily accessing the internet, internet services, and I've always been behind a PAT device when in a hotel, serviced apartment, etc... For example, right now, in my Office in Singapore, my IP address is: 192.168.108.34. And I do all my conferences, whiteboarding, VPNs, etc.. from this office. Now - back to your scenario - You certainly can share a lot of HTTP Servers on a single IP address - a lot of the customers I've worked with do so using PAT, and, you get very used to the port number being part of the HTTP server address: I.E. http://www.acme.com:3031 http://www.acme.com:3031 In a ultra-low IP address environment, you have teams with not only IPAM (IP address Management tools), but also Port Address Management - they track who has been allocated to which port. Now - is this the best case scenario? - No, obviously not - it would be awesome to have a Static IP address, and, there are some scenarios in which I have to have a static IP address - in particular getting IPSec VPNs through PAT can be problematic, so if I want to run a VPN concentrator, I start begging and pleading to get a static IP address. But I know this is going to cost me a lot of money. And that's where I started - once we run out of IPv4 addresses, the market will just start bidding the price of them up. Right now, most ISPs in Singapore will give you a static IP address for $120/year. I expect, as they run out of IP addresses, that price will start to increase - and people who might have opted in for one at $120/year, will probably decline at $500/year - returning those IP addresses back into circulation. At the same time, if someone is sitting on a /20 that they aren't using very using very much (4,000 addresses) - and those IP addresses have $2million/year of value to other people, they will be highly incentivized to capture that value. With all that said - was it not wonderful to call Layer 42, and, within 30 seconds, be granted 2001:1868:209::/48 off of their /32 ISP range? Yes, it was. I had 65,000 networks I could play with, each of which had effectively infinite address space. Do I look forward to that the day that is universal, in which every ISP user is immediately granted a /64 without asking, and anybody with a home network gets a /56 without paperwork, and a /48 is available with just a quick, inexpensive surcharge? Yes, also looking forward to that. But - "Disaster" and "Catastrophe" doesn't capture what will happen if IPv4 takes a few extra years to get traction. The market and people's behavior will adjust.
  - zurn 11y ago
    The disaster is that app developers can't rely on their users being on the internet in the sense of end-to-end addressability in developing new applications. This has major chilling effects on less centralised types of applications, and tilts the tables toward big content providers and "enterprise" users with "intranets" behind centralized firewalls. IPv6 deployment is massively late, users have already been conditioned into accepting NAT as internet access, even going so far as NAT boxes being called "routers"- even though NAT flatly contradicts the RFC definition of IP router, which are forbidden from doing port/address NAT along with other arbitrary traffic interference.
    - ghshephard 11y ago
      It's been the case for at least 15 years that app developers couldn't rely on their users being on the internet. It's annoying, and I agree with you has a chilling effect on less-centralized applications, but doesn't rise to the level of "Disaster." One thing that people need to be precise about, particularly as IPv6 comes online, is the difference between NAT and PAT. I realize that 90%+ of the HN community understand the difference, (NAT changes your Address only, PAT changes your address to a single outbound address, and multiplexes a PORT) but with IPv6 it has a very real significance. Deployment of PAT in IPv6 is really quite frowned upon, but there a number of very real administrative reason why Network Prefix Translation (NPT, https://tools.ietf.org/html/rfc6296 https://tools.ietf.org/html/rfc6296 ) - which is really just stateless NAT, makes sense. With NPT, you convert the first 64 bits (the "Network"), but leave the last 64 bits (the "Interface") untouched. This gives the inside of your network really good ISP mobility - allowing you to switch to a new ISP at the drop of a hat, without having to worry about any internal renumbering, updating thousands of DNS records, etc... The only DNS records you would need to worry about would be for external connectivity (which is typically orders of magnitude less than internal hosts, and also typically more well documented. I expect that most forward looking enterprises deploying IPv6 will use some combination of RFC 4193 (Unique Local IPV6 Unicast, https://tools.ietf.org/html/rfc4193 https://tools.ietf.org/html/rfc4193, the IPv6 variant of RFC 1918) + RFC 6296 Network Prefix Translation.
      - 11y ago

loup-vaillant 11y ago

I'm not sure you comprehend the magnitude of the disaster. Right now, many people, mostly in countries that are lacking in IPv4 allocation, do not have an internet connection. An internet connection is a public IP. If you're behind a NAT, or something like it, you don't have a public IP, therefore you are not connnected to the internet. You are connected to a private network, which forwards some of your packets to the open internet. And that server thing. No public IP, no server. Not such a big problem when you control the NAT (assuming it's in your router), and can forward some ports. But if you share the same public IP with 50 other customers, it is theoretically impossible to have more than one HTTP server for those 50 people. The practical limit, of course, is zero.

ghshephard 11y ago
"Magnitude of the Disaster" is the type of hyperbole that doesn't bring clarity to the situation. I've spent the majority of my working life in the last three years happily accessing the internet, internet services, and I've always been behind a PAT device when in a hotel, serviced apartment, etc... For example, right now, in my Office in Singapore, my IP address is: 192.168.108.34. And I do all my conferences, whiteboarding, VPNs, etc.. from this office. Now - back to your scenario - You certainly can share a lot of HTTP Servers on a single IP address - a lot of the customers I've worked with do so using PAT, and, you get very used to the port number being part of the HTTP server address: I.E. http://www.acme.com:3031 http://www.acme.com:3031 In a ultra-low IP address environment, you have teams with not only IPAM (IP address Management tools), but also Port Address Management - they track who has been allocated to which port. Now - is this the best case scenario? - No, obviously not - it would be awesome to have a Static IP address, and, there are some scenarios in which I have to have a static IP address - in particular getting IPSec VPNs through PAT can be problematic, so if I want to run a VPN concentrator, I start begging and pleading to get a static IP address. But I know this is going to cost me a lot of money. And that's where I started - once we run out of IPv4 addresses, the market will just start bidding the price of them up. Right now, most ISPs in Singapore will give you a static IP address for $120/year. I expect, as they run out of IP addresses, that price will start to increase - and people who might have opted in for one at $120/year, will probably decline at $500/year - returning those IP addresses back into circulation. At the same time, if someone is sitting on a /20 that they aren't using very using very much (4,000 addresses) - and those IP addresses have $2million/year of value to other people, they will be highly incentivized to capture that value. With all that said - was it not wonderful to call Layer 42, and, within 30 seconds, be granted 2001:1868:209::/48 off of their /32 ISP range? Yes, it was. I had 65,000 networks I could play with, each of which had effectively infinite address space. Do I look forward to that the day that is universal, in which every ISP user is immediately granted a /64 without asking, and anybody with a home network gets a /56 without paperwork, and a /48 is available with just a quick, inexpensive surcharge? Yes, also looking forward to that. But - "Disaster" and "Catastrophe" doesn't capture what will happen if IPv4 takes a few extra years to get traction. The market and people's behavior will adjust.
- zurn 11y ago
  The disaster is that app developers can't rely on their users being on the internet in the sense of end-to-end addressability in developing new applications. This has major chilling effects on less centralised types of applications, and tilts the tables toward big content providers and "enterprise" users with "intranets" behind centralized firewalls. IPv6 deployment is massively late, users have already been conditioned into accepting NAT as internet access, even going so far as NAT boxes being called "routers"- even though NAT flatly contradicts the RFC definition of IP router, which are forbidden from doing port/address NAT along with other arbitrary traffic interference.
  - ghshephard 11y ago
    It's been the case for at least 15 years that app developers couldn't rely on their users being on the internet. It's annoying, and I agree with you has a chilling effect on less-centralized applications, but doesn't rise to the level of "Disaster." One thing that people need to be precise about, particularly as IPv6 comes online, is the difference between NAT and PAT. I realize that 90%+ of the HN community understand the difference, (NAT changes your Address only, PAT changes your address to a single outbound address, and multiplexes a PORT) but with IPv6 it has a very real significance. Deployment of PAT in IPv6 is really quite frowned upon, but there a number of very real administrative reason why Network Prefix Translation (NPT, https://tools.ietf.org/html/rfc6296 https://tools.ietf.org/html/rfc6296 ) - which is really just stateless NAT, makes sense. With NPT, you convert the first 64 bits (the "Network"), but leave the last 64 bits (the "Interface") untouched. This gives the inside of your network really good ISP mobility - allowing you to switch to a new ISP at the drop of a hat, without having to worry about any internal renumbering, updating thousands of DNS records, etc... The only DNS records you would need to worry about would be for external connectivity (which is typically orders of magnitude less than internal hosts, and also typically more well documented. I expect that most forward looking enterprises deploying IPv6 will use some combination of RFC 4193 (Unique Local IPV6 Unicast, https://tools.ietf.org/html/rfc4193 https://tools.ietf.org/html/rfc4193, the IPv6 variant of RFC 1918) + RFC 6296 Network Prefix Translation.
    - 11y ago