Don’t Get Caught Behind the Curve [Archived]

By Jay Ford

IPv6 at The University of Iowa Case Study

We activated IPv6 on most of the University of Iowa campus in July 2010. We made network-related services, like name service, NTP, and DHCP that we maintain as part of the networking group available over IPv6 really early.  We do network management like SNMP & 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 data centers are IPv6-enabled as well as most faculty, staff, & student spaces (excluding The University of Iowa Hospitals & 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 behaviors.  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, & 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 fall-back to IPv4 to avoid user-visible trouble.  At our university, with a strong centralized network, we had a positive IPv6 roll-out.

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 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 data center 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 need to push our vendors to support IPv6.  For every network-related RFP, we ask vendors about their stance on IPv6. If vendors aren’t doing IPv6, we see that as a missed opportunity on their part.

As we were going through the process of deploying IPv6, we turned to books, training materials, ARIN 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.

One of 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 roll out 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 same time, and you can too. Test them out in your environments, before they become a critical requirement.

Start ASAP

My advice is to start your IPv6 planning early, especially if 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 ARIN 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.

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.