Cost of IPv6 for IT operations team

Jared Mauch jared at
Mon Apr 13 21:11:53 CEST 2015

> On Mar 27, 2015, at 9:37 AM, Jens Link <lists at> wrote:
> Ted Mittelstaedt <tedm at> 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:

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

puck:~$ ping puck
PING ( 56(84) bytes of data.
64 bytes from ( icmp_seq=1 ttl=64 time=0.012 ms
--- 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( 56 data bytes
64 bytes from icmp_seq=1 ttl=64 time=0.022 ms
64 bytes from icmp_seq=2 ttl=64 time=0.030 ms

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

More information about the ipv6-ops mailing list