Cost of IPv6 for IT operations team

[Benedikt Stockebrand]

Hi Andy and list,

Andy Davidson <andy at nosignal.org> writes:

> This is a strange question, but I think as a consultant I would want
> to design a rollout methodology that made that overhead (cost) as
> close to zero for your customer as possible.

that depends; in some cases you're far more interested in minimizing the
time to delivery, and then things look entirely different.

> Stage one - write v6 support requirements into RFP for equipment
> before you plan to turn it on.  Ideally this will be based on document
> RIPE-554 and be part of your buying process already (and have been in
> this process for at least the last buying cycle!)  This way, when you
> want to turn v6 support on, the incremental cost of your hardware
> support is zero.

That requires a lot of time.  Sure, if you've started this five years
before you actually deployed IPv6 then yes, the additional cost is
zero.

And yes, back in 95 there were allegedly people testing the hardware
they bought for being year 2000 compliant:-)

> Stage two - training, get a tunnel into the lab, make comfort with v6
> part of your technical appraisal for the technology teams, so that
> when it’s time to turn it on your team are familiar and will make
> fewer mistakes.

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.

This is especially bad if you're doing 24/7.  If you screw this up, then
"a tiny number of people" will be exceedingly busy figuring out that
(hopefully) the majority of problems are eventually unrelated to IPv6
while the rest stand around and watch until they can actually continue
with their part of the work.

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.

> Stage three - roll it out at your network edge, core & dns.  Yes this
> is a project which needs time management and planning and incurs cost.

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.

> Stage four - utilise your new training and v6 capable edge to roll out
> NEW services dual-stack.  The incremental cost of adding v6 support to
> a NEW rollout when you have to do a bunch of work to roll out a
> service at all is therefore zero.  v6 support for existing services
> can be added in product refreshes in time.

Just one semi-quote here: "That code has been running nicely without any
updates since 1999; the one last PL/1 (or Algol, or Cobol, or BS2000
assembler) programmer we still had fixed it up for year 2000 and then
retired."

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.

And aside from that you also assume that you have the time to wait for
at least one refresh cycle (more if there are inconvenient dependencies
between services).  As mentioned before that's way from universally
applicable.


In fact, coming up with a number for the effort needed to deploy or run
IPv6 involves a huge amount of work on the details.  For example, if an
in-house software development team has been smart enough to use a single
high-level library for all network operations, then the choice of that
single library from twenty years ago can determine if enabling IPv6 on
all in-house software happens automatically or involves pretty much a
full rewrite of the entire source base.

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


Cheers,

    Benedikt

-- 
Benedikt Stockebrand,                   Stepladder IT Training+Consulting
Dipl.-Inform.                           http://www.stepladder-it.com/

          Business Grade IPv6 --- Consulting, Training, Projects

BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/