3 ms·

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 fac

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
        They need to retrofit those things to support longer addresses, but I mean the existing data and rules don't change. The DNS records and IP routes stay the same. And no, you don't introduce special v4 vs v4.1 routing. For this phase, everyone is still using /32s. Then once basically everything is speaking v4.1 and ok with longer addrs, it's trivial to split up /32 blocks as desired. And yes, NAT stays for most people. That's fine, you'd still be free to disable it and give your devices public IPs if you want.
- Dagger2 3y ago
  > 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. That's not the problem. Being reachable "at the same address on v4.1" (or v6) does not mean that v4 hosts can reach you. In order for v4 hosts to reach you, you have to be doing v4, because v4 hosts will be sending you v4 packets. If you've turned off v4 then that won't work. It'll work if you leave v4 on... but then you're just doing dual stack, and v6 can do that too. The problem here is that you haven't realized that what you're describing is no different to v6's approach, just phrased differently.
  - hot_gril 3y ago
    As far as I can tell, nearly every system has an ipv6 stack included, but they are often choosing not to enable it. So ipv6's adoption problem is no longer related to a lack of capabilities on hosts. Do you agree with that? Let's say every ipv6 stack we have today were instead playing by "ipv4.1"'s rules, meaning same addresses and routing as v4 (and possibly the same packet format as v6). Nobody is taking advantage of longer addresses yet, but the bits are there for later. This also means old DNS entries are still valid, and NATs are still common. What would stop many people from flipping on ipv4.1 mode?
    - Dagger2 3y ago
      How is that not what we're already doing? Almost everyone with a v6 stack still has the exact same v4 address they had before, using the exact same routing as v4. Old DNS entries are still valid, NAT's still common. The only difference seems to be that some people are already making use of the bigger address space, rather than waiting. And that's surely a good thing? If you told everybody to wait until absolutely everything supported it, you'd be waiting forever, and you'd be giving up the benefits of having a larger address space available the entire time... and you don't have a way to force people to wait anyway, so that idea wouldn't even implementable in the first place.

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
      They need to retrofit those things to support longer addresses, but I mean the existing data and rules don't change. The DNS records and IP routes stay the same. And no, you don't introduce special v4 vs v4.1 routing. For this phase, everyone is still using /32s. Then once basically everything is speaking v4.1 and ok with longer addrs, it's trivial to split up /32 blocks as desired. And yes, NAT stays for most people. That's fine, you'd still be free to disable it and give your devices public IPs if you want.
Dagger2 3y ago
> 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. That's not the problem. Being reachable "at the same address on v4.1" (or v6) does not mean that v4 hosts can reach you. In order for v4 hosts to reach you, you have to be doing v4, because v4 hosts will be sending you v4 packets. If you've turned off v4 then that won't work. It'll work if you leave v4 on... but then you're just doing dual stack, and v6 can do that too. The problem here is that you haven't realized that what you're describing is no different to v6's approach, just phrased differently.
- hot_gril 3y ago
  As far as I can tell, nearly every system has an ipv6 stack included, but they are often choosing not to enable it. So ipv6's adoption problem is no longer related to a lack of capabilities on hosts. Do you agree with that? Let's say every ipv6 stack we have today were instead playing by "ipv4.1"'s rules, meaning same addresses and routing as v4 (and possibly the same packet format as v6). Nobody is taking advantage of longer addresses yet, but the bits are there for later. This also means old DNS entries are still valid, and NATs are still common. What would stop many people from flipping on ipv4.1 mode?
  - Dagger2 3y ago
    How is that not what we're already doing? Almost everyone with a v6 stack still has the exact same v4 address they had before, using the exact same routing as v4. Old DNS entries are still valid, NAT's still common. The only difference seems to be that some people are already making use of the bigger address space, rather than waiting. And that's surely a good thing? If you told everybody to wait until absolutely everything supported it, you'd be waiting forever, and you'd be giving up the benefits of having a larger address space available the entire time... and you don't have a way to force people to wait anyway, so that idea wouldn't even implementable in the first place.