As I said: 1) "I have a native IPv6 connection on my Desktop behind my router." -> So there is no tunnel. Only native IPv6 that the Hungarian telekom.hu gives. 2) We will try out setting manually the MSS to 1392, hopefully that could be a good workaround. 3) We will try out the site: http://netalyzr.icsi.berkeley.edu/
I will post the status here later, Thanks! On Mon, Jan 20, 2014 at 11:59 AM, Tore Anderson <t...@fud.no> wrote: > * Ez mail > > > Since I have no fr**king clue what could the problem be, I'm trying on > > this list :) > > I concur 100% with Erik's assessment that this in all likelihood is a > PMTUD problem, specifically in the web_server->your_desktop direction. > > I'd just like to add that the fact that you see it happening to several > independent websites that are known to be operated by competent staff, > and that the problem comes and goes, further indicates that it is due to > rate-limiting of ICMPv6 PTB replies from your tunnel broker's tunneling > router/server. > > The ICSI Netalyzr (http://netalyzr.icsi.berkeley.edu/) will give you > very useful debugging output from the outside point of view. You might > have to run it a few times to to reveal the MTU blackhole though, due to > the problem's intermittent nature. > > As Erik mentions, lowering the TCP MSS will likely work around the > problem. You can probably do this by having the RAs your router emits to > the LAN advertise an MTU of 1452 to match your tunnel (which in turn > should make your desktop default to a TCP MSS of 1392), and/or have your > router rewrite ("clamp") the MSS value in TCP packets it forwards > to/from the tunnel to 1392. > > Or, even better, get rid of the tunneling crap and get native IPv6. This > is a very common problem for IPv6 tunnels. As a web site operator I > would actually prefer it if people stayed IPv4-only until their ISP > could provide them with properly supported IPv6 connectivity. Oh well... > > Tore >
