3 ms·

> 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

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

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.