Cost of IPv6 for IT operations team

[Ted Mittelstaedt]

I don't think that having "things" in the mix extends troubleshooting.

My experience is that problems generally fall into 2 buckets:

1) Textbook ones (mistyped IP address, overload that's readily visible 
if they had looked at the reports, or like you said full hard disk)

The time-suck in these are techs who aren't very experienced, or skilled 
or organized (or all the above)

With these, adding more stuff seems like it extends troubleshooting - 
but the real reason troubleshooting is extended is not because you added 
more stuff it's because your troubleshooting staff isn't up to snuff.

Kind of like you drafted Billy Joe Bob from Hayseed to troubleshoot your 
2015 Chevy Volt and it extended the time troubleshooting because he's 
still looking for the carburetor.

People only blame the car for that because they don't want to face old 
Billy Bob and say 'dude your incompetent, hit the books or get the F out 
of the business"

We live in a complex world that's getting more complex every day.  If 
you want to be a tech, then deal with it, up your game. When your 
spending the same effort hitting the books as you are playing Warcraft 
then I'll have some sympathy.  Otherwise go join the line of people 
sucking off the social services.

2) really knotty ones that take a lot of time, like intermittent failures.

With those, it's very hard to draw correlations.  I have seen some very 
simple, basic, 1-protocol setups that had really oddball problems that 
took a great while to track down.

Just my $0.02

Ted

On 3/27/2015 6:37 AM, Jens Link wrote:
> Ted Mittelstaedt<tedm at ipinc.net>  writes:
>
>> But as for operations costs, I would say, zero
>
> I don't agree. In a dual-stacked environment there is more work to do.
>
> 1. Setting up Servers (and Services)
>
>     You have at least two addresses to configure, which leads to two DNS
>     records, two services to be monitored, more firewall rules, ... And in
>     the end more things to document.
>
> 2. Troubleshooting
>
>     When looking for problems you always have to remember that there are now two
>     protocols and then the fun begins: Is this problem only v4? Or only
>     v6? Or do have a completely different problem.
>
> 3. Layer 8+9
>
>     People have little or no experience with IPv6. They need more time to
>     configure stuff and troubleshoot problems. And they will forget to
>     configure one thing or the other and they will forget that there are
>     two protocols to troubleshoot.And then there will always be people
>     who don't want IPv6 an will always blame it[1].
>
>> The reason is if you don't deploy sooner or later you will have a
>> problem related to IPv6.
>
> Ack.
>
>> Then you will spends lots of time finding and correcting.  That time
>> is roughly equal to the extremely small amount of additional time that
>> the techs deal with IPv6 on a network that has had it properly setup.
>
> It will be worse. When you start implementing IPv6 because the latest
> version of your critical application requires IPv6 and you need IPv6
> tomorrow you'll have a real problem. You have to touch many things at
> once, you may have to buy hardware and you'll be looking for qualified
> external support. Problem is: Many other companies will do the same.
>
> I'll have to remember to buy a big stash of T-Shirts with "Told you so!"
>
> Jens
>
> [1] Someone told me a story about a database server which stopped
> working after IPv6 was deployed. The DB amdin blamed the IPv6
> deployment. Of course it hat nothing to do with IPv6, the hard drive was
> full.