Let us spin this another way. If you cannot even expect mild change such
as 240/4 to become prevalent enough to be useful, on what do you base your optimism that the much larger changes IPv6 requires will?
Joe
Easy - Greater return on the investment; i.e. - instead of getting an IPv4 /4 out of the effort you get an IPv6 Global Unicast Space of 2000::/3 (just for starters, counting neither the rest of the unicast nor multicast, etc. spaces.).
::/3 /48 /64
Do you think we may ever come to regret baking that in? And use that regret to torpedo any attempts at change?
If we do ever grow to regret the /48 and /64 splits, I guess it is a good thing we have 5 more /3s to deal with it ...
As far as roi is concerned, we can make all the calculation we want. What we cannot do is force everyone else to come up with the same numbers we did.
We also cannot make everyone happy all of the time. We can only do the best we can, and make it work as good as we can. Such is life.
Also, the impact of the "changes required" is close to the same in that
every node needs to be touched - that is the hard part, getting updates deployed. *(Unless you want 240/4 to be a special/limited use case - in which case the effort is smaller, but so is the reward ...)*
The scope of the change is far far different, no matter the use case. Never more than a simple update.
Yes, but making a change (regardless of size) on a given platform is often dwarfed by the effort of getting the update pushed out, to every possible instance of said platform. Multiply that by the number of platforms ... With IPv6, it is a bigger single change (in code terms), but the hard part (deployment) is roughly the same order of magnitude in deployment. It is also easier to know if your platform is in an area that now has IPv6, vs a router discovering whether or not the hosts understand the new /4. That is, dual-stack (IPv4 + IPv6) create fewer problems than the coexistence of nodes supporting 240/4 and not supporting 240/4. And again, an additional IPv4 /4 is *just a bit smaller* than what IPv6 brings to the table ... /TJ *... all IMHO / IME, of course.*