4 ms·

Supporting longer addresses still means there's no forwards compatibility from v4. Neighbor discovery replacing ARP, link local addresses, etc. are not really t

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

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