3 ms·

The #1 mistake IETF did was not making IPv6 compatible with IPv4. It's hard to comprehend for most, bug essentially we're building a whole new separate Internet

The #1 mistake IETF did was not making IPv6 compatible with IPv4. It's hard to comprehend for most, bug essentially we're building a whole new separate Internet. The old Internet, or the Internet Classic (v4) and the New Internet - The v6 Internet. IPv6 is a totally new protocol - new L2 interaction with Neighbor Discovery (i.e. has no concept of default gateway), new routing tables, new route-maps, nes access lists, new BFD,... Therefore new topology, new routing behavior, new resiliency and redundancy mechanisms... Just because hardware allows running v4 and v6 stacks side by side, it doesn't make them compatible, just easier to implement by not having to buy new hardware for both.

nextweek2 9y ago
I have to disagree with you there, making it compatible would have meant carrying legacy work flows. With a greenfield development they could engineer purely with an eye to the future. Coding for a mix of paths creates a 3 way test problem. You have to test purely legacy, the mix of legacy and new and then just the new. You suddenly have to start coding for runtime depended details.
hn_throwaway_99 9y ago
I completely agree. I think the whole move from v4 to v6 should be a case study in exactly how industry-wide technology migrations should not be done. The only thing that was the critical flaw in v4 was lack of address space. Yes, there are obviously a lot of other issues with v4, but instead of just fixing that one critical flaw, v6 suffered from classic scope creep, put in the kitchen sink, in a way incompatible with v4, and 2 decades later we're still 5 years away.
deathanatos 9y ago
> making IPv6 compatible with IPv4. This gets suggested and rehashed on every single IPv6 comment section. There is no way to make IPv6 compatible with IPv4: by the Pigeonhole principle, there is simply no way to reference 2 ^ 128 objects using only 32-bits. The next usual hack is to "add an option" or something; but all the routing hardware would need to understand that option, which entails upgrading the entire Internet, which is exactly what IPv6 is doing/has done, except that adding an option ends up with a worse design. Any suggestion needs to fulfill a. any machine should be reachable and b. you can't upgrade everything, or you may as well just go with what we've got.
- akvadrako 9y ago
  I don't think even many of the IPv6 designers would agree with you. Originally, IPv6 was supposed to bring a large set of improvements, like first-class encryption, larger minimum packet sizes, stateless addressing and auto-configured routing. It wasn't just more bits. In the end either all those things were backported to IPv4 or turned out to be bad ideas. IPv6 ended up being just more bits, but with a fully incompatible implementation. If they had known this at the beginning, we could have transitioned to IPv6 long ago, by designing for a smooth transition period and reusing as much of the IPv4 stack as possible. An end-to-end extension header would have been simple - something that can fallback to NAT connection tracking when it's not recognised. And it would have saved man-centuries of effort.
TorKlingberg 9y ago
You cannot make it fully and magically compatible. 128 bits do not fit in 32 bits. They did make it compatible in a whole bunch of ways, like making v4 addresses a subset of v6, and tunnelling v6 through v4, but that seems to have just caused trouble and confused things.

nextweek2 9y ago

I have to disagree with you there, making it compatible would have meant carrying legacy work flows. With a greenfield development they could engineer purely with an eye to the future. Coding for a mix of paths creates a 3 way test problem. You have to test purely legacy, the mix of legacy and new and then just the new. You suddenly have to start coding for runtime depended details.

hn_throwaway_99 9y ago

I completely agree. I think the whole move from v4 to v6 should be a case study in exactly how industry-wide technology migrations should not be done. The only thing that was the critical flaw in v4 was lack of address space. Yes, there are obviously a lot of other issues with v4, but instead of just fixing that one critical flaw, v6 suffered from classic scope creep, put in the kitchen sink, in a way incompatible with v4, and 2 decades later we're still 5 years away.

deathanatos 9y ago

> making IPv6 compatible with IPv4. This gets suggested and rehashed on every single IPv6 comment section. There is no way to make IPv6 compatible with IPv4: by the Pigeonhole principle, there is simply no way to reference 2 ^ 128 objects using only 32-bits. The next usual hack is to "add an option" or something; but all the routing hardware would need to understand that option, which entails upgrading the entire Internet, which is exactly what IPv6 is doing/has done, except that adding an option ends up with a worse design. Any suggestion needs to fulfill a. any machine should be reachable and b. you can't upgrade everything, or you may as well just go with what we've got.

akvadrako 9y ago
I don't think even many of the IPv6 designers would agree with you. Originally, IPv6 was supposed to bring a large set of improvements, like first-class encryption, larger minimum packet sizes, stateless addressing and auto-configured routing. It wasn't just more bits. In the end either all those things were backported to IPv4 or turned out to be bad ideas. IPv6 ended up being just more bits, but with a fully incompatible implementation. If they had known this at the beginning, we could have transitioned to IPv6 long ago, by designing for a smooth transition period and reusing as much of the IPv4 stack as possible. An end-to-end extension header would have been simple - something that can fallback to NAT connection tracking when it's not recognised. And it would have saved man-centuries of effort.

TorKlingberg 9y ago

You cannot make it fully and magically compatible. 128 bits do not fit in 32 bits. They did make it compatible in a whole bunch of ways, like making v4 addresses a subset of v6, and tunnelling v6 through v4, but that seems to have just caused trouble and confused things.