Cost of IPv6 for IT operations team

[Ted Mittelstaedt]

All of this assumes "normal hardware refresh cycles"  That may be the 
case for ordinary office users but I got a million dollar asphalt kiln 
attached to a Windows 98 controller with a serial port that says
otherwise.

Just wanting to point out that "normal hardware refresh cycles" more 
often comes out of the mouth of the salesguy wanting to sell you
something than out of the network manager.  Most of them will say "if it 
ain't broke don't fix it" first.

And switching infrastructure tends to be pretty bulletproof if you
buy good hardware to start with.  I've got a lot of customers with 
switch infrastructure that hasn't changed in years.

"normal hardware refresh cycles" is something the Fortune 1000 have. 
It's a nice concept but not one universally adopted by everyone else in 
the real world.  Another one of these is "hardware service contracts" 
That's not universally adopted, either.

Ted


On 4/2/2015 3:04 AM, Mikael Abrahamsson wrote:
> On Fri, 27 Mar 2015, Phil Mayers wrote:
>
>> I don't believe the rollout cost was high. We used refresh cycles to
>> upgrade to v6-capable gear, and rolled out slowly to grow our team
>> knowledge. But we don't have detailed cost breakdowns.
>
> This is my experience as well, if someone already has decided to employ
> skilled people and tell them (or gave them fairly free hands) to have
> IPv6 enabled on most services in the "next few years", then this will
> happen without very little extra cost.
>
> If one decides that "We need IPv6 on services in the next 6 months" then
> there'll be lots of extra truck rolls and immediate capex and opex if
> this has not been taken into account previously.
>
> It takes 3-5 years to get IPv6 running with minimal extra cost, then it
> can be done as part of normal hardware refresh cycles and slowly
> increasing exposure to IPv6 by staff. So the entities who have not
> started yet and want to get started quickly will have to face increased
> cost.
>
> I was involved in IPv6-enablement of a fairly large ISP and in 2007-2010
> most of the groundwork was done going full native IPv6 instead of
> tunnels etc, testing all platforms, working bug cases with vendors that
> had software bugs, waiting for the fixes, testing again, then looking at
> the next aspect like IPv6-enabling one of the services with friendly
> users, run that for a while, then turning on more customers, enabling
> more services etc. The earlier one starts, the more can be done over
> normal upgrade cycles of software, you can help the vendor to get
> everything done in a way that'll actually for for you.
>
> Another strategy is to wait until everybody else has done this work and
> hope you were in luck with the things you purchased and that it'll just
> work out of the box without any preparation. This is also a valid
> strategy, as long as not everybody does this :)
>