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
