User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.10) Gecko/20071213 Fedora/2.0.0.10-3.fc8 Firefox/2.0.0.10 Build Identifier: Releases.mozilla.org returns an AAAA record of 2001:4f8:0:2::1f. Congrats and thank you for setting up IPv6. However, 2001:4f8:0:2::1f appears to have a broken webserver: When I try to connect to releases.mozilla.org from a host with a 1500 byte mtu behind a 6-to-4 tunnel with a 1480 byte mtu bottleneck it connects but I never get a response back. Because the most common client side deployment for IPv6 is via tunnels this problem strangely breaks connectivity for many people using IPv6. Path MTU discovery should either work or the AAAA record should be removed. (Preferably the first!) Reproducible: Always Steps to Reproduce: 1. Setup 6-to-4 to a router 2. connect router to lan with 1500 byte MTU 3. Attempt to load pages on http://releases.mozilla.org on a IPv6 enabled host on that lan. Actual Results: Pages fail to load. However, if I do a "/sbin/ip -f inet6 route add 2001:4f8:0:2::1f/128 via fe80::211:95ff:fe8b:a0ee dev wlan0 mtu 1480 advmss 1420" to let my client know the path MTU and MSS, the pages load fine. Expected Results: Path MTU discovery should work for IPv6. PMTU discovery with IPv6 works fine for me to every other site I've tested. An example session: [root@bessel ]# curl -vv releases.mozilla.org * About to connect() to releases.mozilla.org port 80 (#0) * Trying 2001:4f8:0:2::1f... connected * Connected to releases.mozilla.org (2001:4f8:0:2::1f) port 80 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.17.1 (x86_64-redhat-linux-gnu) libcurl/7.17.1 NSS/3.11.7.1 zlib/1.2.3 libidn/0.6.14 > Host: releases.mozilla.org > Accept: */* > [root@bessel ]# #I ctrl-Ced after ~30seconds. [root@bessel ]# /sbin/ip -f inet6 route add 2001:4f8:0:2::1f/128 via fe80::211:95ff:fe8b:a0ee dev wlan0 mtu 1480 advmss 1420 [root@bessel ]# curl -vv releases.mozilla.org * About to connect() to releases.mozilla.org port 80 (#0) * Trying 2001:4f8:0:2::1f... connected * Connected to releases.mozilla.org (2001:4f8:0:2::1f) port 80 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.17.1 (x86_64-redhat-linux-gnu) libcurl/7.17.1 NSS/3.11.7.1 zlib/1.2.3 libidn/0.6.14 > Host: releases.mozilla.org > Accept: */* > < HTTP/1.1 200 OK < Content-Type: text/html < Content-Length: 1501 < Date: Sat, 23 Feb 2008 07:39:17 GMT < Server: lighttpd/1.4.18 < <?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <head> <title>Index of /</title> <style type="text/css"> a, a:active {text-decoration: none; color: blue;} a:visited {color: #48468F;} a:hover, a:focus {text-decoration: underline; color: red;} body {background-color: #F5F5F5;} h2 {margin-bottom: 12px;} table {margin-left: 12px;} th, td { font: 90% monospace; text-align: left;} th { font-weight: bold; padding-right: 14px; padding-bottom: 3px;} td {padding-right: 14px;} td.s, th.s {text-align: right;} div.list { background-color: white; border-top: 1px solid #646464; border-bottom: 1px solid #646464; padding-top: 10px; padding-bottom: 14px;} div.foot { font: 90% monospace; color: #787878; padding-top: 4px;} </style> </head> <body> <h2>Index of /</h2> <div class="list">
The IPv6 site is run by ISC. Their admin doesn't seem to have a Bugzilla account, and I'm not sure what his email address is. Justin/mrz? Care to forward this along to him?
emailed peter about this.
peter says they are working on it - nothing we can fix, so closing the bug, but ISC has been notified and is working on a fix.
It's worth mentioning that almost a year later the issue with the ISC mirror and IPv6 path-mtu-discovery has still not been corrected or, if it was, has reoccurred. The result is very unfortunate— intermittent inexplicable stalling when trying to access releases.mozilla.org from an IPv6 enabled client, making it nearly impossible to install add-ons and such.
I've forwarded a copy of this to Peter again.
"I removed the second IPv6 member of the cluster at the last report of this (on Feb 1st), so all that traffic is going to one box for now which should resolve the pMTU issues. Let me know if that is not the case. Best Wishes - Peter"
or
