RE: I can fetch the header of websites via IPv6 but not the webpage, why?
Hi,
> -Original Message-
> From: ipv6-ops-bounces+fred.l.templin=boeing@lists.cluenet.de
> [mailto:ipv6-ops-
> bounces+fred.l.templin=boeing@lists.cluenet.de] On Behalf Of Richard
> Hartmann
> Sent: Tuesday, January 21, 2014 12:48 PM
> To: Tore Anderson
> Cc: Ez mail; ipv6-ops@lists.cluenet.de
> Subject: Re: I can fetch the header of websites via IPv6 but not the webpage,
> why?
>
> On Mon, Jan 20, 2014 at 11:59 AM, Tore Anderson wrote:
>
>
> > 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.
>
> Unless a party has one single IPv6-enabled machine, clamping MSS on
> the gateway is probably preferable.
If you clamp the MSS to a smaller size but DO NOT advertise a small
MTU on the LAN, hosts that use RFC4821 can at a later time probe for
packet sizes that are larger that the MSS and advance the MSS size
if the probe succeeds. So, clamp the MSS but leave the MTU of the
LAN the same as that of the native link.
Thanks - Fred
fred.l.temp...@boeing.com
> > 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...
>
> Most people don't have that liberty as of right now; increasing
> adoption is arguably better, especially considering that a lot of
> people developing software need to fix part of the ecosystem.
>
>
>
> Richard
Re: I can fetch the header of websites via IPv6 but not the webpage, why?
On Mon, Jan 20, 2014 at 11:59 AM, Tore Anderson wrote:
> 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.
Unless a party has one single IPv6-enabled machine, clamping MSS on
the gateway is probably preferable.
> 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...
Most people don't have that liberty as of right now; increasing
adoption is arguably better, especially considering that a lot of
people developing software need to fix part of the ecosystem.
Richard
Re: I can fetch the header of websites via IPv6 but not the webpage, why?
1452 is the good one :D
On Tue, Jan 21, 2014 at 9:30 PM, Ez Egy wrote:
> The solution was setting the MTU to 1480 in radvd in the router:
>
> option AdvLinkMTU 1480
> # option AdvLinkMTU 1452
>
>
> On Mon, Jan 20, 2014 at 5:22 PM, Ez Egy wrote:
>
>> 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.hugives.
>> 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 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
>>>
>>
>>
>
Re: I can fetch the header of websites via IPv6 but not the webpage, why?
The solution was setting the MTU to 1480 in radvd in the router:
option AdvLinkMTU 1480
# option AdvLinkMTU 1452
On Mon, Jan 20, 2014 at 5:22 PM, Ez Egy wrote:
> 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 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
>>
>
>
Re: I can fetch the header of websites via IPv6 but not the webpage, why?
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 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
>
Re: I can fetch the header of websites via IPv6 but not the webpage, why?
* Hannes Frederic Sowa > Tunnels should actually work fine and icmp rate limiting should take > place per destination (or on a /64 boundary). Either someone messed up > their filters or we have a software bug (maybe we should just introduce > a netfilter target which does mid-path fragmentation of IPv6 packets :P ). The key word here is "should" ;-) In my experience the reality is more grim. DIY-tunnelers are greatly over-represented in the users that report IPv6-related problems. It would appear that DIY-tunnelers has a special attraction to people who are in that dangerous middle ground of cluefulness where they are fully capable of tinkering around and changing all sorts of stuff, yet lacking the clue to actually fully understand what they're doing, why their stuff doesn't actually end up working very well, or how to actually get it working again. (I'm saying that *every* DIY-tunneler fit that description, just that they're over-represented.) Centrally managed tunnels like 6RD fares better. Presumably the providers responsible for those know that relying on PMTUD to work flawlessly 100% of the time for 100% of the destinations on the internet is a non-started, and implement tricks like RA MTU Options and/or TCP MSS clamping to give the subscriber a better chance of having a good user experience. (This isn't anything new with IPv6, BTW, clamping the TCP MSS was commonplace in IPv4 PPPoE deployments too, for exactly the same reasons.) Fortunately the DIY-tunnelers constitute an insignificant amount of users, so it's okay to simply tell them «you broke it so you get to keep the pieces». Had there been significantly more of them we would probably have felt forced to jack down the MTU/MSS on the server end, which would have been a real shame because that would be something that would have impacted all users, including those with native connectivity. Also worth noting is that even if PMTUD would have worked 100% of the time, its still not without cost; the time to first byte on a download gets a penalty equal to the RTT between the server and the tunnel ingress server/router. So you end up with a worse user experience than with IPv4 even though the network latencies/paths are identical. Tore
Re: I can fetch the header of websites via IPv6 but not the webpage, why?
On Mon, Jan 20, 2014 at 11:59:39AM +0100, Tore Anderson wrote: > 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... Tunnels should actually work fine and icmp rate limiting should take place per destination (or on a /64 boundary). Either someone messed up their filters or we have a software bug (maybe we should just introduce a netfilter target which does mid-path fragmentation of IPv6 packets :P ). We had some pretty significant bugs in pmtud in linux which were fixed some while ago: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e3bc10bd95d7fcc3f2ac690c6ff22833ea6781d6 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=01ba16d6ec85a1ec4669c75513a76b61ec53ee50 But they have not yet been integrated in all the vendor's kernel. Especially on heavy loaded servers we need some way to ensure longer pmtu lifetimes in the routing table. Currently they can easily get evacuated too fast if lots of IPv6 flows hit a linux end host and should hold on at least the minimal time the administrator had configured. Greetings, Hannes
Re: I can fetch the header of websites via IPv6 but not the webpage, why?
Hi Tore and list,
Tore Anderson writes:
> Or, even better, get rid of the tunneling crap and get native IPv6. This
> is a very common problem for IPv6 tunnels.
\begin{fundamental}
fair enough, except of course that this isn't a problem with the tunnels
as such, but with whoever messes with the ICMP PTBs. While this
approach does work as an immediate kludge, it also removes the pressure
to actually find and fix the real cause, which may eventually establish
the kludge as a "best practice solution".
\end{fundamental}
Cheers,
Benedikt
--
Benedikt Stockebrand, Stepladder IT Training+Consulting
Dipl.-Inform. http://www.stepladder-it.com/
Business Grade IPv6 --- Consulting, Training, Projects
Re: I can fetch the header of websites via IPv6 but not the webpage, why?
* 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
