IPv4 crutches

Back in June I participated in Turn off IPv4 Day as a show of solidarity. I had grand plans to write up a long post about the issues encountered throughout the day, but I had already done similar versions of this activity in the lab, so there weren't a whole lot of surprises. There was one gotcha right at the beginning that did catch me a bit off-guard: the Internet looked a lot darker than I anticipated.


Many websites have made a lot of noise about having enabled IPv6 connectivity. Google and Facebook notable among these. Suddenly, however, I found myself unable to reach these beacons of IPv6 accessibility. I was a bit stumped at first, but it came to me fairly quickly what had happened.

The test procedure for the day was fairly simple: remove the IPv4 address from the LAN interface on the router. I still needed IPv4 on the WAN side for the tunnel, but for everything on the inside it was IPv6 or bust. This included the recursing DNS server I run in house. When I finally did a dig +trace to one of these sites, I got as far as trying to look up the NSes for the domain and got the dreaded dig: couldn't get address ....

Let's look at the Alexa Top 10 US sites:

Site                AAAA    NS      ip6.nl
google.com          Y       N       3.0
facebook.com        Y       N       2.0
youtube.com         Y       N       3.0
yahoo.com           Y       N       1.5
amazon.com          N       Y       2.0
linkedin.com        N       Y       2.5
wikipedia.org       Y       N       3.0
ebay.com            N       Y       1.5
twitter.com         N       Y       3.0
bing.com            N       N       0.0

• AAAAs as reported by Cameron Byrne in his NANOG presentation 464XLAT: Breaking Free of IPv4 on slide 30.
• NS as tested from my console 9 June 2014 16:00 ET, test method: dig -6 +trace -t AAAA ${DOMAIN}
• ip6.nl score is on a scale of 5, includes AAAA, NS, and MX checks.

No single site had both AAAA and NS records, meaning none of the Alexa top 10 US were accessible from a pure IPv6-only network. An IPv4 crutch had to be used to access all of these sites.

Since this exercise was conducted, only one of these sites has made noticeable improvements in this space: linkedin.com. Despite now having AAAA and NS, the entirety of their CDN is not IPv6 accessible, requiring IPv4 as yet another crutch.

While it is tempting to say "We will be in a dual-stack world for many more years, so I don't have to worry," this is a self-fulfilling prophecy. We must continue to strive for the end-game of complete IPv6 accessibility in order to reduce the amount of time we have to maintain and troubleshoot two IP stacks. LinkedIn and Facebook have noted in public forums that they are still actively working these problems. The rest of these sites have been eerily silent on the matter.

For those of you who are trying to get ahead of Google, et al on your IPv6 deployment, I recommend checking out the Mythic Beasts IPv6 Health Check. It is more thorough than the ip6.nl check, and more importantly, it offers guidance on how to get a perfect 10.