4 ms·

> Yep, it's tragic because it all stems from unforced differences vs ipv4. The design was reasonable, but with perfect hindsight, it needed to be different. The

> Yep, it's tragic because it all stems from unforced differences vs ipv4. The design was reasonable, but with perfect hindsight, it needed to be different. They needed to keep the existing /32s and just make the address field bigger, despite the disadvantages. Exactly. I would love to have seen the world in which that happened, and where all the other parts of IPv6 were independently proposed (and likely many of them rejected as unwanted).

frollogaston 2y ago
The main problem wasn't all the smaller features but one big one in particular that can't be split into smaller pieces, the new addressing scheme. They wanted to replace all the existing addresses, which meant replacing all the routes. Besides the difficulty of that by itself, it automatically meant that the v6 versions of DNS, DHCP, NAT, etc wouldn't support v4, rather it'd be a totally separate stack. There were also some small things. And routers often having bad defaults for v6, which btw, would not even be a concern if they left the big thing alone.
- JoshTriplett 2y ago
  > Besides the difficulty of that by itself, it automatically meant that the v6 versions of DNS, DHCP, NAT, etc wouldn't support v4, rather it'd be a totally separate stack. Sure, "make the addresses bigger" would have required providing DHCPv6, DNS AAAA records, and various other protocol updates for protocols that embedded IP addresses. And making changes to the protocol header at the same time (e.g. removing the redundant checksum) were also a good idea. It didn't require pushing SLAAC instead of DHCP. It didn't require recommending (though fortunately not requiring) IPsec for all IPv6 stacks. It didn't require changing the address syntax to use colons, causing pain for all protocols that used `IP:port` or similar. It didn't require mandating link-local addresses for every interface. It didn't require adding a mandatory address-collision-detection mechanism. And I'm sure I'm forgetting a few.
  - frollogaston 2y ago
    Yeah. I didn't like any of those proposed changes, especially the colons. You also didn't mention how NAT6 isn't a thing by default.
  - cyberax 2y ago
    It didn't require removing ARP and inventing Neighbor Discovery that embeds the hardware addresses into the IP address. It didn't require the Ruby Goldberg "on link" network mechanism. It didn't require multicast instead of broadcasts for local network discovery. It didn't require using DNS config (of all things) to specify V4/V6 priority. It didn't require adding a "flow label" that is nobody to this day knows how to use properly. The list of fails is ridiculous.

frollogaston 2y ago

The main problem wasn't all the smaller features but one big one in particular that can't be split into smaller pieces, the new addressing scheme. They wanted to replace all the existing addresses, which meant replacing all the routes. Besides the difficulty of that by itself, it automatically meant that the v6 versions of DNS, DHCP, NAT, etc wouldn't support v4, rather it'd be a totally separate stack. There were also some small things. And routers often having bad defaults for v6, which btw, would not even be a concern if they left the big thing alone.

JoshTriplett 2y ago
> Besides the difficulty of that by itself, it automatically meant that the v6 versions of DNS, DHCP, NAT, etc wouldn't support v4, rather it'd be a totally separate stack. Sure, "make the addresses bigger" would have required providing DHCPv6, DNS AAAA records, and various other protocol updates for protocols that embedded IP addresses. And making changes to the protocol header at the same time (e.g. removing the redundant checksum) were also a good idea. It didn't require pushing SLAAC instead of DHCP. It didn't require recommending (though fortunately not requiring) IPsec for all IPv6 stacks. It didn't require changing the address syntax to use colons, causing pain for all protocols that used `IP:port` or similar. It didn't require mandating link-local addresses for every interface. It didn't require adding a mandatory address-collision-detection mechanism. And I'm sure I'm forgetting a few.
- frollogaston 2y ago
  Yeah. I didn't like any of those proposed changes, especially the colons. You also didn't mention how NAT6 isn't a thing by default.
- cyberax 2y ago
  It didn't require removing ARP and inventing Neighbor Discovery that embeds the hardware addresses into the IP address. It didn't require the Ruby Goldberg "on link" network mechanism. It didn't require multicast instead of broadcasts for local network discovery. It didn't require using DNS config (of all things) to specify V4/V6 priority. It didn't require adding a "flow label" that is nobody to this day knows how to use properly. The list of fails is ridiculous.