Top 5 Misperceptions about Enterprise IPv6 Deployment - #2
We are over the hump kids. The No. 2 entry in this series has more to do with politics within the enterprise than it does with technical stuff.
It makes sense that because of where IPv6 falls into the OSI model that the network team would naturally claim ownership of its deployment. It is also true that without the network team building a scalable, available, secure and fast IPv6 environment that all other areas of IT would be ineffectual at best.
The point I am making with this is that often times the network team within IT will do the entire design and in some cases even start the deployment of IPv6 in complete isolation. Sure, they may rope in a few of their security folks for due diligence sakes, but that is often where it ends.
100% of the enterprise deployments that took way too long or failed completely were nearly all due to political issues where the network team did not include any other part of IT.
100% of the successful enterprise deployments I have worked with had a virtual team of representatives for all parts of IT. Even if those “other” people in ops, helpdesk, desktop, server, Active Directory, security, management, etc. only passively participate in the planning and deployment phases, they have to at least know what is going on.
I had an enterprise customer that suffered horrendous application performance issues that lasted weeks due to the network team deploying IPv6 from their access layer-facing VLANs in the campus and branch all the way across the network to the access layer-facing VLANs in the data center. The customer had very recently deployed Microsoft Windows 7 and Windows Server 2008 so the OSes were ready to rip with IPv6 day one. Someone from the network team had moved over to the AD and DNS team shortly after the network portion had been completed and started populating DNS with AAAA records for many applications in the data center without anyone knowing about it.
Fast forward a few minutes later and those Windows 7 clients that have IPv6-enabled by default got addressing from the network configuration, had DNS resolution for both the A and AAAA records for apps in the data center and the Windows Server 2008 boxes also had IPv6 addressing and BAM, we have a magical connection.
But wait, the security team and other teams had no clue what IPv6 was or that it was running in their environment and there were firewall rules in place in certain parts of the network that actually prohibited any protocol that was non-IPv4 from passing through.
So, we have client and server operating systems with addressing and name resolution as well as spotty end-to-end routability over IPv6. Glue that with applications that can run over IPv6 (i.e. Microsoft Exchange 2010) and you have the makings of a helpdesk nightmare. This is exactly what they got. Client connections and apps started hanging for minutes at a time, but it would not happen everywhere. The helpdesk start troubleshooting the apps and guess what else? They tested IPv4 connectivity, which was working perfectly. It took them weeks to finally figure out what had happened and to resolve the firewall issues.
Lost trust between teams? Check. More politically-charged meetings? Check. More isolation and siloed mentality between groups? Check. IPv6 gets a black eye because of the classic “I own IP” mentality? Priceless.
Don’t be egotistical and think that because it is IP that you can do everything on your own and expect a positive outcome.
