IPv6 is Not Optional [Archived]

By Mattias Lindgren

IPv6 Case Study from University of Colorado Denver in Denver, Colorado

The University of Colorado in Denver has a presence across two main campuses - the Anschutz Medical Campus in Aurora, Colorado and the Auraria Campus in Downtown Denver.  Over the past year, I spearheaded the effort by the network team to complete a project of enabling IPv6 across both campuses.  This involved extensive planning phases, going through project creation and approval, and finally the roll-out to our approximately 30,000 users.

Planning

We began by obtaining IPv6 space from ARIN.  Lining up supporting documentation as well as approval of the contract amendment by the University purchasing team was a time-consuming portion of the planning phase.  We knew we wanted to get ample space for the future, so we requested and got approval for a /40.

Make it Official

In discussion with my manager, we decided that the best way to get buy-in from the whole IT department was to make it an official project.  This is key as it sets expectations for all the project members and stakeholders, and holds each team member accountable for completing their assigned tasks.  We regularly hold a Project Review Board where members of the IT staff can present project frameworks.  At one such meeting, I presented the benefits of implementing IPv6.  Representing the network team, I argued that migrating to IPv6 is not optional, and adoption of it over the legacy IPv4 protocol is happening at other major universities and will soon become the dominant protocol on the internet.  The earlier you adopt it, the easier implementation will be as networks only increase in complexity over time.  We also discussed efficiency gains as complex NAT schemes would no longer be needed for pure IPv6 traffic.  The project was approved by our CIO and it became an official mandate across central IT to deploy IPv6.

Project Rollout

We felt that an important part of the rollout was to educate the technical staff outside of the central IT department.  To facilitate this, we brought in an outside vendor to give a half day presentation on IPv6 and what it meant.  We had a good turnout of about 150 people.

Over the past couple of years, we implemented MPLS across both of our campuses.  This made implementation of IPv6 easier as we could target well-defined chunks of our network for rollout.  We saw a brand new IPv6 network as an opportunity to atone for legacy protocol sins, and designed the new dual-stack network with redundancy and scalability in mind from day one.  Having already rolled out MPLS also presented its own challenges, as we found that some of the features present in the IPv4 world hadn’t yet become available on the IPv6 side.  It has become a running joke that IPv6, at 20-some years old, is such a young protocol that we can’t expect vendors to support it just yet.

Since our legacy network routing table was sprawling with thousands of routes, we took the opportunity to summarize our IPv6 routing table as much as possible and it is currently less than 50 routes.

We decided on DHCPv6 for our addressing scheme, and began handing out addresses from our centralized DHCP and DNS appliance. This negated the need for disabling privacy-extensions and also made the client addresses a little more manageable.

One issue we’ve had for a long time is the presence of 6to4 adapters on our Windows computers.  Since we still have workstations with public IPv4 addresses, they automatically create a 6to4 tunnel.  While this was intended as a transition technology, we’ve found that it can cause issues by generating thousands of incorrect DNS entries and clients will mistakenly use these 6to4 adapters which can lead to connectivity problems.  This added challenges to user buy-in because they believed this to be an IPv6 problem.  As part of our implementation plan, we disable these adapters through Windows Group Policy.

Final Words

It is a great advantage to start as early as possible in your IPv6 deployment.  This way you’re not forced to react to future requirements and you can do a controlled roll-out.  From a budgeting perspective, it did not require any capital expenditures to implement IPv6, however with our MPLS project we had refreshed quite a bit of our hardware already.  We did find some caveats with older supervisor modules that did not have all the IPv6 support we needed, so we had to withhold rollouts to certain segments until equipment could be replaced.

I also feel buy-in from the entire department is crucial as it creates clear expectations for the entire team and produces a cohesive message from help-desk and workstation support to system administrators and network engineers.

After the success of our IPv6 rollout, I’ve had conversations with network engineers from our sister institutions expressing interest in our IPv6 implementation.  As collaboration between organizations who often have overlapping private IPv4 space increases, I see IPv6 becoming even more important.

Overall, we’ve seen no complaints from our end-users as we’ve rolled out IPv6 across both of our campuses.  To be honest, very few people are even aware they have IPv6 access, which is exactly as it should be.

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.