> Overall we are now much further into the IPv6 migration than djb ever envisioned.
That post was written 20 years ago. I would hope that the migration would be more than "much further along", I'd have hoped it had been completed, like a decade ago.
> is based on the same fundamental misunderstanding that one somehow can extend IPv4 in a way somehow, but remain compatible with IPv4-only clients
I'm not a network engineer, but I've seen loads of commentary from knowledgeable sources that it would have been quite possible to have extended the ipv4 address space without requiring 2 completely separate network stacks.
I think the simple fact that ipv6 includes so many other parts beyond just extending the address space shows what a foolish endeavor it was in the first place. I'm not saying the other bits aren't good ideas, but the only immovable factor that has people wringing their hands about ipv4 is the address limitation. If they had just focused on that, we probably wouldn't be in a situation where we're still running 2 network stacks virtually everywhere, and will be for the foreseeable future. The famous XKCD "Standards" meme says it best: https://xkcd.com/927/
I have yet to read any IPv6 alternative that can theoretically work or is not just IPv6 in disguise (or something that is implemented in IPv6 in a slightly similar fashion).
It may sound like a great plan as long as one doesn't look too closely at the details.
IPv4 has fixed 32-bit addresses and one cannot cram more than 32-bit of information into a fixed 32-bit field.
But one would need to do that for it to be forward compatible, since how would a IPv4-only client open communications with a expanded address space server?
One idea is to only upgrade the client and server and tunnel the expanded address space packets over IPv4. IPv6 has that - that's how it was bootstrapped before native IPv6 connectivity was a thing.
I believe the claim is that, IF IPv6 had been a much more minor modification of IPv4, including just a change to the packet structure to have a larger address field, it would have seen more adoption more rapidly than the current version of IPv6 which also changes everything else about the L2-3 stack. Sure, you would have still needed new devices and that would have taken some years, but as long as the network architecture remained the same, it wouldn't have required a quarter century to get to 30% adoption.
I don't know that I believe this claim at all, but it is at least coherent and possible (unlike claims that N-bit addresses could have been added to IPv4 in a backwards compatible manner). Perhaps SLAAC, the focus on routable end user devices etc were indeed major distractions that pulled focus away from a move to a new larger address space - which is the only thing people actually wanted from IPv6.
> which is the only thing people actually wanted from IPv6.
I'm not sure this is true. There's a lot of warts in the way IPv4 was put together (ARP is a tire-fire of badness for example), and the opportunity was taken to implement those in a better way. Lots of network engineers are very happy about that.
I don't feel strongly about it, but my reading of the complaint is that the implication is it should've been something like an address in 240.0.0.0/4 plus more bits. Then to IPv4 it looks like a reserved for future use address (and we declare we're done with IPv4 now, there will be no (other) future use) but to (this hypothetical variant of) IPv6 it's a longer address.
I think what annoys people is everything else that changed with it, if DHCP (I know), subnets, NAT if you wanted it, etc. was all just the same, if the model was the same the IPs were just longer now, that they wouldn't really complain.
I'm not even sure it would be necessary to put it in unaddressable v4 block, since it would be too long and a different version anyway. Obviously people have thought about this a lot more than me so know a lot more about it, I'm not naïve about that.
> That post was written 20 years ago. I would hope that the migration would be more than "much further along", I'd have hoped it had been completed, like a decade ago.
Yes, the IPv6 migration has taken much longer than anyone expected. But this argument would have made more sense in 2015 when we were looking at 5% IPv6 deployment and very erratic growth. But it's not, we've been looking at 10% of the market gaining IPv6 support for the last 3 years and are now at 45%. Now granted, this is likely to be largely "new" devices, e.g. in mobile networks and in countries like India where these were hidden behind CGNAT before. But these are exactly the type of devices that an IPv4 extension header couldn't have reached either.
That post was written 20 years ago. I would hope that the migration would be more than "much further along", I'd have hoped it had been completed, like a decade ago.
> is based on the same fundamental misunderstanding that one somehow can extend IPv4 in a way somehow, but remain compatible with IPv4-only clients
I'm not a network engineer, but I've seen loads of commentary from knowledgeable sources that it would have been quite possible to have extended the ipv4 address space without requiring 2 completely separate network stacks.
I think the simple fact that ipv6 includes so many other parts beyond just extending the address space shows what a foolish endeavor it was in the first place. I'm not saying the other bits aren't good ideas, but the only immovable factor that has people wringing their hands about ipv4 is the address limitation. If they had just focused on that, we probably wouldn't be in a situation where we're still running 2 network stacks virtually everywhere, and will be for the foreseeable future. The famous XKCD "Standards" meme says it best: https://xkcd.com/927/