On 2015-06-29 18:30, David Schweikert wrote:
Hi,
I tried to report this issue to the Cablecom support, but I wasn't very successful...
Recently, it looks like my home Cablecom connection was migrated to a DS-Lite setup. I get a public IPv6 address and a private IPv4 address. My IPv4 packets get encapsulated in IPv6, sent to a NATing gateway in the Cablecom network, and NATed there.
Have fun playing any kind of online game, especially Playstation based...
Oh and of course, do enjoy too the overloaded AFTR boxes as is being reported about the German variants of Cablecom / Unity Media / Liberty Global.
What contract do you have btw, is it the 'free' edition or are you actually paying a hefty amount of money for this kind of 'service'?
Btw, don't blame Liberty Global too much for this, it was the Cable Labs consortium who decided that this was the path to go, as it frees up so many nice IPv4 addresses for the business units of the companies involved in those companies.
Oh and indeed, the reason various people got a modem replacement recently was simply as the old Thomson's do not support 6RD while the Technicolors do support it. Hence, coming likely to every end-user at one point or another... unfortunately.
At least, I have native IPv6 at home now, which is nice, but this is creating various problems for me. The worse one seems to be that path MTU is broken:
dws@shuttle:~$ ping -s 1433 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 1433(1461) bytes of data. From 192.0.0.2 icmp_seq=1 Frag needed and DF set (mtu = 1474) From 192.0.0.2 icmp_seq=2 Frag needed and DF set (mtu = 1474) From 192.0.0.2 icmp_seq=3 Frag needed and DF set (mtu = 1474)
192.0.0.2 is in the DS-LITE /24. Thus that is a node of theirs reporting this.
But there is not directly anything wrong with the above, just means that your box needs to fragment it and they don't do it for you (as that would mean state and then the thing will really completely burn down).
So some Cablecom router is sending ICMP errors saying that I should fragment the packets to at most 1474 bytes, when in fact I am sending packets that are 1461 bytes long.
Likely that is missing the overhead of the tunneled traffic.
As you can see above, ping doesn't work at all with path MTU discovery, because the discovered MTU is incorrect.
If I manually reduce the size to 1460, it works, so this seems to be the real MTU:
dws@shuttle:~$ ping -s 1432 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 1432(1460) bytes of data. 1440 bytes from 8.8.8.8: icmp_seq=1 ttl=58 time=10.4 ms 1440 bytes from 8.8.8.8: icmp_seq=2 ttl=58 time=10.6 ms
Do you agree with my analysis that this is a problem in Cablecom's network?
Depends where the MTU setting comes from.
Do realize that this is not the only thing that is breaking heavily with DS-Lite.
Greets, Jeroen