Yesterday I read this toot (German) over on mastodon which starts with “IPv6 is hard.”

No it’s not. It’s different.

I ran across this multiple times: There is an A and an AAAA-record for a FQDN, but the web server is only reachable via IPv4. You can easily test this with curl

$ curl -4  https://github.com -o /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  273k    0  273k    0     0  3417k      0 --:--:-- --:--:-- --:--:-- 3553k
$ curl -6  https://github.com -o /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (7) Couldn't connect to server

When using IPv4 273k are “saved” to /dev/null, using IPv6 we get an error message “Couldn’t connect to server”

Note that I’m using GitHub here because it is a well known example for not offering IPv6 as a time of writing, and it probably will have not IPv6 soon.

So in the case of the toot mentioned above there is an AAAA for the FQDN. But the connection doesn’t work. But the end user doesn’t notice. Because there is a browser feature called Happy Eyeballs (HE). Basically: A browser tries both protocols and uses the faster on. In case of non-working IPv6 IPv4 is always faster.

HE can have some funny side effects. In a project a connection to a development web server sometimes worked and sometimes didn’t. The solution was quite simple. The customer used a split VPN tunnel. IPv4 was routed via the VPN tunnel and those IPv4 addresses were allowed in the web servers access list. IPv6 was routed via the normal Internet connection and those addresses weren’t allowed.

But back to the original problem: In another toot we learn that a support ticket was opened four weeks ago and that traceroute was prohibited. But there is always the option to use the -T option for traceroute or tcptraceroute. This use tcp instead of UDP (standard traceroute) or ICMP (Windows tracert).

When you run traceroute -T for both IPv4 and IPv6 you’ll see that in this case IPv6 ends one hop earlier than IPv4. Or in this case the last hop loops back to itself.

This could mean that there is a missing firewall rule allowing traffic to the server or there is a routing issue on the firewall.

But we can learn much more from this:

  • If browser wouldn’t do happy eyeballs, the support hotline would have been exploded
  • There is no external monitoring, at least not for IPv6
  • There is no automation or at least no complete automation

So please: If you do IPv6 take it seriously. If you don’t take it seriously, don’t do IPv6. That leaves to people thinking that IPv6 is hard and can not be done.

Some notes: I’ll cover traceroute and co. in a future blog post and regarding GitHub check out this link.