Thirdparties - the biggest bottleneck to IPv6 adoption.

As a modern system builder, I realise the importance of IPv6 support and how urgent it is to replace the current IPv4 stack. Even large scale providers like Microsofts Azure have had to resort to issuing IPv4 addresses to new virtual machines assigned to other counties to meet the demand for addresses.

But if today one was to go out and build a IPv6 compatible web product, they would encounter a considerable amount of barriers, some of which are very hard to overcome without going to other new suppliers in the hosting marketplace, some of which might be expensive, or you might not be familiar with.

IPv6 Content Deployment Networks (CDNS)

• HTTPs only CDNs will usually serve content from one of their own domain names rather than a custom name setup by their customer.
• Their DNS resolving servers should be accessible over IPv4 and IPv6.
• Over IPv6 it should do the same any cast routing found in typical CDN setups and route to geographically relevant IPv6 addresses for the end user.

IPv6 Virtual Machines and Servers

• A hosting provider will also need to offer IPv6 address assignment to servers or VMs they offer.
• Each server will also need to access the IPv6 internet, so IPv6 routing must be supported.
• Load balancers must also be IPv6 aware. Typically these work by changing an IP address reported in a DNS lookup after applying a performance/fallback algorithm. So the load balancer will also need to be accessible over IPv6 and be able to respond with both IPv4 and IPv6 addresses.
• It’s normal to see different hosting provider companies deal with IPv4 and IPv6. For example, I might host all my products on Azure, which is currently IPv4 only. I might have a good deal and be eager to keep them for hosting. However, it becomes a requirement that IPv6 must be supported. I could use Rackspace to host the IPv6 version, and keep Azure hosting the IPv4. This would save me an added task of having to move everything to Rackspace, and perhaps give-up any preferential pricing I might have with Azure. The drawback to this approach is that some resources might be idle. It’s always more efficient for the platform to deal with both IPv4 and IPv6 traffic. When there are resources setup independently to deal with the two, there will be some inefficient overlap.

IPv6 Monitoring Systems

• This is a pain point listed in my article comparing monitoring providers. Many monitoring solutions available today are IPv4 only - their routing setup prevents them from even detecting the existence of a website over IPv6. And if they do support IPv6 - they don’t make it evident or allow their monitoring checks to be configured for IPv6 only - they don’t seem to realise that in some cases, an entire separate set of infrastructure will server IPv6 traffic while another deals with IPv4.

So we can see that there is no simple IPv6 ‘on switch’. For the IPv6 migration to work, it’s an all-or-nothing scenario. Each part of the stack must support IPv6 by default. If just one part is missing, weather it be a CDN or a load balancer, the website will fail to work properly.