On 11/04/15 10:27, Nick Hilliard wrote:
Uh, lemme just drop this in here: http://imgur.com/AYbpRG2
;o)
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.
Cheers,
Phil
