IPv6 as a protocol has been known for a while, but enterprises are beginning to understand the ways in which it can help them achieve their goals, improve efficiency and gain functionality that were hitherto unavailable.
When the IPv4 to IPv6 transition first took place, some Internet-scale companies enthusiastically adopted the technology. They built out their data centers as IPv6-only networks understanding the impending exhaustion of IPv4 addresses. Most other companies attempted to manage the transition by simply migrating from native IPv4 to a dual stack network for IPv6 compatibility. This, however, neither saved IPv4 addresses nor improved features and applications over IPv6. The logical next step for those companies and indeed the industry, in general, is to implement entire campuses as IPv6-only networks. The advantages include avoiding the maintenance of two protocol stacks, reduced OPEX, and, chiefly, no more dependency on IPv4 address. The IPv6 network is cleaner, faster and more secure thanks to a protocol redesigned to embrace encryption, favor targeted multicast over expensive broadcast communication and remove variable length subnets from routing.
Cisco has been one of the early pioneers in this space. From an implementation and adoption standpoint, we have taken it upon ourselves to start building an IPv6-only campus to demonstrate to our customers not just the criticality of this technology but also how exactly to manage the transition seamlessly.
The Cisco Enterprise Network Engineering team, in collaboration with the Cisco IT team, took the lead in converting Building 23 (known internally as “The v6 Island”) in San Jose, California to an IPv6-only network. The building, serving over 500 employees with at least two devices per person, over 120 access points and 20 network devices, accessing nearly 20 IPv6 applications and three collaboration endpoints per device, went live with the transition shortly after the new year began. As committed as we are to innovation, we also sympathize with early adopters of emerging technologies. As a consequence, we turned lab rats, as it were, in building an IPv6 campus. The goal was to demonstrate how to navigate the growth pains of such a revolutionary transition with a clear and near upside.
This transition has been one of our coolest projects, and it is very exciting to have the opportunity to roll out the first-ever true IPv6-only building in the industry servicing the typical daily business traffic of a large enterprise. Despite this excitement, the changeover to a pure IPv6 facility has been herculean in terms of ensuring non-disruption of critical services. Cisco users interact daily with diverse Enterprise applications – many designed without IPv6 in mind – and they expect to get their jobs done from any platform, anywhere. This meant network plumbing – writing a translator for domains that are still running on v4, customer-centric practices like engaging with multiple users and being proactive to enable a wide range of devices (we are proud proponents of BYOD). Despite these challenges the project was all wrapped up in three months and the results speak for themselves. The IPv6 user count has consistently been at 450+ users daily with traffic throughput measuring an average of 400 mbps.
Adoption of a new technology is difficult and most technologists wax eloquent about initial reluctance. As we strive to be adopters and advocates for IPv6 as the way of the future, we have successfully implemented our own solution to demonstrate what an IPv6-only building is capable of. As we gain momentum towards v6 enabled collaboration and mobile-based adoption, it is our hope that our v6 implementation acts as a lighthouse and guides you on your v6 journey. Learn more about our IPv6 journey in this video. https://youtu.be/BRunKoc2hnc
Would love to hear about your IPv6 stories @aoswal1234.
The performance statement is interesting. As a tester of IPv4 and IPv6 capable routers I see that the IPv6 performance is much less than IPv4 given the same router configuration and traffic profile. Just wondering how IPv6 performance in 23 was measured and how it compares to IPv4 numbers under the same configuration.
Hi Steve, IPV6 only deployment we eliminate the overhead due to NAT translation needed to convert internal IPV4 address to external address. This will help reduce latency and get the overall end user performance enhanced.
In building 23 we are already seeing improved performance for IPv6 native traffic today, (mostly to the internet) we often see better performance than IPv4 (response time, DNS resolution, bandwidth).
-Loghs
Howdy so when I compare performance of let’s say QoS IPv4 vs QoS IPv6, IPv6 always has lower performance. NAT is not used in this case. Here’s an example of the data that the unified performance team collects:
http://up-tools.cisco.com/upm/#/visualization?reportID=58b59fd1e4f761792bd7f2dc
As part of employee in Bldg-23, we have been part of this transition. After initial hiccups (mostly due to issues on MAC side), the experience have been smooth on Mac and iPhone. In general, transition to IPv6 has been slow in world because of various technologies to help with exhaustion of IPv4 addresses. However as we enter in the world of 50 Billion devices, IPv6 usage is about to explode and hence such transitions and Cisco-on-Cisco is very critical for Cisco to be in fore-front of this.
Remarkable feat indeed!
Would love to attend a nerd lunch that gets into the engineering details of how this was orchestrated and problems that the team ran into with our switches/routers, details of domain translator etc. What would help from a monitoring perspective etc.
It will be very inconvenient for lab equipment. Most development activities are done in IPv4.
Hi Jim,
Connecting the IPv6 building to IPv4 lab is a big part of this transition and where most of the supporting effort is. In this effort, we tested each work flow who use different applications including lab access, we found as long as the IPv4 host has a DNS name, NAT64/DNS64 can smoothly take care of it; we also have a solution for hosts only have IPv4 address, by auto-converting the IPv4 address to a DNS host name, replacing the “.” to “-“, e.g. 172.12.12.12 becomes 172-12-12-12, then it can be reolved and routed by DNS64/NAT64. If you have more question around this, please feel free to drop a note to cisco-ipv6-transformer@cisco.com. -thanks, Mei
Hi Jim,
Thanks for the comment. You are quite right that this change pulls other changes in its wake. Usage of IPv4 numerical addresses to access services (for example “ssh user@10.1.1.1” or “vnc://172.36.10.10”) are common in lab usage but become unusable in an IPv6 environment as we can’t use the IPv4 address anymore and IPv6 literal address as long and cumbersome to remember.
This all leads to a migration to Named Based addressing – access all services with names such as “ssh user@mylabhost” or “vnc://mylabdesktop.cisco.com”. Its always hard to change habit, but its only a matter of time. We are messaging to lab admins and teams to implement naming (and have a tool to auto/bulk name upon request) as well as implement pervasive IPv6 in labs.
This is an amazing journey for sure and I have been part of many initial discussions towards the IPv6 enablement and agree with Anand. The best way to move forward is to aim towards IPv6 only infrastructure building. It may take some time to get to optimal points but its worth investing the time and money. Nice informative blog as always Anand.
Awesome feat. I’m really glad we started converting building to IPV6. More and more customers and ISPs are using IPv6 and most mobile apps support IPV6 these days.
Let’s master the conversion process and take it to other buildings/campuses and help our customers do the same as well.
Internal Nerd lunch will be helpful.
We also need to drive IPV6 adoption in our labs. Cisco on Cisco is a very powerful marketing tool.
Awesome achievement to transition to a completely IPv6 network. Cisco should lead this transition in the industry. We recently added IPv6 support for the Plug-and-Play solution so that a device can be on-boarded and deployed by customers like Reliance and NGENA who operate pure IPv6 networks.
For Cisco, there still are gaps in promoting IPv6. For example, by default IPv6 is not enabled on the interfaces in most of our platforms. Only IPv4 is enabled. This is one of the limitations we had to overcome to enable Plug-and-Play over pure IPv6 networks.
v6 migration is real and more importantly a need now in the IoT world! This is a great example of a deployment inside Cisco to showcase to the field. Awesome collaborative job by the ENG alpha team and Cisco IT to make this happen!
Great to see Cisco leading changes by taking actions. Well done and welcome to the IPv6 only world!
(reposting. I was not logged in the system)
Great to see Cisco lead the IPv6 Technology transition, Anand. Looking forward to seeing more enterprises around the world start making this transition as well to leverage all the benefits that we’ve started seeing in building 23.
Great to see a real world implementation of IPv6 in our own backyard. Looking fwd to more metrics from Bldg 23 IPv6 usage in the coming weeks. True instance of “Eating your own Desert” (not dog-food)
Amazed!
While it is good to see many positive feedback, it is known to many people in BLD#23 that there is huge frustration about “alpha”SSID. This is evidenced that people even are starting to put up private WIFI hotspot around using D-Link, Netgear consumer boxes. It is a pain when you are in discussion during the meeting, the connection is gone; when you have idea how to fix bug and want to try, VNC session is frozen!#$%@*&!
When will it be in production quality?
While we had a few initial teething issues, the IT team and alpha team have addressed the issue now. Earlier, not all applications internally had a Nat64 translation enabled, but now we have it all in place.
Also, please note all applications in the laptop are not V6 ready and they need to be upgraded to the latest version for them to seamlessly work in the network. Please look into this link to get the IPV6 compatible versions for various applications.
If you still have more questions please reach out to cisco-ipv6-transformer@cisco.com.
-Loghs
Kudos to the ENG Alpha team and Cisco IT for making the transition happen. Really interested to learn how the deployment was phased. Concise write up & video clip !
Nice. Yes, IPv6 is there from long time but migration to IPv6 is super slow. It would be interesting to see how Cisco drives their customers to adopt such solutions. Great job everyone 🙂
Now you just need to take this philosophy and leadership to the Netacad material. Nearly all the labs/reading are still very IPv4 heavy.
I am network admin, handle both cisco and non-cisco devices, both wired and wireless. I would like to access the documentation for this validated design. Will there be any additional cost for this solution? To be frankly speaking, it is actually a mess to handle both ipv4 and ipv6 and support variety of v4 and v6 applications in an small enterprise. Please provide the cisco link for this validated design. Good job and thank you very much.
Please reach out to me directly losriniv@cisco.com and I can help you on this
– Loghs
That’s what I call a great example of Cisco’s leadership. Agree 100% with the IPv6’s implementation. I personally like to take the advantage of challenges to improve better solutions, that’s the flavor of technology. Congratulations ENG alpha team and Cisco IT to make this happen!
What code are you running on your Wireless LAN controllers? As far as I was aware you aren’t shipping any IPv6 only code for them yet.
We are using the latest WLC code which supports Capwap over IPV6 for Wave2 & Wave1 APs
Nice article Anand on a great journey to IPv6 and kudos Alpha team for all your efforts. You guys are awesome.
Great work! Did you tackle the building infrastructure such as HVAC, door controls, security cameras?
Also, where do you put the NAT64 gateway – at the/each building, in the network core, or at the Internet edge?
We have migrated the building users and network infra as part of the transition. This didn’t include HVAC/Door Knobs. The Nat64 is is at the site/network core of the campus.
Hi,
This looks very interesting.
I did try emailing the address in the infographic to discuss further, but got a bounce back:
This is a delivery failure notification message indicating that
an email you addressed to email address :
— cisco-ipv6-transformer@cisco.com
could not be delivered. The problem appears to be :
— Recipient email address is possibly incorrect
Additional information follows :
— #5.1.0 Address rejected.
This condition occurred after 1 attempt(s) to deliver over
a period of 0 hour(s).
Tim
Sorry about that, We are fixing this to receive emails from outside Cisco. Currently its configured to just within Cisco. In the mean while please email me directly. losriniv@cisco.com.
We just fixed the email alias to be able to receive emails from non Cisco email-IDs. Please drop us a note on any questions/comments – Loghs
How are you handling the software that’s got hard coded ipv4 concepts in it? Have you got a layer in there doing 464xlat, and if so, how are you managing it to retirement (ie tracking actual use with a view to remediating identified rogue software and, eventually removing the layer)?
Great work! That is how Cisco on Cisco works. I am sure that there will be more challenges afterward.
I don’t expect fast transition to IP6 and sending IPv4 to history. IPv4 will be with us for a long. These protocols will exist paralel and IPv6 would take more and more percents of network traffic. When some Enterprise understand that is too complicate to cope with IPv4 and short public address space it would get IPv6. It will be a massive transition at one moment. Something like Gauss function with time on X and number of transions to IPv6 on Y axis.
Kudo’s are nice, but why would an experiment like this show more than the previous ones ? Look at http://ipv6.com/articles/general/timeline-of-ipv6.htm for a nice example of incredibly myopic visions on IPv6. There are so many others, like http://www.worldipv6launch.org (this time it’s for real … 5 years ago). My DSL box had IPv6 (dual stack) 10 years ago. It was removed because … NAT won the contest. Maybe if they had chosen 64-bit addresses it wouldn’t have failed. Or if it had brought some real added value for the money. Today the Internet is IPv4. If it ain’t broken, don’t fix it.