When something fails, it’s only natural to seek a workaround. A plan b. A solution.
In this episode of Packet Pushers-IPv6 Buzz 104, Tom Coffeen, Scott Hogg, and Ed Horley talk about how you can use IPv6 to get around IPv4 failures and how that might play out in your environment – at home, at work, or when you’re on your mobile provider. So what exactly goes on, and can you detect those IPv4 failures yourself?
What Type of IPv4 Failures Typically Occur?
Consider this scenario: You have both protocols at your disposal. You have a dual-protocol client, and you have some service and transport that is dual-protocol capable – so you have both protocols end-to-end. But, then, something happens to IPv4 connectivity.
What this can look like in a more practical and everyday sense is that IPv4 fails at home–specifically, something happens to your dual-stack internet service provider. Maybe the public v4 routing is broken somehow, but the v6 seems to be working. The following steps depend on what is available to you.
How IPv6 Behaves During IPv4 Failure
If your client is dual-stack capable and using two resolvers–a v4 and v6 resolver address–it will use whatever resolver is available. (The v4 resolver won’t be reachable, but the v6 resolver will be.) When v6 does its recursive DNS lookup, it keeps track of the round-trip time and won’t be able to talk to any other IPv4-named servers, but it can do v6 recursive lookups. So it will not only know that v4 is unavailable, but that v6 round-trip time is available and faster, and it will choose that option to facilitate the lookups.
The plus side of this scenario is that even in a failure like this, most people will still have internet access to their favorite sites and not realize that IPv4 is down. So they can still be “happily surfing” because everything appears to be working for the end user.
The mass majority of app services are IPv6-enabled. Most individuals will not have an issue with Google to Office 365, GSuite, Gmail, YouTube, and more. It would only be a small number of users who would notice something is down in a significant way.
Cloud Provider Outages
When it comes to cloud provider outages, whether something happens to the CICD pipeline, CDN, cloud load balancer, or web application firewall, something in the cloud domain is experiencing outages. Unfortunately, knowing what part is failing, IPv4 or IPv6, can be more challenging because cloud providers often don’t make that distinction. However, some tools can help. One example is ThousandEyes from Cisco, which can tell the difference between v4 and v6 failures.
There is always a slight chance that both IPv4 and IPv6 could fail simultaneously, something that Ed, Scott, and Tom called “the worst of both worlds.” To prevent that, they encourage rolling out IPv6, but not in a way that is tied to IPv4. Otherwise, you will have dependency mapping between the two, and you have to guarantee that both are operating flawlessly for your service to work, which is not optimal.
As Ed, Scott, and Tom wrap up this conversation, they close by sharing: When IPv4 fails, IPv6 is an ideal backup plan to get around those failures, usually even without the user noticing. As IPv4 becomes a thing of the past, IPv4 shortcomings will also be. If you are running into an IPv4 failure and need help, just don’t seek advice on Twitter – it’s an IPv4-only site.
For more discussions on IPv6, check out IPv6 Buzz for a complete list of episodes.
