Cost of IPv6 for IT operations team

Phil Mayers p.mayers at
Mon Apr 13 13:55:21 CEST 2015

On 11/04/15 10:27, Nick Hilliard wrote:

> Uh, lemme just drop this in here:


> The problem with stage 4 is that it requires that the expertise garnered by
> the initial deployment team is spread throughout the rest of the company,
> ranging from product development to the FLS desk, right through to
> customers.  This is a prolonged and time-consuming process, and
> consequently expensive.  I'd love to see a larger scale discussion about
> this, because it's one of the main blockages for ipv6 adoption and
> discussion of live cases would help other organisations make the jump.

University environment here, fully dual-stacked everywhere.

Interestingly enough, we've not done a huge amount of training across 
the rest of the IT support function. It was always intended, but it's 
actually surprisingly rare to need to refer to an IP address - v4 or v6 
- when troubleshooting problems. MAC addresses are, generally, far more 
useful, and with v4/v6 ARP/ND tracking, give you the IPs.

We have spread some knowledge into our "infrastructure applications" 
team - exchange, webservers, etc. - and that's been fine.

We've had a lot less luck spreading the knowledge into the teams which 
deal with COTS application stacks e.g. Oracle. The problem there is the 
"upstream" support - if Oracle don't certify or deploy on IPv6, the 
people running that stack have no interesting in doing so.

The major thing is "don't forget to configure the IPv6 vhost". But by 
dual-stacking everyones desktop, including the developers, that gets 
picked up early.

For supporting client connectivity (desktops, laptops) we've not found 
the protocol differences very relevant. MAC address on wired, 802.1x 
username on wireless or MAC if it's an auth-level problem.

We just haven't found it a problem. Maybe it's a University thing. I'm 
sure consumer ISPs have a much harder time.


More information about the ipv6-ops mailing list