Another Big day for IPv6 - 10% native penetration

Mon Jan 4 23:55:59 UTC 2016

It’s always fun when I open my mouth in public only to turn it into a learning experience.

TL;DR version: Several enhancements to the script and to my PERL library to improve the
accuracy were made. The now more accurate results aren’t very different.

Details below:

As a result of comments received in this thread and privately about the statistics pages,
I started investigating the mysterious 5XX result codes and made several improvements to
the script.

First, I found the black text on blue hard to read, so I got rid of it. I converted the
black text to white when the background is blue.

Purely cosmetic, but still worth doing.

Next, I started digging into why was LWP returning a 5xx result code. I discovered that
it wasn’t getting a 5xx on the wire and was only sending one request which was getting
a 3xx result and then it wasn’t sending an additional request. This led me to (erroneously)
assume that it wasn’t attempting to follow the redirect.

Some additional digging led me to the fact that LWP sometimes lies to you in both the
documentation and the software.

It was following redirects and continued to do so no matter how hard I tried to tell it
not to.

I did find out how to reverse the redirect back a step ($ua->previous() will return the
response prior to the current response object in $ua if anyone cares).

Armed with that information, I started looking at what I was getting and the text being
reported by LWP with the 5xx errors. Turns out that I had neglected to install a
module known as LWP::Protocol::https which meant that any redirect to HTTPS would
fail with a 5xx result code from LWP without any packets over the wire being attempted.

I’ve also made the script slightly more optimistic in that I do now count 3xx results
as valid. This is now OVERLY optimistic in that anything that gets stuck at 3xx is
actually a failed page load (the redirect went somewhere that didn’t actually work),
but there are very few of these and they appear to relate to certificate verification
failures which may be due to the version of root cert library on my system used by
LWP more than anything else.

The legitimate results post redirect are now guaranteed to come from an IPv6 destination
because LWP is running with a source host name/address which does not have an A record
or an IPv4 address associated.

So… The revised statistics are now up and the results aren’t very startling.

DNS results are unchanged.

domain.name results are 82 (16.4%) up from 69 (13.8%).
www.domain.name <http://www.domain.name/> results are 101 (20.2%) up from 81 (16.2%)

So it only changed the results for 13-20 sites overall.

speedtest.net <http://speedtest.net/> and wikimedia.org <http://wikimedia.org/> (but not www.wikimedia.org <http://www.wikimedia.org/>) failes (500) with “write failed: bad file descriptor” ??? Write?
Interestingly, speedtest.net <http://speedtest.net/> has an AAAA record, but www.speedtest.net <http://www.speedtest.net/> does not.
mega.nz <http://mega.nz/> still errors out 500 for timeout
marca.com <http://marca.com/> still has a legitimate 500 error (timeout)

A further enhancement to the script will probably replace the short status code in the table with the full status line
for any result outside of the 2xx range.

Owen