Cost of IPv6 for IT operations team

[Jens Link]

Jared Mauch <jared at puck.nether.net> writes:

>>   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. 
>
> This sure is true in an environment where humans are still the gating factor
> in setting the machines up.

Sure. But unfortunately that's the majority of customers I work for. 
 
> Where some amount of automation or database driven configuration exist
> (and i define database loosely) it will not be measurably more.  The
> initial investment in the tooling/scripts/magic is the cost.

I helped implementing IPv6 for a big German website (well two but the
same network, the same servers,  same admins, same tools, different
developers) back in 2012. The Admins new their infrastructure,
developers knew their  code, almost everything was automated. And most
important:  They worked together, exchanged knowledge. After three month
everything was ready and there was not much extra work that had to be
done. Most work was on the development side (numbers with three dots in
between is not a very good regexp for finding valid IPs and integer is
most likely to small too save IPv6 addresses to a database).

On the other hand I know many enterprises / universities / ISPs / ...
who don't automate things. Everything is done manually and any many
tasks are just copy'n'paste (and if that fails they have a problem
because they don't know what they are doing). One of them is using
2001:db8::/32 internally (well with a typo in the db8 part). They do
have IPv4 PI. They could easily implement IPv6 PI. They don't want
to. They got used to the problems they have.

In the last couple of month I worked on two projects where I really
liked to have used some config management system like puppet, saltstack,
chef, ... The admins at the customers had heard that such tools exists
but haven't had time to decide which one to use. And IPv6 was absolutely
no topic (I got "Well the data sheet for the server says that it supports
IPb6 that's enough" and "No we don't need IPV6" as reply when I asked
about it.)

>> 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. 
>
> I think there are some issues here due to the divergent functions of tools.

Not only that. Remembering that there are two different protocols would
be a first step. Not blaming IPv6 when you only see IPv4 traffic in a
wireshark trace the next. 

Talking to each other is also important. One of my favorite examples: 

http://blog.quux.de/?p=1542

> This means understanding how the tool works.  I find this is a skill often
> missing, and the subjective reasoning.  This is difficult to teach but is
> unrelated to IPv6.

Troubleshooting is an art. And many people lack the basic
knowledge. Don't get me started about DNS problems, ssh-keys, monitoring
(or the lack of monitoring), updates, ...
 
>> [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. 
>
> And these people need to be called out for not doing their jobs properly.

But they won't listen to us. They probably would listen to their boss
but he (or she) doesn't know any better. 

Jens
-- 
----------------------------------------------------------------------------
| Foelderichstr. 40   | 13595 Berlin, Germany           | +49-151-18721264 |
| http://blog.quux.de | jabber: jenslink at jabber.quux.de | ---------------  | 
----------------------------------------------------------------------------