It has been awhile so prepare for a long entry.
At work, I was asked to summarize my customer engagements for the last few months. This list, which includes all of the customers I have worked with regarding IPv6 deployment, has a name, date, and summary of the various meetings and action items. As I read back through them all I realized that every one of them have 2-5 things in common. If you have attended one of my Cisco Live “Enterprise IPv6 Deployment” sessions somewhere on planet earth at some point over the past 8 years, some of these will sound familiar.
There are really three elements to what is happening in many enterprise organizations as it relates to IPv6 deployment:
- External Pressure
- Internal Pressure
- New Opportunities
Let’s look at these in a bit more detail. As the figure shows, the three elements have some kind of force (external, internal or both) as well as a potential for using IPv6 capabilities in a new technology, design or market.
External Pressure
Growth/Protection:
Many of the enterprise customers I work with are doing what any business does and that is to grow their business or at least protect what they have. I lost count on the number of enterprises that have already or are trying to take their businesses into emerging markets such as China, India, South America and other locales. While the business folks are trying to sort out demographics, pricing models, legal stuff, import/export rules, the IT folks are hard at working trying to get things connected. With the growing threat of globally routable IPv4 address exhaustion and the already tightly constrained access to this addressing in these emerging markets, enterprise organizations are either already being told “no” for new IPv4 addressing in these markets or fear they soon will be. Basically, if you want to continue to grow or if you sell your products or services on the Internet, IPv6 matters to you as you do not want to lose out on sales just because you did not support an IP protocol of which others in the world are using. This is an external pressure on the enterprise due to the IPv4 address exhaustion issue that can and is impacting their business today, not in two years, today.
Partnerships
I recently had the two most busy weeks of customer engagements I have had in probably 10 years. I met with over 18 major enterprise customers in about 10 days in very deep IPv6 deployment conversations. 1/3 of them were talking to me about IPv6 deployment for no other reason than them needing to peer with a partner organization (sub-contractor, manufacturing facility that makes stuff for them, Federal government contractor) that had already deployed IPv6 pervasively. Like a vendor RFI/RFP check mark, these customers were being told “this is the way we are going and in order to maintain good business continuity you need to go this way also. At least when talking to us via IP”. Again, this is an external pressure being applied when the enterprise account themselves may not have an immediate need for IPv6 deployment but those with whom they do business do. They must respond or threaten that relationship. This is really no different than a product vendor such as Cisco – if a customer mandates a requirement for a feature, Cisco can either ignore it and lose the business or they can support it and maintain the relationship.
Internal Pressure
Operating Systems and Applications
This is an oldie, but a goodie. I used to laugh at this one, but no more. My friends at Microsoft have done a stellar job of getting a very good IPv6 stack in Microsoft Windows 7 and Server 2008. They also shipped the OS with IPv6 enabled which was not the case in XP/2003, thank goodness. However, many enterprises are totally clueless of the fact that this is not just another client or server OS upgrade. The networking folks in IT are generally out of the loop on many OS upgrades as 1) they don’t own that part of IT 2) they traditionally have not cared. However, since Windows Vista and now with Windows 7 and Server 2008, there are boatloads of new and cool network-impacting features that all areas of IT should be knowledgeable about. Stuff I tested and wrote about way back when such as RFC1323 functions such as SACKs, Timestamps, TCP auto-tuning, and on the server side all of the RFC1323 stuff plus Compound TCP (CTCP) and many more. All cool stuff and all of it network impacting. But, if you don’t know about them, what they do and how they interact (or break) with certain network-focused components then you will pay dearly. An older PPT I did on the topic of Microsoft OS impact on the network can be found at: http://bit.ly/6EaIK1
This idea of assuming that just because a new OS (Windows, Mac, Linux, whatever) lands on your network, you don’t need to pay attention as it should not matter has never been more wrong than now with IPv6. For years, I never talked to a single banking or finance customer about IPv6 until they started ringing my phone off the proverbial hook over the last year. Many have discovered IPv6 on their networks via just basic link-local Router Advertisement (RA)/Neighbor Solicitation (NS) activity or full-on automatic tunneling behavior via Teredo or 6to4. Sure, you can kill this behavior if you know it is happening, but often it is happening and for a long period of time without any knowledge of the OS or networking teams. I recently talked to a customer who uses publicly routable IPv4 address space in their data centers and had recently upgraded from Microsoft Windows Server 2003 to Server 2008 R2. All went very well, everything worked, everyone was happy. However, they noticed that their network monitoring tools flat-lined on traffic that ‘should’ have been using IPv4. Since IPv6 was enabled by default and link-local addresses where created, these servers immediately started communicating on-link with each other over IPv6 via their link-local addresses vs. IPv4. In addition to this, since the hosts were using non-RFC1918 addressing, 6to4 interfaces/tunnels were formed which troubled them greatly. Everything still worked great, but the IT staff was going into a coma from not understanding that this is the default behavior. In the end, they were educated on it, learned their lesson (hopefully) and actually embraced IPv6, kept it in the OS, deployed many applications over IPv6 transport and are quite happy with their decision. Others may decide to kill IPv6 in the OS until they know what to do with it. But, again, an external force causing a knee-jerk reaction. This stuff is happening regardless of the vertical or market the enterprise is in.
The final point here is about IPv6-only solutions such as Microsoft DirectAccess. Microsoft does a great job of selling the idea of Microsoft DA to executives as an ease-of-use tool which then translates to those executives coming back and saying to their IT staff “thou shall deploy this”. The IT folks start working with it and realize that this thing is IPv6-only. Sure, my friend Sean Siler from Microsoft and his team did a killer job of allowing for a decision-process that allows for the client to determine if native IPv6 can be used or if some sort of encapsulation has to take place, but even with that, the application on the client and server needs to either directly support IPv6 or be protocol agnostic. Either way, the application requirements may be more robust than what the IT staff are prepared for. This creates friction with meeting the mandate or business requirement from the executive side and the ability to have the applications work over IPv6.
Fixing Old Problems
I am not going to spend much time on this as this topic could be a full series of blog entries on its own. The point here is that bunches of enterprises face IT issues with stuff like Mergers & Acquisitions (M&A) and one of the most irritating issues in that space is colliding RFC1918 IPv4 address space. Until one of the merged entities can be re-addressed (if needed) into the parent organizations address space, a common short-term resolution (which very often ends up being permanent) is NAT overlap. NAT overlap has been used for a long time by organizations all of the world. Basically, NAT overlap is when you create a NAT pool that uses a non-colliding address space that can be used to allow for endpoints and applications to be accessible between sites (such as reservation systems or other mission critical systems that both entities need to use immediately) until re-addressing solves the collision issue. Now, IPv6 and how it plays… I have had several customers come and say “we solved our M&A issue by creating an IPv6 overlay network that allows only those critical systems and users to communicate without this NAT overlap nightmare”. Very often they achieve this in a very rapid way as they leave their existing network as-is and deploy just enough IPv6 to get the job done which relieves the time pressure of mucking around with IPv4 to get it all to work with NAT overlap. They can then focus on dealing with the collision issues in the background while business continues on as usual.
New Technology
IPv6 is a greenfield opportunity and using IPv6 and its massive address space to deal with new technologies such as SmartGrid (not really an enterprise-specific topic but still cool) is growing. Also, the movement to large-scale Virtual Desktop Infrastructure (VDI) and specifically, Hosted Virtual Desktops (HVD) environments has left many customers in trouble as it relates to IPv4 space. This is true due to the fact that most HVD deployments (i.e. VMware View, Citrix XenDesktop) are additive in nature. With the exception of call center environments, most HVD deployments are adding virtual machine (VM) agents into the DC in addition to keeping the existing thick clients (PCs, Macs, other endpoints). When you glue together the IP addressing demands for thick clients such as PCs or printers, servers, IP Phones and now, VMs to serve as HVD agents, you end up with a boatload of hosts chewing up IPs. Right now, I have a MacBook Pro, with a VMware View client connected into our corporate data center, an iPad connected to a WebEx session and also my iPhone 4 connected to the corporate network all while I am listening to WebEx audio over my IP Phone. Do the math – that is a bunch of IP addresses being chewed up for one person. Multiply this and you can see the challenge in a large network. Customers are now telling me “if I went to IPv6, I resolve a bunch of issues I have with addressing. Yes, I have some short-term deployment challenges, but in the long run, I should be good to go, especially in my data center”. This glues together HVD + IPv6 which then challenges vendors such as VMware, Citrix and Cisco to fill the gaps.
I will have dedicated posts on this topic that are not just around IPv6 addressing, but also around the idea of how IPv6 can help increase the number of hosts-per-VLAN issue that many of the enterprise customers are testing and wanting to implement. Stay tuned.
Sorry for the long post but we will work from this baseline of drivers to walk through enterprise deployment over the next few weeks.
Cheers,
Shannon
