6 ms·

This comes up every time, but it doesn't make any sense. Routers, software, IT professionals, would've all been just as happy to not support IPv4.1 as they have

This comes up every time, but it doesn't make any sense. Routers, software, IT professionals, would've all been just as happy to not support IPv4.1 as they have been to not support IPv6. At this point though the inflection point has already been passed adoption-wise and AWS needs to just do the thing already.

hot_gril 3y ago
v6 introduces more hurdles. New different kinds of addresses (link-local, etc). No more NAT by default. Existing v4 addresses not accessible over it. In contrast, switching to this "v4.1" would be low-risk. You just support longer addresses, that's it.
- snuxoll 3y ago
  Supporting longer addresses still means there's no forwards compatibility from v4. Neighbor discovery replacing ARP, link local addresses, etc. are not really the source of headache when it comes to v6 deployments - the legacy environment that v4 created is.
  - hot_gril 3y ago
    v4.1 host is still addressable from v4 host as long as its address is 32-bit. So they don't start leasing out the longer ones until v4.1 adoption is good enough. In the meantime, you slap in v4.1 hardware without having to even think about it. You can also make compromises with NAT, like handing out 40-bit addresses that are auto-translated to/from 32-bit with 8 bits going into the port.
    - snuxoll 3y ago
      And a IPv6 host is still addressable from an IPv4 host as long as it has an IPv4 address. You've done absolutely nothing to spur adoption - because the mere fact that you extended the address space and required infrastructure all across the globe to be replaced and reconfigured to support it causes the exact same issues. Again, neighbor discovery, SLAAC, link-local addressing, none of it has anything to do with how long it's taken the world to adopt IPv6. The fact that they have to do anything at all is, and there's no solution around that.
      - hot_gril 3y ago
        My v4.1 address would be the same as my v4 address if I was on v4 before. Even if I turn off v4.0, I'm still reachable at the same address on v4.1. This is not the case with v6. That's the problem. Furthermore, the longer addresses would be routed similarly to the 32-bit ones: dst=1.1.1.1.2 would go to the 1.1.1.1/32 router the same exact way dst=1.1.1.1 does. Only difference is what that router does with the packet.
        snuxoll 3y ago
        > Furthermore, the longer addresses would be routed similarly to the 32-bit ones: dst=1.1.1.1.2 would go to the 1.1.1.1/32 router the same exact way dst=1.1.1.1 does. Only difference is what that router does with the packet. IPv4 packets have 32-bit address fields in the packet header, 1.1.1.1/32 still needs to understand IPv4.1 packets or it's going to think you're sending it corrupt garbage. Again, nothing changes - if you do anything to change the structure of the packet header the same problem happens, no matter what.
        hot_gril 3y ago
        Yes, the packet header changes. Basically all routers have supported v6 packets for a while, which was a large effort, but evidently it was possible. And yet, we've not collectively adopted v6. We are stuck with dual stacks. If the same support was added except with the /32s preserved, everyone could've switched to v4.1 with basically no change to the routing, DNS, NAT, etc. Not a big jump like going to v6. Then ISPs could later divide up their /32s and hand out, say, /88s to customers. Address crunch would've been already averted.
        snuxoll 3y ago
        > with basically no change to the routing, DNS, NAT, etc. Except you're wrong on all of the above. We'd still need a completely different "v4.1" routing layer, because a /32 could never be a subnet while also being a distinct endpoint, so we'd have to treat any routes smaller than a /33 as being the old IPv4 world while a /33 and bigger would be v4.1. So we still end up with the exact same split, except now our address space is an even bigger fucking mess instead of the clear break v6 is giving us to make a more hierarchical network (eventually getting rid of the ludicrous routing table bloat we currently have, though we really need to come up with a better solution for multi-WAN failover in small networks to avoid everyone and their dog needing an ASN and BGP session to have a HA setup). DNS would still need changes, because the struct for an A record still contains a 32-bit address. Nothing stopped us from using NAT with IPv6, but it sucks and broke end to end connectivity so while we already had to break the world to make the switch why not deal away with the ugly hack while we were at it. There is no world in which any successor to IPv4 did not have a long transition time without government mandates, and that's basically what it is taking to get ISP's and cloud providers to adapt it (the whole reason AWS, Azure, GCP, et. al. are slowly getting their shit together is the US government is mandated to go single stack).
- blueflow 3y ago
  > You just support longer addresses, that's it. There is no way a router that does not understand the address extension is able to route packages to the larger address spaces correctly. So this is not possible to do.
- throw0101b 3y ago
  > You just support longer addresses, that's it. There is no "just" in this. Copy-pasting from my other comment: -- IPv4 data structures have four bytes/octets (4B) for addresses. So how do you fit 8B of addresses in 4B structures? You don't. So you have to update every network element—host (desktop, laptop, mobile, embedded), router, switch, firewall—to have a new data structure (and maybe new function/system calls, as the old ones assume the old structures). So all devices have to have updated network stacks, including long-lived ones that sometimes are not touched for a decade+. And not just pure networking code: anything that touches (e.g.) DNS as well, as A records are 4B-only as well, so you need a new record type and deploy new DNS server and resolver code everywhere. But of course if you have a 4B-only network elements/devices, they cannot talk to 8B-only devices/services, so you have to create translation mechanisms because some devices may not yet have the update 8B-capable network stack. And sometimes an 8B network is an island in a sea of 4B, so you have to have tunneling. Of course some may have both 4B and 8B, and want to talk to something has also has 4B and 8B, so now you have to have code for source/destination selection. -- So "just" expanding IPv4 to IPv4+ ends up being the exact same amount of work as ended up with IPv6. The only thing you could say with "just" more addresses is keeping ARP and the like (instead of DAD, etc).
  - hot_gril 3y ago
    Building it is the same amount of work as building ipv6 support. Adopting it is not the same work as adopting v6. We already have ubiquitous v6 hardware/software support, but it's a whole 'nother thing to actually use it. 1. Add v4.1 support, but keep using 32-bit addresses. 2. Start using >32-bit addresses when ready. By the way, the WWW has gone through transitions like adopting HTTPS and banning old versions of TLS with it. Crucial to that was having transitional periods where both things work. This step was missed in ipv6 rollout.
    - throw0101b 3y ago
      > 1. Add v4.1 support, but keep using 32-bit addresses. 2. Start using >32-bit addresses when ready. When who is ready? Different people/organizations will be ready at different times. Some people will not be able to get IPv4 addresses so will be 'stuck' with being IPv4.1-only. Given the finite IPv4 addresses, some will move the IPv4 addresses to revenue-generating areas and will go IPv4.1-only internally—which is what prompted Microsoft to be IPv6-only/first internally: their IPv4 addresses got sent to Azure: * https://www.arin.net/blog/2019/04/03/microsoft-works-toward-ipv6-only-single-stack-network/ https://www.arin.net/blog/2019/04/03/microsoft-works-toward-... And once that happens, which it would inevitably too with IPv4.1, we're at: If you have a IPv4-only network elements/devices, they cannot talk to IPv4.1-only devices/services (and vice verse), so you have to create translation mechanisms because some devices may not yet have the update 8B-capable network stack. And sometimes an IPv4.1 network is an island in a sea of IPv4, so you have to have tunneling. Of course some may have both IPv4 and IPv4.1, and want to talk to something has also has IPv4 and IPv4.1, so now you have to have code for source/destination selection.
- hackmiester 3y ago
  The lack of NAT represents the removal of an issue. The fact that you already understand NAT does not reduce the actual, real complexity that it is introducing.
  - hot_gril 3y ago
    NAT is a more desirable form of security than a firewall for most users, despite it not being intended for that purpose. It should be the default, and if you don't want NAT, go ahead and don't use it.
    - bigstrat2003 3y ago
      > NAT is a more desirable form of security than a firewall for most users... I don't agree with this. First, most users don't know or care about security. So neither is more desirable for them. But also, on its merits NAT isn't more desirable. It provides zero security that is not provided by a simple default deny inbound rule on a firewall. And on top of that, it introduces additional complexity that even a non-technical user has to contend with sometimes (port forwarding). NAT is not and never has been a security mechanism. We need to stop trying to shoehorn it in to a role it isn't meant for.
      - hot_gril 3y ago
        It's not shoehorned, though. Corporate and home users find it convenient. It's very hard to screw up, unlike v6 firewalls which often have bad defaults or possibly don't work as intended. Especially when one of the other goals of ipv6 is to enable p2p applications, which might lead to permissive defaults. My home router has one public IP and many private IPs. No matter how crappy my router is, it's impossible to address private IPs from the outside except on the random mapped ports. With v6, I'd instead be double-checking that my router firewall is doing its job, e.g. https://community.verizon.com/t5/Fios-Internet-and-High-Speed/IPv6-firewall-on-Fios-router-is-allowing-inbound-connections/td-p/1573464 https://community.verizon.com/t5/Fios-Internet-and-High-Spee... . Even if the router turns out to be WAI, I shouldn't have to question that!
redox99 3y ago
Not at all. This would be much easier to migrate and support. Nowadays you have two entire separate stacks, each with their own firewall rules. That's why the first thing I do is outright disable IPv6 because of the potential security issues due to misconfiguration. The hardware and operating systems have supported IPv6 for a very long time. The problem is that it's a pain in the ass to maintain 2 stacks simultaneously, that's why adoption is so slow. OS and hardware support is not the bottleneck.
- deleted 3y ago
  [deleted]
- hot_gril 3y ago
  Yep, this idea comes up every time because it's actually a good idea.
  - Dagger2 3y ago
    And every time people explain why the idea is either impossible or describing v6's existing behavior. At what point do these posts become trolling?
    - hot_gril 3y ago
      I've yet to see a satisfactory explanation of either. It's always basically "you'd still have to change the headers" which misses the point.

hot_gril 3y ago

v6 introduces more hurdles. New different kinds of addresses (link-local, etc). No more NAT by default. Existing v4 addresses not accessible over it. In contrast, switching to this "v4.1" would be low-risk. You just support longer addresses, that's it.

snuxoll 3y ago
Supporting longer addresses still means there's no forwards compatibility from v4. Neighbor discovery replacing ARP, link local addresses, etc. are not really the source of headache when it comes to v6 deployments - the legacy environment that v4 created is.
- hot_gril 3y ago
  v4.1 host is still addressable from v4 host as long as its address is 32-bit. So they don't start leasing out the longer ones until v4.1 adoption is good enough. In the meantime, you slap in v4.1 hardware without having to even think about it. You can also make compromises with NAT, like handing out 40-bit addresses that are auto-translated to/from 32-bit with 8 bits going into the port.
  - snuxoll 3y ago
    And a IPv6 host is still addressable from an IPv4 host as long as it has an IPv4 address. You've done absolutely nothing to spur adoption - because the mere fact that you extended the address space and required infrastructure all across the globe to be replaced and reconfigured to support it causes the exact same issues. Again, neighbor discovery, SLAAC, link-local addressing, none of it has anything to do with how long it's taken the world to adopt IPv6. The fact that they have to do anything at all is, and there's no solution around that.
    - hot_gril 3y ago
      My v4.1 address would be the same as my v4 address if I was on v4 before. Even if I turn off v4.0, I'm still reachable at the same address on v4.1. This is not the case with v6. That's the problem. Furthermore, the longer addresses would be routed similarly to the 32-bit ones: dst=1.1.1.1.2 would go to the 1.1.1.1/32 router the same exact way dst=1.1.1.1 does. Only difference is what that router does with the packet.
      - snuxoll 3y ago
        > Furthermore, the longer addresses would be routed similarly to the 32-bit ones: dst=1.1.1.1.2 would go to the 1.1.1.1/32 router the same exact way dst=1.1.1.1 does. Only difference is what that router does with the packet. IPv4 packets have 32-bit address fields in the packet header, 1.1.1.1/32 still needs to understand IPv4.1 packets or it's going to think you're sending it corrupt garbage. Again, nothing changes - if you do anything to change the structure of the packet header the same problem happens, no matter what.
        hot_gril 3y ago
        Yes, the packet header changes. Basically all routers have supported v6 packets for a while, which was a large effort, but evidently it was possible. And yet, we've not collectively adopted v6. We are stuck with dual stacks. If the same support was added except with the /32s preserved, everyone could've switched to v4.1 with basically no change to the routing, DNS, NAT, etc. Not a big jump like going to v6. Then ISPs could later divide up their /32s and hand out, say, /88s to customers. Address crunch would've been already averted.
        snuxoll 3y ago
        > with basically no change to the routing, DNS, NAT, etc. Except you're wrong on all of the above. We'd still need a completely different "v4.1" routing layer, because a /32 could never be a subnet while also being a distinct endpoint, so we'd have to treat any routes smaller than a /33 as being the old IPv4 world while a /33 and bigger would be v4.1. So we still end up with the exact same split, except now our address space is an even bigger fucking mess instead of the clear break v6 is giving us to make a more hierarchical network (eventually getting rid of the ludicrous routing table bloat we currently have, though we really need to come up with a better solution for multi-WAN failover in small networks to avoid everyone and their dog needing an ASN and BGP session to have a HA setup). DNS would still need changes, because the struct for an A record still contains a 32-bit address. Nothing stopped us from using NAT with IPv6, but it sucks and broke end to end connectivity so while we already had to break the world to make the switch why not deal away with the ugly hack while we were at it. There is no world in which any successor to IPv4 did not have a long transition time without government mandates, and that's basically what it is taking to get ISP's and cloud providers to adapt it (the whole reason AWS, Azure, GCP, et. al. are slowly getting their shit together is the US government is mandated to go single stack).
blueflow 3y ago
> You just support longer addresses, that's it. There is no way a router that does not understand the address extension is able to route packages to the larger address spaces correctly. So this is not possible to do.
throw0101b 3y ago
> You just support longer addresses, that's it. There is no "just" in this. Copy-pasting from my other comment: -- IPv4 data structures have four bytes/octets (4B) for addresses. So how do you fit 8B of addresses in 4B structures? You don't. So you have to update every network element—host (desktop, laptop, mobile, embedded), router, switch, firewall—to have a new data structure (and maybe new function/system calls, as the old ones assume the old structures). So all devices have to have updated network stacks, including long-lived ones that sometimes are not touched for a decade+. And not just pure networking code: anything that touches (e.g.) DNS as well, as A records are 4B-only as well, so you need a new record type and deploy new DNS server and resolver code everywhere. But of course if you have a 4B-only network elements/devices, they cannot talk to 8B-only devices/services, so you have to create translation mechanisms because some devices may not yet have the update 8B-capable network stack. And sometimes an 8B network is an island in a sea of 4B, so you have to have tunneling. Of course some may have both 4B and 8B, and want to talk to something has also has 4B and 8B, so now you have to have code for source/destination selection. -- So "just" expanding IPv4 to IPv4+ ends up being the exact same amount of work as ended up with IPv6. The only thing you could say with "just" more addresses is keeping ARP and the like (instead of DAD, etc).
- hot_gril 3y ago
  Building it is the same amount of work as building ipv6 support. Adopting it is not the same work as adopting v6. We already have ubiquitous v6 hardware/software support, but it's a whole 'nother thing to actually use it. 1. Add v4.1 support, but keep using 32-bit addresses. 2. Start using >32-bit addresses when ready. By the way, the WWW has gone through transitions like adopting HTTPS and banning old versions of TLS with it. Crucial to that was having transitional periods where both things work. This step was missed in ipv6 rollout.
  - throw0101b 3y ago
    > 1. Add v4.1 support, but keep using 32-bit addresses. 2. Start using >32-bit addresses when ready. When who is ready? Different people/organizations will be ready at different times. Some people will not be able to get IPv4 addresses so will be 'stuck' with being IPv4.1-only. Given the finite IPv4 addresses, some will move the IPv4 addresses to revenue-generating areas and will go IPv4.1-only internally—which is what prompted Microsoft to be IPv6-only/first internally: their IPv4 addresses got sent to Azure: * https://www.arin.net/blog/2019/04/03/microsoft-works-toward-ipv6-only-single-stack-network/ https://www.arin.net/blog/2019/04/03/microsoft-works-toward-... And once that happens, which it would inevitably too with IPv4.1, we're at: If you have a IPv4-only network elements/devices, they cannot talk to IPv4.1-only devices/services (and vice verse), so you have to create translation mechanisms because some devices may not yet have the update 8B-capable network stack. And sometimes an IPv4.1 network is an island in a sea of IPv4, so you have to have tunneling. Of course some may have both IPv4 and IPv4.1, and want to talk to something has also has IPv4 and IPv4.1, so now you have to have code for source/destination selection.
hackmiester 3y ago
The lack of NAT represents the removal of an issue. The fact that you already understand NAT does not reduce the actual, real complexity that it is introducing.
- hot_gril 3y ago
  NAT is a more desirable form of security than a firewall for most users, despite it not being intended for that purpose. It should be the default, and if you don't want NAT, go ahead and don't use it.
  - bigstrat2003 3y ago
    > NAT is a more desirable form of security than a firewall for most users... I don't agree with this. First, most users don't know or care about security. So neither is more desirable for them. But also, on its merits NAT isn't more desirable. It provides zero security that is not provided by a simple default deny inbound rule on a firewall. And on top of that, it introduces additional complexity that even a non-technical user has to contend with sometimes (port forwarding). NAT is not and never has been a security mechanism. We need to stop trying to shoehorn it in to a role it isn't meant for.
    - hot_gril 3y ago
      It's not shoehorned, though. Corporate and home users find it convenient. It's very hard to screw up, unlike v6 firewalls which often have bad defaults or possibly don't work as intended. Especially when one of the other goals of ipv6 is to enable p2p applications, which might lead to permissive defaults. My home router has one public IP and many private IPs. No matter how crappy my router is, it's impossible to address private IPs from the outside except on the random mapped ports. With v6, I'd instead be double-checking that my router firewall is doing its job, e.g. https://community.verizon.com/t5/Fios-Internet-and-High-Speed/IPv6-firewall-on-Fios-router-is-allowing-inbound-connections/td-p/1573464 https://community.verizon.com/t5/Fios-Internet-and-High-Spee... . Even if the router turns out to be WAI, I shouldn't have to question that!

redox99 3y ago

Not at all. This would be much easier to migrate and support. Nowadays you have two entire separate stacks, each with their own firewall rules. That's why the first thing I do is outright disable IPv6 because of the potential security issues due to misconfiguration. The hardware and operating systems have supported IPv6 for a very long time. The problem is that it's a pain in the ass to maintain 2 stacks simultaneously, that's why adoption is so slow. OS and hardware support is not the bottleneck.

deleted 3y ago
[deleted]
hot_gril 3y ago
Yep, this idea comes up every time because it's actually a good idea.
- Dagger2 3y ago
  And every time people explain why the idea is either impossible or describing v6's existing behavior. At what point do these posts become trolling?
  - hot_gril 3y ago
    I've yet to see a satisfactory explanation of either. It's always basically "you'd still have to change the headers" which misses the point.