Three Key Standpoints in Implementing IPv6 [Archived]

By A. Michael Salim

American Data Technology, Inc. IPv6 Case Study

American Data Technology, Inc is a small hosting company based in North Carolina with variety of customers. We have three datacenter spaces, two in Research Triangle Park, North Carolina and one in Ashburn, Virginia. We provide hosting services over both IPv4 and IPv6 (“dual stack”). In fact, all our IP traffic could be sent over IPv6 including HTTPs, remote desktop, SSH, VPN, and various other types of traffic. Since end users of the websites are the general public, we decided we had to be dual stacked. The same way we couldn’t lock out IPv6 users and be IPv4 only, we couldn’t lock out IPv4 users and be IPv6 only. We have to be able to support both.

Internal process

As one of the founding members and CTO of ADTI, I manage all the technical and IT-related initiatives for the company. In that role, I oversaw our IPv6 project. We had various tech meetings to make sure everything was lined up in the right sequence.  We asked ourselves: Which routers would be enabled with IPv6 first –internal or border routers? Which switches? and so on. In the end, everything has to support IPv6 all the way from the border router to the servers.

We also had to make decisions about how much IPv6 space we would allocate to each customer. We had conversations about numbering conventions. For convenience, we decided on assigning IPv6 addresses to customers using the last IPv6 address to match their IPv4 address.

Driving incentive to deploy

Back in the 2012 timeframe, there was a lot of press that IPv4 was about to run out shortly, but the biggest reason we deployed IPv6 was due to our U.S. government customers. They were mandated to support IPv6 and to be on a dual stack network by September 30, 2012. Indeed, we have found IPv6 interest is primarily from our federal customers because of the OMB mandated requirement that all government websites have to support IPv6 as well as IPv4.  It is important that government websites be accessible to their customer-base (i.e. everyone in the country). They can’t be in a situation where they are putting out information or forms where only some people can get to it, not everyone.

Even though we still aren’t in a situation where customers are forced to use IPv6 because there is no IPv4 yet, we definitely have customers that prefer IPv6. When their router has a choice between an IPv4 path and IPv6 path, they choose IPv6 first.

Three key standpoints - technical, security, and coordination

I recommend you make sure your IPv6 implementation is planned from a technical, security, and coordination standpoint.

From technology standpoint

Deploying IPv6 meant making sure all our equipment supported IPv6. Beyond that our upstream providers (whoever we got our network services from) also had to support IPv6. Back when we were working on our implementation, there were a lot of companies offering pseudo IPv6 capability. By that I mean they would “pretend” to offer IPv6, but then they would provide it through some fancy tunneling or something like that. We weren’t thrilled with that kind of approach, because the bottom line is that it wasn’t really IPv6. On top of that, who knows what security issues you were introducing by doing that. We decided we needed to be on a native IPv6 network. Unfortunately, one of our datacenters indicated they had no immediate plans to deploy IPv6 for the next 12-24 months, so we ended up having to migrate to a datacenter that did support it.  We had to move all our equipment over, and that datacenter lost our business as a result of not supporting IPv6.

Around the same time, we were needing more and more IP addresses so we got our own IPv4 and IPv6 allocation from ARIN. We got the smallest IPv6 allocation available at the time which was a /32. We were one of the companies that had achieved IPv6 capability in time to participate in World IPv6 Day on June 6, 2012.

From a security standpoint

When we were preparing to deploy IPv6, we spent quite a bit of time studying the security ramifications. We wanted to ensure whatever IPv6 configurations we turned were secure and hardened. We didn’t want to introduce any new vulnerabilities into the system or adversely impact the security posture of our infrastructure or our customers’ assets. For example, there were several settings related to address discovery that we needed to configure one way and not the other. Configuring it the wrong way could allow hackers to get a foothold and expand into the network.

From a coordination standpoint

Our IPv6 implementation had to be closely planned logistically with our customers. We had one customer in particular that was eager to be on IPv6 by a certain deadline. We worked with them on all the IP address changes, even having to go through the long process of changing IPv4 addresses so everything was on a new network. With our other customers, we notified them that they had the option of adding IPv6 addresses. We considered whether we should just go ahead and enable IPv6 for all our customers or just let them know they have the option to enable IPv6. For security reasons, we decided it was best to give every customer the option of adding IPv6 at no charge, and they could contact us if they want it enabled. We have seen both government and few commercial customers take advantage of that offer.

Considerations

Our biggest obstacle at the time of our deployment was the lack of IPv6 capability among network or bandwidth providers. Even though most providers had a plan to eventually offer it, some were working on it faster than others. We had to switch companies to one that provided IPv6 immediately. It’s one thing to be on an IPv6 network yourself, but if no one else is, what good is that? It has to be end to end. The same customer I described earlier also had huge challenges in this regard. Even though they were driving the IPv6 requirement, their datacenter was not on IPv6 for at least another year.  That meant we had to provide two sets of equipment for them. We provided them a jump server where they would connect via IPv4 (because they only had IPv4 capability), and then from that jump server they would connect to an IPv6-only server, thus allowing them to be on IPv6 network.

In general, cost-wise, deploying wasn’t that big of deal. We didn’t suddenly see providers charging more money for IPv6. There was a lot of effort involved that did carry with it a cost. However, that was primarily a one-time engineering and implementation cost. There were no significant additional reoccurring costs in implementing IPv6.

One interesting thing you have to plan for is related to the size of IPv6 in comparison with IPv4 and the time it will take to scan those networks. We allocate about eight IPv4 addresses per customer, but with IPv6 it’s hard to allocate anything less than a few million. In an IPv4 network you can run a scan of everything in a /24 IP range in only a few seconds. In an IPv6 environment where you have a /48 subnet per customer, it will take a longer time to scan everything, to the point where it becomes infeasible to scan an entire IPv6 subnet in a timely manner. Yet as part of ongoing security monitoring, you have to continue doing the scans, because you don’t know what might be lurking somewhere in that range, so the security architecture needs careful planning and design to accommodate these aspects.

IPv6 is a good thing

I believe there’s no reason not to implement IPv6 at this time. The top two pieces of advice I would recommend for other hosting providers are to:

1. Carefully select your upstream provider. Make sure they are providing good quality IPv6. Nowadays it’s not such a big issue, but back when we were deploying IPv6 there was a blurry line between native and non-native IPv6.

2. Make sure you pay attention to security aspects. It is not straightforward. Be very careful. Give a great deal of thought in how you implement IPv6 from a security standpoint.

Every bandwidth, hosting, and network provider should implement IPv6. Definitely do not choose to not implement it. That would be a mistake.

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.