The move to IPv6: An app developer’s experience

By on 21 Feb 2017

Category: Tech matters

Tags: , , ,

Blog home

Image courtesy of host1plus.com

For a service provider, the client’s needs come before anything else. At EventMobi, we aim to fulfil 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.

One such prospective client required our service to run over IPv6, as per their organization’s mandate. This request and Apple’s announcement that all apps would need to support IPv6 by mid-2016 meant we had to act. But as developers we tend to follow one rule — if it ain’t broke, don’t fix it. That said, we knew something would have to be done eventually.

Then earlier this year, we received news from our app release coordinator that some of our apps had been failing Apple’s app review process due to lack of IPv6 support. What was more surprising was Apple seemed to be doing random spot checks for IPv6.

If Apple suddenly decided IPv6 support was mandatory, 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.

ipv6_cs_fig1

The tough part was building an IPv6-only environment. 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. We began going through different mobile data providers for IPv6. After a few tries, we discovered that Fido supports IPv6. We created a hotspot on a Fido 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. The app seemed to load successfully, menus and pictures were appearing, and high fives went around. Finally, 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.

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.

Nadir Hassan is a Full Stack Engineer at EventMobi.

Rate this article

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.

Leave a Reply

Your email address will not be published. Required fields are marked *

Top