On Mon, 29 Jun 2015 18:30:39 +0200, David Schweikert <[email protected]> said:
> 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? The tunnel adds 40 bytes of overhead for the IPv6 header, but the DS-Lite spec says that the tunnel endpoints MUST perform fragmentation and reassembly of the IPv6 packet such that the IPv4 packet can be transported without fragmentation. I suppose that this actually works, since you're getting the PTB message from the "AFTR" element's IPv4 address (the inside of the carrier's NAT), i.e. the packet must have already left the tunnel. Now, I'd expect that the MTU of the next link, which is the outside of the CGN, is 1500. In this case, that MTU appears to be 1474, which would indicate that there is another encapsulation happening upstream, but the overhead of 26 bytes (20 bytes IPv4 plus 6 bytes tunnel header) looks unfamiliar. This may be strange but it should still work. It would be interesting to understand why this additional overhead is there, though. The actual problem is the fact that packets that do conform to the advertised MTU are dropped if they are between 1461 and 1474 bytes long. That's a classical MTU blackhole and breaks PMTUD, as you say. This needs to be fixed by Cablecom. -- Alex _______________________________________________ swinog mailing list [email protected] http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
