The Move to IPv6: An App Developer’s Experience

Nadir Hassan
EventMobi
Published in
4 min readFeb 21, 2017
Image courtesy of host1plus.com

For a service provider, the client needs come before anything else. At EventMobi, we aim to fulfill the needs of our clients every day. The issues we face can vary in complexity and sometimes require creative problem solving to get the job done.

Recently we started to see clients requesting our products operate over IPv6 and further our platform dependency on Apple’s iOS required us to immediately start looking at how we can make strides towards supporting IPv6 across our products.

If Apple enforces IPv6 support more heavily and strictly moving forward, it would present a serious challenge for the business as we ship four to five apps a day. So we were left with no choice but to begin the process of supporting IPv6.

What We Did

Enabling your system with IPv6 requires the addition of an AAAA DNS record to your domain, but our route is simpler.

Our backend runs on AWS; more specifically our servers run on EC2. We weren’t restricted by the lack of IPv6 support from our platform since we use AWS Elastic Load Balancers (ELBs), which provide us with three domain names. The standard domain name has an A record. Prefixing that domain with ‘ipv6’ provides an AAAA record while using ‘dualstack’ instead has both an A and an AAAA record.

Since our domain name uses a CNAME record to resolve to our ELB’s domain name, all we had to do was change the CNAME record from “name-123456789.region.elb.amazonaws.com” to “dualstack.name-123456789.region.elb.amazonaws.com”.

When making a connection, most browsers will default to using IPv6 if it’s available. If an AAAA record is missing, it will default to the A record (IPv4).

Testing

We first had to set up some way to see which protocol we are using (v4 or v6).

We used a Chrome extension called IPvFoo that displays which IP (v4 or v6) was used to fetch the parent page of an application. We used Google’s IPv6 test site that tells us if our browser is able to to make an IPv6 connection, but it doesn’t guarantee that we can load the page over IPv6. We also used the unix ‘dig’ utility to lookup all the DNS records for every domain we were testing.

You can probably now see that there were almost no problems with enabling IPv6 but more with testing it.

The tough part was building a clean environment that would operate only strictly with IPv6. At first, shutting down IPv4 on our machines broke all connections. We suspected the problem lay in our Meraki routers but after some digging around the server rooms and the configs, it turns out these had IPv6 enabled, which meant the problem was coming from our ISP. We confirmed with our IT department that our ISP didn’t have IPv6 enabled for our account.

To overcome this, we had a great idea to test the system using our phone data. Unfortunately to make matters worse, not all cellular networks support IPv6 quite yet. However after doing our rounds in the office testing different networks, we found one provider where we were able to successfully test our approach. We created a hotspot on this phone, turned off IPv4 on our machines, and voila! We now had an IPv6-only channel.

As awkward as it was to create, it got the job done. We added the AAAA records on our test environment and started testing. Our apps were loading successfully, along with any content, and high fives went around! Unfortunately this was all a little too early, as we opened the network tab in the developer tools and saw the wall of red — third-party libraries.

Third-Party Libraries

We use several third-party services and to get our application working on IPv6-only networks, all of them need to be available over IPv6. We pulled up a list of all the dependencies of our product and manually checked if they all support IPv6. If any of these dependencies failed over IPv6, we would have two options: to either convince the provider to update or we add a proxy layer to our stack for their service.

Conclusion

This process raises an important question: why, in 2017, is the Internet still not IPv6 ready?

Of course, the answer is not that simple. When everything works as it should, there is little reason to push new developments. Strict organization mandates force service providers to provide the service, and companies like Apple lead the trend by forcing it upon their developers. All of this makes updating feel like a large burden, but there are other great initiatives and movements that aim to turn this endeavour into an accomplishment.

If you’re curious about learning more, check out the World IPv6 Launch for more information. Also, feel free to reach out to me to chat about IPv6 and the developments we face at EventMobi. Better yet if problems like this interest you and you’d like to be part of an awesome team to push the web forward, EventMobi is hiring!

This post was originally published on the website of the Asia-Pacific Network Information Centre, or APNIC for short, here https://blog.apnic.net/2017/02/21/move-ipv6-app-developers-experience/

--

--