Cost of IPv6 for IT operations team

[Jared Mauch]

> On Mar 27, 2015, at 9:37 AM, Jens Link <lists at quux.de> 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. 

This sure is true in an environment where humans are still the gating factor
in setting the machines up.  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’m reminded of this graphic:

http://www.geeksaresexy.net/2012/01/05/geeks-vs-non-geeks-picture/

This is true for many people stuck in the cut+paste world of configuring
devices, be they hosts or routers.

> 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.

Take ping/ping6 as an example.  One returns the IP being pinged, the other the
hostname.

puck:~$ ping puck
PING puck.nether.net (204.42.254.5) 56(84) bytes of data.
64 bytes from puck.nether.net (204.42.254.5): icmp_seq=1 ttl=64 time=0.012 ms
^C
--- puck.nether.net ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.012/0.012/0.012/0.000 ms
puck:~$ ping6 puck
PING puck(puck.nether.net) 56 data bytes
64 bytes from puck.nether.net: icmp_seq=1 ttl=64 time=0.022 ms
64 bytes from puck.nether.net: icmp_seq=2 ttl=64 time=0.030 ms
^C

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.

> 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].

Yes, this is the whole fun I’ve seen occur.  Some places, e.g.: 
www.thruway.ny.gov -> cname www.thruway.ny.gov when I report their
problems say “we don’t support ipv6” when i say “asking for aaaa you
send back SERVFAIL”.

This was interesting as it triggered a bug in the resolver of my ISP as well
so they responded from the unicast address of the host vs anycast.


>> 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. 

And these people need to be called out for not doing their jobs properly.

- Jared