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. 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) 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. 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? Cheers David _______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
