• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

Need some help tracking down connection problems.

Started by Quill, April 02, 2013, 08:40:15 PM

Previous topic - Next topic

Quill

I'd appreciate some help tracking down a connection issue with two sites on the same domain. As far as I am aware, I have no problems anywhere else, when connecting over IPv6. Also, every test I've tried comes back good.

The two sites in question are:
help.comodo.com - 2a02:1788:4fd:cd::c742:cde6
downloads.comodo.com - 2a02:1788:4fd::b2ff:5201

If I set my router to default settings it uses an MTU or 1480, which is reflected in the OS with

netsh int ipv6 show subinterfaces

However, my IPv6 MTU is actually 1320 - due to the connection type with my ISP. If I set the router MTU manually to 1320, I can connect. However, I haven't needed to make this change for any other site I've connected to so far.

So, my question is, why is the connection failing on these sites, when using default settings, when it appears to work everywhere else?

Thanks for any help.



kasperd

Quote from: Quill on April 02, 2013, 08:40:15 PMwhy is the connection failing on these sites, when using default settings, when it appears to work everywhere else?
Because those sites have a flaw in their PMTU discovery.

I was able to reproduce the problem on help.comodo.com by setting a link MTU in my own LAN to only 1280 bytes. The first time I reproduced it, I had mistakenly dumped the traffic on the wrong side of the low MTU, so I didn't see much. All I saw was five packets:
SYN
SYN+ACK
ACK
HTTP request
ACK

That is typical in case of a PMTU problem.

I repeated and dumped the traffic on the proper side of the link with low MTU, to see more of what is going on. But this time it behaved differently.

As expected I received packets, which were too large for the 1280 byte link. They were rejected using ICMPv6 Too Big error messages. The TCP stack on the server side responded properly to that by splitting the TCP segment in two and retransmitting it. But later packets indicated a serious flaw. Even after retransmitting the first segment split into smaller segments, it kept producing new segments, which were over 1280 bytes.

This flaw in itself would "only" waste half the bandwidth, but it should still have worked. And it did work for a little bit. But eventually it stopped retransmitting the segments, even though I kept responding with too big messages. One possible explanation is that they have a firewall rate limiting the Too Big messages, which when combined with the flawed TCP stack exhibit this symptom.

The reason it did not work at all the first time might be that somebody else had just been hammering their firewall with Too Big messages.

Quill

Thank you for taking the time to investigate this and for the explanation.

If I may, when you say "I repeated and dumped the traffic on the proper side of the link with low MTU, to see more of what is going on." does that mean you simply moved the monitor from the LAN side of the link to the WAN side?

Thanks again

kasperd

Quote from: Quill on April 03, 2013, 06:11:51 PMdoes that mean you simply moved the monitor from the LAN side of the link to the WAN side?
Sort of, but not exactly. You won't see much on the link with the lower MTU regardless of which end of it you look at the traffic. I needed to look at the traffic on the WAN side of the router generating the ICMPv6 error. Any point between that router and the edge of my own network would work, so I actually looked at the 6in4 traffic right at the link towards the modem.