Cost of IPv6 for IT operations team

[Phil Mayers]

On 13/04/15 09:55, Benedikt Stockebrand wrote:

> Which is a major effort in some environments because---contrary to what
> Nick wrote---pretty much anyone involved needs to be familiarized with
> IPv6.  The reason here is that if there is any problem once IPv6 is
> enabled anywhere, then *all* people doing the troubleshooting need to
> know how to exclude IPv6 from the list of possible problem causes.

See, this makes sense - it's a reasonable assertion. But it's the 
opposite of what we've found.

In all honesty, I doubt a large portion of the organisation understands 
how IPv*4* works. If you think about one of the many areas v6 differs - 
ARP/DHCP versus ND/SLAAC/DHCPv6 - how many people *really* understood 
the former that well?

IME, not many.

So I'm a bit conflicted. What you say makes sense, but contradicts my 
experience. Still, data != sumof(anecdote) and all ;o)

> And as soon as you add a round or so of blame game, that "tiny number of
> people" will also have to communicate towards management that no, no
> matter what some other people claim, it isn't an IPv6 fault---which is
> exceedingly difficult since this situation usually leads to management
> turning towards the trouble ticket management system only to discover
> that (a) pretty much anytime anything went wrong IPv6 was somehow
> involved according to the paper trail and (b) time to fix has
> significantly increased due to this additional showstopper step.

OTOH, we often find the network blamed for basically everything. So this 
is only a small extension ;o)

> In an enterprise network that's actually a minor issue compared to
> e.g. the business applications that need to be fixed up, or the overdue
> OS updates that need to be deployed.

+1

> While it's really convenient to use product refresh cycles to enable in
> some cases, from what I've seen at least in enterprise environments this
> frequently doesn't work as a general approach.

What problems have you seen? Insufficiently demanding RFP or lack of 
awareness of the need to put it in an RFP? Or something else?

> In other words, just because someone claims some number measured in one
> specific environment doesn't mean anything at all to yours.

Very strongly agreed.

At this stage of "IT support" as a profession - encompassing the 
technology, tools, management structures and so forth - it's clear to me 
there's huge variation, making any comparisons dangerously close to 
apples/oranges.

Cheers,
Phil