Okay. Fun situation. A possibly-interesting web site has a hostname, let’s say lart-me.example.com. That hostname has two IP addresses, as follows:
$ host lart-me.example.com lart-me.example.com has address 192.0.2.197 lart-me.example.com has IPv6 address 2001:db8:dead:beef::3 $
(Yes, I’m using unroutable examples. I did consider using actual hostnames and addresses.)
It’s listening on IPv4 only, probably because admin don’t know about IPv6 or it’s blocked as not being TCPv4, UDPv4 or ICMPv4 or something silly like that.
Now, add in a lack of browser (or proxy) fallback to IPv4 – don’t assume that this isn’t intentional! – and watch what happens…
Confirming that it’s not listening on IPv6:
$ telnet -4 lart-me.example.com 80 Trying 192.0.2.197... Connected to lart-me.example.com. Escape character is '^]'. ^] telnet> Connection closed. $ $ telnet -6 lart-me.example.com 80 & sleep 60; kill %1 [1] 6942 Trying 2001:db8:dead:beef::3... $
Whoops. Basically, fail.
Needless to say, traceroute6 lart-me.example.com works at least part of the way.
I see this (potentially) becoming a common problem as IPv6 spreads but admin (for example) simply don’t consider IPv6… they really need to make sure that their sites or services work properly regardless of whether the client uses IPv4 or IPv6 since, sooner or later, IPv4 is going to become Fun™ to use (consider carrier-grade NAT) and will eventually be of historical interest only.
I tried emailing the perpetrators of two such sites. One ignored me and the other doesn’t have a working webmaster@ address – which is another fail in its own right.