Stop Procrastinating and Do IPv6 [Archived]

By Mike Milne

IPv6 Case Study from Carleton University in Ottawa, Ontario

Founded in 1942, Carleton University has about 30,000 students and our campus is a single location occupying 62 hectares of land in Ottawa, Ontario. We knew we were going to have to implement IPv6 eventually, but two events in 2011 got us started. The first event was the IANA announcement in February 2011 that all remaining IPv4 addresses had been allocated to the regional registries, and that there were none left. This event got a lot of media coverage and resulted in some calls of concern from several university departments. The second event was hearing Owen DeLong from Hurricane Electric speak at the IPv6 summit held in Ottawa in April of 2011. As a true “IPv6 Evangelist”, his takeaway message was that not only was it not as hard as you think, but the time to act was now!

Set a strategy

We started by obtaining a /48 assignment of IPv6 addresses from ARIN, and then began developing an implementation plan. We identified the major steps required, including; assessing the readiness of our infrastructure to support IPv6 traffic, designing an internal routing and IPv6 address allocation plan, determining how we would assign IPv6 addresses to internal systems, and integrating our IPv6 routing with our three ISP providers.

It seemed like a very daunting task at first, but one of the smartest decisions we made was to divide the network up into client and server environments. While our plan is still to eventually implement IPv6 everywhere, we decided to proceed only on the client side of the network that serves end user workstations. We knew that the client devices had good IPv6 support, and all of the pieces of the network that required configuration were under the control of our networking group. We have a large installation of IoT (Internet of Things) devices such as video surveillance, building automation, and VoIP. We decided against implementing IPv6 there for now as these devices currently use private IPv4 addresses, are not required to talk to the Internet, and there were questions about support of IPv6 by these devices.

Assess your IPv6 readiness

We did pretty well when it came time for our IPv6 readiness assessment. Most of our equipment was ready to go, but there were several devices where we had to upgrade the device software. Fortunately, these upgrades were covered under our maintenance agreements and did not cost us anything. We did find five building routers that were not IPv6 capable, so we simply did not implement IPv6 in these buildings. Eventually, these devices were replaced and IPv6 was implemented with the new hardware. We did find that the readiness assessment was a bit of an iterative process that needed to be repeated as the design unfolded. We had to go through it a few times to ensure all required features were supported; such as our internal routing protocol, policy based routing, etc.

Take a test drive

We ended up using OSPFv3 as our internal routing protocol as all of our routers supported it without any additional licensing costs, and because our physical network topology was ideally suited to an OSPF design with a backbone and multiple areas. We first built the OSPFv3 backbone area between our four fully meshed core routers, then added one additional area that included the building where the networking team sits. We then established BGP connectivity to one of our ISPs and took it for a test drive!

We then did some lab work to determine how we would assign IPv6 addresses to end user workstations. We decided to use stateful DHCP, and to suppress the announcement of network prefixes by our routers during the Router Solicitation process. We wanted to be able to associate an assigned IPv6 address to a physical machine, and like many universities we have a lot of systems connected to our network that are not under our control and we couldn’t disable the privacy extensions. Our two DHCPv6 servers are in our data centers so we had to use DHCP relay to get the requests from the end user subnets to the servers.

We then extended the OSPF design to include all campus buildings, but only enabled one IPv6 subnet in each building. This allowed us to validate our OSPF design as well as test that routing worked within the campus as well as to the Internet.

Finally, we built the DHCPv6 scopes and rolled IPv6 out to the end user subnets. The uptick in IPv6 traffic was immediate as most popular sites such as Google, Facebook and YouTube are IPv6 enabled. At present, about 45 percent of our total traffic is IPv6.

Speed bumps

We did hit some speed bumps along the way. The biggest had to do with our wireless network. We have a large wireless installation, with 2,000 access points and at peak periods we can have in excess of 13,000 connected client devices. When we enabled IPv6 on wireless the overhead associated with the ND (Neighbor Discovery) process completely flattened the CPU on the systems where the wireless controllers are installed. The problem was resolved by upgrading the CPU modules to a newer model where the ND process is implemented in hardware.

Work in progress

We have pretty much completed IPv6 implementation on end user networks, and our next major step will be to start implementing it on the server side. Our Windows Active Directory infrastructure is a likely first target. We have also experimented with running unilingual IPv4 systems behind a F5 load balancer with the F5 device providing the dual stack protocols and this works quite well. We will probably use this method to enable IPv6 services on most of our public facing web servers. We also have a number of departments that run their own networks, and we have spread the IPv6 message to them. The School of Computer Science will probably be the first aboard later this summer.

Lessons learned

The single biggest benefit we have gained with IPv6 is the sheer volume of IP addresses available to us. All end-user subnets use a /64 assignment, and we no longer have to worry about making the subnets too small as we did with IPv4. Our Wireless network and student residences use private IPv4 addresses, and we have seen reduced CPU load on our firewalls as the amount of NAT (Network Address Translation) processing is reduced. When we receive abuse complaints for IPv6 addresses we can identify the machine, something that using private IPv4 addresses with NAT does not allow us to do.

The smartest decision we made was to split the IPv6 implementation into client and server pieces. This allowed us to move quickly without any risk to our core business systems. Another big plus of this project was that we did not give it a specific deadline, as there was no real business reason to do so. Not only did this let me work on more pressing issues, such as outages when they arose, it gave me the time to think the design through and do it right the first time. As a network engineer, I really enjoyed working on the project. Not only did it allow me to learn something new, it gave me an opportunity to do a complete end-to-end network design. The best advice I could leave you with is to stop procrastinating and do it!

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.