IPv6 at LSU [Archived]

By Hector Rios

IPv6 Case Study from Louisiana State University in Baton Rouge, Louisiana

Louisiana State University (LSU) has been supporting IPv6 since 2008. Our first exposure was at an Internet2 Member meeting held in New Orleans. LSU was the host and assisted in providing various network requirements. IPv6 was one of them, but even though it ended up not being used, it did provide the catalyst that enabled the eventual deployment on the Baton Rouge campus.

Implementing IPv6 on the LSU campus first required some initial research and testing. As network engineers, we first had to get up to speed on the technology, how it operated, how it was different from IPv4, what security concerns were there, and how it could easily be deployed. In addition, we had to become familiar with the capabilities of our existing network infrastructure, determine whether IPv6 was supported, to what degree, and build an inventory. This exercise provided valuable information that allowed us to determine areas where we could confidently deploy IPv6, and it also provided us with a list of equipment that either completely or partially lacked IPv6 support. Some of the features we explored were the following: OSPFv3, MBGP, HSRP, First Hop Security, Multicast, Wireless, Network Access Control (NAC), DHCP, DNS, NMS, ACLs, and firewall rules, to name a few. This list was then incorporated into our network life cycle plans and strategic plans to ensure that those pieces of equipment or software would eventually get upgraded.

After our initial research and testing, it was decided that the best deployment model would be dual-stack with stateless autoconfiguration (SLAAC). To start at a small scale, IPv6 was first deployed within the LSU’s Information Technology Services (ITS) building. Users were notified in advance of this new capability and documentation was made available so they could become familiar with the transition.  This approach provided both network engineers and users the opportunity to “play” with IPv6, but more importantly, it allowed us to learn even more about what we needed to do to support it at a larger scale.  Some of the lessons learned during this phase were things like caveats regarding different operating systems. For example, Windows XP required explicit IPv6 installation and activation; Windows Vista and 7 required temporary addresses to be disabled (privacy extensions). In addition, we were also able to further refine our firewall policies and security measures at the access, distribution, and core layers.

In a period of about two years, we had learned so much about IPv6 that we were ready to deploy it campus wide. In September of 2010, the dual-stack network was expanded to the entire campus, including our wireless network and VPN. By then, all relevant information for users as well as operators had been properly documented and made available. To allow for testing, we stood up an IPv6 site (ipv6.lsu.edu) so users could confirm that IPv6 was working correctly. In addition, we worked with some departments to encourage them to enable their main websites with IPv6 support. This allowed them to get involved in the process, become more aware of IPv6 and the capabilities of not only their servers, but anything that might be IPv6 capable, and finally build the same curiosity we had when we began our journey.

Eventually we participated in both World IPv6 Day and subsequently in World IPv6 Launch Day. This allowed us to provide the LSU community with a context by which they could see the reach and importance of IPv6 at a worldwide level as well as to promote it in whatever capacity we could.

IPv6 address space is big. Really big

In the initial phases of our deployment, we were still not fully convinced about our addressing scheme. The main issue was the fact that we were so used to working with IPv4 and being conservative, that we hadn’t grasped the immensity of the IPv6 space. We knew we needed a more flexible scheme that would allow us for easier deployment, management and identification. Once we understood our requirements, we came up with a better solution. Our IPv6 space was broken down into groups of IP spaces that were dedicated to specific areas of the campus such as our Residential Network, research networks, remote sites, and future campus sites. Further subdivisions were implemented that took into account growth and enabled uniformity. Finally, we embedded information into IPv6 prefixes so we could easily identify networks by router and VLAN ID. The result was a scheme that lead to a more informative address space that was easier to deploy and troubleshoot.

Workarounds. There will be some.

Realistically, there are many challenges with deploying IPv6. For example, early on at our university, we had a mechanism to control access to the network. This mechanism relied on both DHCP and DNS, and required users to register their MAC address via a registration portal. When we started implementing IPv6, we quickly realized we were going to automatically provide network access to our users even if they were not registered because this registration relied solely on IPv4 and could not be easily ported to IPv6.  The workaround for this issue was to only provide user devices with an IPv4 DNS server address so we could serve both A and AAAA records and still control network access.

IPv6 global addresses are prefixes that can be globally routable. Within the LSU network, we had subnets that were both publicly and privately addressed. Some privately addressed subnets had access to the Internet via NAT, others didn’t. Since our initial approach was to assign a global prefix to every subnet (we did not want to use Unique Local Addresses), this opened up the ability for some devices to have access to the Internet, when they previously did not have this capability. This issue was addressed by ensuring that the proper firewall rules were in place to prevent Internet access to those devices that didn’t need it. In some instance, IPv6 was not even enabled at all.

Even though IPv6 support has matured over the years, interesting bugs and caveats are still common. During one of our router implementations we ran into an interesting IPv6 issue. The problem was an apparent limitation on how to secure SNMP on IPv6. Specifically, it seemed as though the router was unable to support IPv6 ACLs to control SNMP access. After working with our vendor, the workaround was to create an ACL for IPv4 and IPv6 with the same name. This solved the issue.

Who needs to be involved?

The initiative and vision to support IPv6 at an early stage started with the networking team because we had the knowledge of the technology and understood its importance and impact. The challenge was the ability to translate that knowledge into something that key university stakeholders understood and were able to support. When you bring something like IPv6 to IT executives, it could be a challenge to be able to demonstrate the tangible benefits, especially when there are other priorities that have a wider and palpable economic impact. When you bring up concerns about products and vendors lacking IPv6 support to people who don’t understand its importance, they’ll have a bigger tendency push it to the side and not consider it a priority. IPv6 is an “under-the-hood” technology.  Some stakeholders don’t care too much about the technicalities of the engine specs, they just want those engines to be able to move things from one place to another, and to be fast and reliable. This is especially true when there is already an older engine (IPv4) that has been running for quite a while and seems to be doing fine.  However, it is incumbent upon network engineers to fully understand the issues and concerns with IPv4 (depletion, NAT) and getting the buy-in at the highest level of your IT organization. This way, a strategic plan and roadmap can be developed and ensure everybody is onboard and follows it.

It is important to understand that IPv6 is not a switch that can be simply turned on when needed. It requires careful planning and it affects everything from the very applications that users interact with to the devices that process and move packets. Ignoring it will not only work against you but could potentially put you at a disadvantage. Do you know if your critical applications currently support or have IPv6 in their roadmap? Talk to your vendors. Even today, we still meet vendors that have no understanding of IPv6 or have no plans to support it.

It’s not as hard as you think

Deploying IPv6 is not as hard as people think. Yes, there are many new things to learn and challenges to overcome. Engineers need proper training and practice, but sources for education abound, both free and paid. Unlike when LSU first got involved with IPv6, today a lot of technology, applications and services already support IPv6. But you must do your homework and ensure that you have a clear understanding of your requirements, and even more important, you must test those requirements to make sure they are actually met.  In a way, here at LSU it felt like we were beta testers for a while, but we persevered by working with vendors and pressuring them to address our issues. If we were to implement IPv6 today, I know that it would be a lot easier because the technology has had time to mature. Now many solutions already come with built-in IPv6 support, and in almost all instances at no additional cost. So there are less and less excuses to not support IPv6.

If you’re thinking about IPv6, I suggest you get your hands dirty. Start with what you have, see how it works, determine what needs to be upgraded, and what needs to be replaced.  Determine who your stakeholders are and engage with them to provide education and get them on board to test with you. As you learn more, you’ll become more comfortable and will quickly realize that it’s not as hard as you think. At LSU we’ve been doing it for so long that is now second nature. We look forward to the day when IPv4 will sunset. Adopt IPv6 today and you’ll make it happen that much faster.

Any views, positions, statements or opinions of a guest blog post are those of the author alone and do not represent those of ARIN. ARIN does not guarantee the accuracy, completeness or validity of any claims or statements, nor shall ARIN be liable for any representations, omissions or errors contained in a guest blog post.