4 ms·

If a backwards compatible, "IPv4.1" version would have been deployed, designed to route transparently through the legacy IPv4 infrastructure, then public routes

If a backwards compatible, "IPv4.1" version would have been deployed, designed to route transparently through the legacy IPv4 infrastructure, then public routes could have been restricted to the legacy field for a number of years by IANA. 32 bits was perfectly adequate for routing for decades and would still be if not for the route explosion caused by exhaustion itself. A similiar problem could still happen inside your mixed IPv4-"IPv4.1" system, but in that case it's your problem to fix and not the fault of the protocol or of some distant sysadmin.

darkr 11y ago
IPv4.1 is a thing, and has been supported in the Linux kernel for some years. It basically adds on a extra octet to IPv4, giving you 40 bits of address space rather than 32. AFAIK this hasn't and will probably never make it out of experimental status.
lmm 11y ago
> If a backwards compatible, "IPv4.1" version would have been deployed, designed to route transparently through the legacy IPv4 infrastructure, then public routes could have been restricted to the legacy field for a number of years by IANA. So endpoints would not have publicly routable addresses, and your packets would be sent across the Internet encapsulated as IPv4. Isn't that just NAT? It would work, to the extent that NAT works today, but it wouldn't get us any closer to having a publicly routable network with more addresses (you'd still get undebuggable problems whenever you tried to switch on public routing), and it wouldn't address the real problem which is not just IP address exhaustion but also class A, B and C exhaustion. What do you do when a new datacenter wants to connect to the Internet? Give it a single IP taken from the middle of a block owned by the same company? That's your "route explosion caused by exhaustion itself" right there.
- cornholio 11y ago
  > Isn't that just NAT? No, the critical difference being that "NAT internal IPs" are now public IPv6s and the NAT mapping, instead of being private to the NAT box is now exposed to the other "NAT boxes" on the internet, for example encapsulated in an IPv4 option that is ignored by legacy systems. This means two IPv6 networks can converse transparently and not care what IPv4 connectivity lies between them. This further means that: 1. IPv6 deployment is no longer a tragedy of the commons: if I deploy IPv6 I get it's benefits immediately along with my remote peers, no longer dependent of providers, AWS or some remote sysadmin over which I have no control. 2. There are no longer any dual stacks to maintain, timeouts, and switches that plague us today; IPv6 just works on the existing IPv4 infrastructure until it becomes dominant. 3. IPv4-only services are incetivized to upgrade because they can provide better service to IPv6 customers who share a common IPv4 that will presumably revert to a form of NAT when connecting to an IPv4 only server. In short, a rational and much less risky upgrade path. >What do you do when a new datacenter wants to connect to the Internet? Give it a single IP taken from the middle of a block owned by the same company? It's obviously too late now to fix this. What I am saying is we did not have a datacenter explosion, but a route explosion fueled by exhaustion, where the same datacenter needed more public IPs, got them in a myriad of tiny blocks and broadcasted misery to all routers on the planet. An IPv6 success would have allowed us to keep 32 bit routes for a long time.
  - lmm 11y ago
    > No, the critical difference being that "NAT internal IPs" are now public IPv6s and the NAT mapping, instead of being private to the NAT box is now exposed to the other "NAT boxes" on the internet, for example encapsulated in an IPv4 option that is ignored by legacy systems. This means two IPv6 networks can converse transparently and not care what IPv4 connectivity lies between them. But IPv4 connectivity can only route according to the IPv4 rules. Which means two "IPv6" networks would have to use the IPv4 rules as well, because a network where half the routers are using one set of rules and half of them are using the others will go terribly wrong. So you're stuck only using "IPv6" at the endpoints, and IPv4 in between - i.e. NAT. > It's obviously too late now to fix this. What I am saying is we did not have a datacenter explosion, but a route explosion fueled by exhaustion, where the same datacenter needed more public IPs, got them in a myriad of tiny blocks and broadcasted misery to all routers on the planet. An IPv6 success would have allowed us to keep 32 bit routes for a long time. The estimate I've seen is that fragmentation means there are 3x as many routes as there should be. Which sounds like a lot, but with the exponential growth in the number of internet-connected devices, that would only have covered another ~2 years' growth.
    - cornholio 11y ago
      Of course, all such encapsulated "IPv6" traffic is routed according to the public IPv4 rules up to the network that emitted the rules, which will further examine the full address and take appropriate private routing decisions. To talk to your "IPv6" node, I don't need to know the full route, just be able to route to a system close enough to you that understands "IPv6" - the border of your network. I stress again that when you connect me from behind NAT, I see your public IPv4 but have no idea how to reach you back, nor can you publish such info. When you contact me over an 6:4 encapsulation, I get your globally unique IPv6 which I can use to connect back to you at a later date - connection works end to end as if we were inside an IPv6 Internet, so it's not fair to call it "NAT". It's more aptly a NAT64-tunneling hybrid, that's transparent, backwards compatible and can be switched to full v6 operation when critical mass is achieved, by symply publishing 128 bit routes. In hindsight, I am convinced the dual stack solution is much, much harder to deploy and was the wrong solution.

darkr 11y ago

IPv4.1 is a thing, and has been supported in the Linux kernel for some years. It basically adds on a extra octet to IPv4, giving you 40 bits of address space rather than 32. AFAIK this hasn't and will probably never make it out of experimental status.

lmm 11y ago

> If a backwards compatible, "IPv4.1" version would have been deployed, designed to route transparently through the legacy IPv4 infrastructure, then public routes could have been restricted to the legacy field for a number of years by IANA. So endpoints would not have publicly routable addresses, and your packets would be sent across the Internet encapsulated as IPv4. Isn't that just NAT? It would work, to the extent that NAT works today, but it wouldn't get us any closer to having a publicly routable network with more addresses (you'd still get undebuggable problems whenever you tried to switch on public routing), and it wouldn't address the real problem which is not just IP address exhaustion but also class A, B and C exhaustion. What do you do when a new datacenter wants to connect to the Internet? Give it a single IP taken from the middle of a block owned by the same company? That's your "route explosion caused by exhaustion itself" right there.

cornholio 11y ago
> Isn't that just NAT? No, the critical difference being that "NAT internal IPs" are now public IPv6s and the NAT mapping, instead of being private to the NAT box is now exposed to the other "NAT boxes" on the internet, for example encapsulated in an IPv4 option that is ignored by legacy systems. This means two IPv6 networks can converse transparently and not care what IPv4 connectivity lies between them. This further means that: 1. IPv6 deployment is no longer a tragedy of the commons: if I deploy IPv6 I get it's benefits immediately along with my remote peers, no longer dependent of providers, AWS or some remote sysadmin over which I have no control. 2. There are no longer any dual stacks to maintain, timeouts, and switches that plague us today; IPv6 just works on the existing IPv4 infrastructure until it becomes dominant. 3. IPv4-only services are incetivized to upgrade because they can provide better service to IPv6 customers who share a common IPv4 that will presumably revert to a form of NAT when connecting to an IPv4 only server. In short, a rational and much less risky upgrade path. >What do you do when a new datacenter wants to connect to the Internet? Give it a single IP taken from the middle of a block owned by the same company? It's obviously too late now to fix this. What I am saying is we did not have a datacenter explosion, but a route explosion fueled by exhaustion, where the same datacenter needed more public IPs, got them in a myriad of tiny blocks and broadcasted misery to all routers on the planet. An IPv6 success would have allowed us to keep 32 bit routes for a long time.
- lmm 11y ago
  > No, the critical difference being that "NAT internal IPs" are now public IPv6s and the NAT mapping, instead of being private to the NAT box is now exposed to the other "NAT boxes" on the internet, for example encapsulated in an IPv4 option that is ignored by legacy systems. This means two IPv6 networks can converse transparently and not care what IPv4 connectivity lies between them. But IPv4 connectivity can only route according to the IPv4 rules. Which means two "IPv6" networks would have to use the IPv4 rules as well, because a network where half the routers are using one set of rules and half of them are using the others will go terribly wrong. So you're stuck only using "IPv6" at the endpoints, and IPv4 in between - i.e. NAT. > It's obviously too late now to fix this. What I am saying is we did not have a datacenter explosion, but a route explosion fueled by exhaustion, where the same datacenter needed more public IPs, got them in a myriad of tiny blocks and broadcasted misery to all routers on the planet. An IPv6 success would have allowed us to keep 32 bit routes for a long time. The estimate I've seen is that fragmentation means there are 3x as many routes as there should be. Which sounds like a lot, but with the exponential growth in the number of internet-connected devices, that would only have covered another ~2 years' growth.
  - cornholio 11y ago
    Of course, all such encapsulated "IPv6" traffic is routed according to the public IPv4 rules up to the network that emitted the rules, which will further examine the full address and take appropriate private routing decisions. To talk to your "IPv6" node, I don't need to know the full route, just be able to route to a system close enough to you that understands "IPv6" - the border of your network. I stress again that when you connect me from behind NAT, I see your public IPv4 but have no idea how to reach you back, nor can you publish such info. When you contact me over an 6:4 encapsulation, I get your globally unique IPv6 which I can use to connect back to you at a later date - connection works end to end as if we were inside an IPv6 Internet, so it's not fair to call it "NAT". It's more aptly a NAT64-tunneling hybrid, that's transparent, backwards compatible and can be switched to full v6 operation when critical mass is achieved, by symply publishing 128 bit routes. In hindsight, I am convinced the dual stack solution is much, much harder to deploy and was the wrong solution.