It was a stale DNS entry. Now fixed (modulo TTLs and such), thanks. That said, your troubleshooting was troubleshooting a different problem, not your browser's inability to retrieve the page. The way the browser sends the request is something like this (note the HTTP version and the host header): ayourtch@mcmini:~$ telnet -6 6lab.cisco.com 80 Trying 2001:420:4420:101:0:c:15c0:4664... Connected to 6lab.cisco.com. Escape character is '^]'. GET / HTTP/1.1 Host: 6lab.cisco.com HTTP/1.1 302 Found Date: Thu, 21 Nov 2013 19:38:31 GMT Server: Apache/2.2.16 (Debian) X-Frame-Options: SAMEORIGIN Location: http://6lab.cisco.com/index.php Cache-Control: max-age=1 Expires: Thu, 21 Nov 2013 19:38:32 GMT Vary: Accept-Encoding Content-Length: 295 Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>302 Found</title> </head><body> <h1>Found</h1> <p>The document has moved <a href="http://6lab.cisco.com/index.php">here</a>.</p> <hr> <address>Apache/2.2.16 (Debian) Server at 6lab.cisco.com Port 80</address> </body></html> Anyway, the fact that you were still able to retrieve the original reply with a redirect, makes me think that there could be a PMTUD problem somewhere inbetween 6lab and yourself for retrieving the larger content ... If you tell your client address I will be able to test this theory. Or you can quickly tweak your local interface value to 1280 and if that works, then tell me your client address so i could debug from the other side. --a On 11/21/13, Matthew Petach <mpetach@netflight.com> wrote:
On Wed, Nov 20, 2013 at 1:30 PM, Gary E. Miller <gem@rellim.com> wrote:
Yo Lee!
On Wed, 20 Nov 2013 16:14:47 -0500 Lee Howard <Lee@asgard.org> wrote:
There is obviously a long tail of ip4 destinations, but nearly all of 500 of the Alexa global 500 have ip6 listeners,
Do you have a data source for that? I see no indication of IPv6 listeners on 85% of the top sites.
A slightly different metric, 44% of USA content available on IPv6:
I'm puzzled; I have native v6 connectivity to 6lab.cisco.com according to traceroute6 output, and yet the page says I'm connecting to it via IPv4. :( So, I did some poking; it seems 6lab.cisco.com doesn't have working IPv6 for their stats system, which makes me wonder how accurate the data from it is likely to be:
mpetach@mintyHP:~> telnet -6 6lab.cisco.com 80 Trying 2001:420:4420:101:0:c:15c0:4664... Connected to 6lab.cisco.com. Escape character is '^]'. GET / HTTP/1.0
HTTP/1.1 302 Found Date: Thu, 21 Nov 2013 19:03:29 GMT Server: Apache/2.2.16 (Debian) Location: http://6lab-stats.com/index.php Cache-Control: max-age=1 Expires: Thu, 21 Nov 2013 19:03:30 GMT Vary: Accept-Encoding Content-Length: 295 Connection: close Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>302 Found</title> </head><body> <h1>Found</h1> <p>The document has moved <a href="http://6lab-stats.com/index.php ">here</a>.</p> <hr> <address>Apache/2.2.16 (Debian) Server at 6lab-stats.com Port 80</address> </body></html> Connection closed by foreign host. mpetach@mintyHP:~> telnet -6 6lab-stats.com 80 Trying 2001:420:81:101:0:c:15c0:4664... telnet: Unable to connect to remote host: Connection timed out mpetach@mintyHP:~> mpetach@mintyHP:~> ping6 6lab-stats.com PING 6lab-stats.com(2001:420:81:101:0:c:15c0:4664) 56 data bytes ^C --- 6lab-stats.com ping statistics --- 10 packets transmitted, 0 received, 100% packet loss, time 9071ms
mpetach@mintyHP:~>
RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 gem@rellim.com Tel:+1(541)382-8588