We recently had a potential client approach our sales team about purchasing our SaaS product, but the client had a hard requirement that we worked on IPv6-only. We were IPv4-only at the time, so we decided to investigate how easy it would be to add v6 support. Turns out, it’s a mixed bag.
It was easy enough to add v6 support to our application - all we needed to do was add a AAAA record so that our domain properly resolved to the v6 address of our load balancer. But a number of the external services that we depend on haven’t migrated yet, so our application won’t work properly unless we can convince them to migrate as well, or we add a proxy layer to our stack.
And it turned out that testing our changes was a challenge because the ISP for our office doesn’t support IPv6. In fact, my ISP at home doesn’t support v6 either. We also tried from a BrowserStack environment, but their VMs are IPv4-only as well. (One thing we have yet to try is an Amazon Workspace.)
In the end, we were able to test when one of our developers noticed that his phone supported IPv6. We created a wi-fi hotspot on the phone, connected to that, and turned off IPv4 on the test machine. But wow, I’m surprised at how far away the world still seems to be from supporting IPv6.
I found it interesting that this was brought on by insufficient RFC1918 space—clearly only a problem in large organizations.
Maybe true, but having been a spectator for another large organization’s half migration to a ‘temporary’ (read permanent) solution I’d much prefer the pain of a whole hog v6 migration.
It is interesting to see such a mini-case-study about finding a setup that works while no vendor provides all the features that are needed.