On the IPv4 level, yes. And without ignoring things like ICMP, as there might just be an error message coming back from something. But if there is a hop that is misconfigured (eg 1492 instead of 1280) then this fails as it just checks ICMP. Tracepath is a good indicator of MTU issues, and showing what it is estimated to be, it is not fool proof. But it is important, as your tunnel goes from your endpoint to the tunnel endpoint (eg a PoP), it does not go to the random host you selected. Those paths will thus be different and might have different properties. Completely different? That is, all hardware is different? The whole path is different? What is the same? I am starting to think of hardware issues seeing the type of corrupted packets you are showing in the other message. Not necessarily. If something is misconfigured either inbound or outbound tracepath won't catch that. You need to look from both sides of the link. Also there are still hosts on the Internet that do rate limiting of ICMP for instance that horribly break things. Tracepath/route? :) More details please. I guess you have never been a DOCSIS user where sometimes only packets <512 bytes go through I guess? :) Hardware and links can have soooo many problems, it is not funny. That is why networking people have jobs.... I am thinking of hardware issues.... could just be a weird cable somewhere or humidity affecting things.

Packet 85 shows that that packet arrived out of order, as the previous segment was not captured. Packet 86 is a previously unseen, but acked, packet. That is rather weird don't you think? That means that your host did ack it, but your pcap did not see it. What system is this? :) Also where are you doing the pcapping? Packet 103 is completely corrupt indeed. That packet SHOULD have never been forwarded. Fun detail: that packet does NOT come from SixXSd. Check the previous packets, where the ID is always 0x4200 as that is what sixxsd sets it to. Also the destination address is mangled by then, thus sixxsd would not be able to send it anywhere. Packet 103 arrives with that set to 0x0000. Now you will also see that the whole packet is "offset" as the destination IPv6 address contains the real source address!!!! Magically there is a correct "60" directly after the proto-41 packet. Payload length of 16896 though is completely broken. At 0x40 of the packet there is the source address and from 0x50 there is the destination address, still in tact. The rest seems to be plausible for an IPv6 packet. Actually, if you check, there is a '60' at 0x38, and if you retarget Wireshark, the rest parses perfectly as an IPv6 packet. Something thus inserted bytes 0x24 - 0x38 into the packet. That corruption MUST have happened between sixxsd (the PoP) and your side of the IPv4 endpoint on the IPv4 layer. Instead of testing SSH, I would suggest doing a plain-text ncat between two hosts of some large file with line numbers and then per line say 1000 AAAAAAAA.... and then next line BBBBB... in them. That way you will see the proper order in wireshark and can see where the packet goes wrong.