The Department of Work and Pensions, UK has an entire /8
george.herbert at gmail.com
Thu Sep 20 20:18:58 UTC 2012
On Thu, Sep 20, 2012 at 7:10 AM, Joe Maimon <jmaimon at 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
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
> 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
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
This is a classic market window failure. It's not just engineering.
Timing is ultimately just as important.
-george william herbert
george.herbert at gmail.com
More information about the NANOG