On Thu, Sep 20, 2012 at 7:10 AM, Joe Maimon <jmaimon@ttec.com> wrote:
George Herbert wrote:
We could have started it at a more opportune time in the past. We could also have done other things like a straight IPv4-48 or IPv4-64, without the other protocol suite foo that's delayed IPv6 rollout. Operators could have either used larger baseball bats or more participating numbers to make some IPv6 protocol design go the other way. IETF could have realized they were in Epic Fail by Too Clever territory.
All of these things are water under the bridge now. We have what we have. It being amusing to grouse about mistakes of the past does not magically change the present. We have rapidly vanishing IPv4 and no 240/4, IPv6, and no time. That is reality.
Pining for 240/4 fjords is not a time machine to change the past.
What is not amusing is continued evidence that the lessons from this debacle have not been learned.
Or that other past lessons are being forgotten.
Baking in bogonity is bad.
Ok, but the bogonity is baked in in two areas already; both 240/4 and IPv6. 240/4 is baked in (or out) of IPv4 on a large quantity of deployed firmware and devices, and larger quantity of local OS IPv4 stacks. The local OSes are, as a rule, upgraded on 2-3 year timelines and patched in many cases something like annually or every few months. Firmware, less so. As someone else pointed out, a lot of those devices are not under support anymore or from now defunct vendors, so a hardware replace is the fix. IPv6 was also baked out of a large quantity of deployed firmware and devices, and OS stacks. This has largely already been remedied, and people are largely aware that device firmware that's not upgradable needs replacement, so the fix is mostly in and already most of the way through happening. In both cases, a roughly 7-10 year total process in practice; in one case, we're already 5-6 years of serious effort in to it. Do you understand the difference between starting a 7, 8, 10 year process fresh from zero right now versus continuing one we're nearly done with?
Predicting the (f)utility of starting multi-year efforts in the present for future benefit is self-fulfilling.
No. This is a classic techie-makes-business-failure problem. You are not creating products for today's customers. You're creating products for customers who will be there when the product is ready. You're not creating a product to compete with today's products; you're competing with the products that will be out when it's done and shipping, and that come out subsequently. This is what "market window" is all about.
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?
We're somewhere around 2/3 of the way through on the IPv6 changes. We haven't started a 240/4 activation project yet. We have found while doing the IPv6 that there are some glitches; a very few of them at protocol level, with so-far tolerable workarounds or adjustments in expectations. A lot of them at operational process and usage levels. A lot more of them at business / user levels. There's a difference between "IPv6 doesn't work" and "IPv6 is not perfect". IPv6 is deployed, running nationally, represents 0.6-1.0% of active IP traffic right now to big websites depending on who you talk to (Google was 0.6% I think, Wikipedia reporting 0.8% on an internal list a couple of weeks ago, etc). It's obviously not "doesn't work" as it's showing functional IPv6 traffic levels that approximate those of the whole Internet 15 years ago. It's obviously not perfect. It's asserted that the operational problems are big for a number of sites, but others are making it work. We'll have to see on that. In any case, it's not 7-10 years away from working. Even if we have to respin a support protocol (DHCPv6.1, anyone?) the core protocol and most of the stacks and the routers and devices probably wouldn't need replacement. Someone who objects to current operational issues is likely to eventually (soon) just write code rather than wait for arguments to settle and the protocol wizards to pronounce. Running code trumps theory and argument. If you think you can accomplish a full 240/4 support rollout across the world's devices and infrastructure faster than we can get IPv6 running, I would suggest that you reconsider. It's an easier fix at one level only - the code in the stacks that needs changing is relatively minor. Even if the protocol and code changes were completely done tomorrow by magic, the deployment phase, all 5+ years of it, is starting at zero. IPv6 is deployed; not universally, but most of the way through. We're shaving operational issues with the protocol and support protocols off now, and dealing with deployments into slow-adopters. IPv6 is able to be operational for many people now; 240/4 would not be operational for anyone in a safe sense until 2017-2020. This is a classic market window failure. It's not just engineering. Timing is ultimately just as important. -- -george william herbert george.herbert@gmail.com