We activated IPv6 on most of the University of Iowa campus in July 2010.
We made network-related services, such as name service, NTP, and DHCP (which we maintain as part of the networking group) available over IPv6 really early. We do network management like SNMP and syslog over IPv6 where it makes sense and we have RADIUS running over IPv6.
Things that we have directly in our control for our own use we did as early as we could. The more user-exposed and visible it was, the longer it took to get going. Our datacentres are IPv6-enabled as well as most faculty, staff, and student spaces (excluding The University of Iowa Hospitals and Clinics which has yet to do any IPv6).
The pace of IPv6 is accelerating
We had a relatively small amount of IPv4 address space and wanted to avoid NAT and other ugly behaviours. We were trying to not get caught behind the curve.
I think there’s a tendency with IPv6 to keep putting it off, but if you do that, you just get further and further behind. Then by the time you really have to do it, it’s a huge undertaking.
The pace of IPv6 is accelerating and if you don’t get on board, you’re going to slam into the wall. We have been deploying IPv6 early and piece by piece. Even today, it’s still a work in progress.
Our strategy involved trying hard to avoid the so-called transition mechanisms like 6to4, because I think they are a distraction and waste of effort. Instead of spending time thinking about how to work through them, just go ahead and embrace native IPv6 dual-stack in parallel with IPv4, and get on with it. We did that on our campus, and it simplified things.
I recommend you get IPv6 into your daily operations and I recommend approaching your IPv6 project by going dual-stack from the start. Everything will prefer IPv6 if it’s working correctly, and happy eyeballs is able to help with that. If something with IPv6 isn’t working the way it should, happy eyeballs allows for a fast fallback to IPv4 to avoid user-visible trouble. At our university, with a strong centralized network, we had a positive IPv6 rollout.
We did what we could to inform the university community about our plan to deploy IPv6. For example, at our annual ‘Tech Forum’ for University of Iowa IT employees we did a presentation about why we were doing IPv6 and what to expect.
Getting it just right
Getting our wireless networks on IPv6 was a big challenge for us. As a major technical service that we offer, there was a high demand to do it just right, and to this day we are still ironing out the quirks. The firewalls for our datacentre were another challenge as some of them were behind the times when we first started deploying IPv6, but that’s been mostly resolved.
In addition, multicast routing, MLD snooping, and switch level functions were all issues we had to work through. We also needed to push our vendors to support IPv6. For every network-related RFP, we asked vendors about their stance on IPv6. If vendors weren’t doing IPv6, we saw that as a missed opportunity on their part.
As we were going through the process of deploying IPv6, we turned to books, training materials, our local Regional Internet Registry’s (RIR) resources, testing sites, other’s experiences, and sample addressing plans. After that research phase, we were closer to understanding the protocol and being more effective in using it.
Check out APNIC’s 10-step plan for deploying IPv6 as well as other case stories from around the region and the globe.
One of the early advocates of the transition to IPv6 was the manager of our server support group. Furthermore, the engineering, business, and computer science academic units were willing to be our guinea pigs as we began to test IPv6. We made it clear that we could roll things back if necessary, but we didn’t have to do that anywhere. Yes, we did see a few bugs here and there, but nothing major. The testing we did helped prepare us for a successful IPv6 rollout campus-wide.
Don’t get left behind
The main reason you need to do IPv6 is to not be left behind and stuck in IPv4’s constraints. With IPv6, you move away from the monstrous IPv4 routing table that keeps adding more demands and makes IPv4 more expensive.
Even back in 2008 and 2009, client devices were trying to do IPv6 whether you thought so or not, even preferring it to IPv4 in most cases. At the very least, you need to pay attention to IPv6 and do something with the protocol.
We ended up doing DNSSEC and IPv6, at the same time, and you can too. Test them out in your environments, before they become a critical requirement.
Learn about DNSSEC and why it’s important to secure it
Start ASAP
My advice is to start your IPv6 planning early, especially if you haven’t even begun yet. You can do it slowly, starting with your network-related services. Once you mess with it yourself in a non-user environment, you will get the day-to-day exposure you need to go bigger.
Don’t forget that your addressing plan in IPv6 is a different game than it was in IPv4. The IPv6 space is huge and how you will lay it out takes some thought. Consider how many sites you have, and apply it to your situation.
When you go to your local RIR [or LIR] for your IPv6 address space, think about the size of block you will want to ask for.
Initially, we got a single /48 thinking we wouldn’t need any more space, but we have since expanded that to a /44 so we could have additional /48s. The smallest IPv6 chunk you can route distinctly on the Internet is a /48, analogous to a /24 in IPv4, so you might need multiple /48s for reasons other than just raw address quantity.
I recommend getting more space than you think you might need so you can be flexible with your routing and hosting.
IPv4 is losing momentum
I think it’s important to get network voices involved early in your IPv6 project. Go slow and consider dual-stack with IPv4 as there are many compatibility issues with the various transition technologies.
IPv6 has reached critical mass and you need to get on the boat. Be part of the active Internet.
Original post appeared on ARIN Blog “Don’t Get Caught Behind the Curve“
Jay Ford is a part of the Network Engineer Group in the Information Technology Services at The University of Iowa.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
Did you face any security issues along the way at all during your deployment of IPv6?