[186803] in North American Network Operators' Group
Re: Another Big day for IPv6 - 10% native penetration
daemon@ATHENA.MIT.EDU (Owen DeLong)
Mon Jan 4 18:57:04 2016
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <201C563E-5546-434A-B806-83C91184CC24@delong.com>
Date: Mon, 4 Jan 2016 15:55:59 -0800
To: Jon Lewis <jlewis@lewis.org>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
It=E2=80=99s 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=E2=80=99t 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=E2=80=99t getting a 5xx on the wire and was only sending one =
request which was getting
a 3xx result and then it wasn=E2=80=99t sending an additional request. =
This led me to (erroneously)
assume that it wasn=E2=80=99t 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=E2=80=99ve 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=E2=80=99=
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=E2=80=A6 The revised statistics are now up and the results aren=E2=80=99=
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 =E2=80=9Cwrite failed: =
bad file descriptor=E2=80=9D ??? 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
