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
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
Hi Jeroen,
Thanks for writing back.
On Mon, Jun 29, 2015 at 18:50:47 +0200, Jeroen Massar wrote:
Recently, it looks like my home Cablecom connection was migrated to a DS-Lite setup.
[...] 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'?
It's a quite expensive package (95.-/month)...
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).
Are you sure that there isn't anything wrong with the above? It seems to me that Path MTU discovery can't work, if the MTU reported by the router is not correct. That there is no other ICMP message from any other router.
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.
Yes, I guess so too.
Cheers David
Hi David
I forwarded all 4 e-mails to the project team which forwarded it to Engineering and they'll analyze it and investigate.
BTW: we have multiple CGN boxes (carrier grade NAT) and monitor usage so we can extend capacity if needed.
Regards, Dominik
On 2015-07-02 10:14, Angehrn, Dominik wrote:
Hi David
I forwarded all 4 e-mails to the project team which forwarded it to Engineering and they'll analyze it and investigate.
BTW: we have multiple CGN boxes (carrier grade NAT) and monitor usage so we can extend capacity if needed.
Sounds like a great presentation to give at SwiNOG with one of the tiles of: "Scaling DS-Lite to millions" "Why we should not have deployed DS-Lite" "Problems we found and where unable to solve with DS-Lite" etc...
This as there are LOTS of complaints about getting forced DS-Lite on various German forums about the German edition of Cablecom about overloaded AFTR boxes and lots of problems with Playstation, VPNs and other services that suddenly completely break and leave people flabbergasted as they can't resolve it while before everything just works. Hence, lots of people complaining that IPv6 is the issue, while it is the big NAT that is causing them.
Would be great to hear what has been attempted to address this.
Also, it would be awesome if the UPC Cablecom website was updated to clearly state which contracts get DS-Lite and which get native IPv4/IPv6.
Paying moneyz for Internet over DS-Lite while one is a gamer is not something one will want. Transparency thus will be a good thing.
Of course, none of the contracts tell anything about IP, let alone IPv4 or IPv6 thus nobody has a foot to stand on, which is rather annoying when there are no other choices in one's area for getting connectivity. (...something about shared cable access which would be a great thing...)
Greets, Jeroen
On Thu, Jul 02, 2015 at 08:14:17 +0000, Angehrn, Dominik wrote:
I forwarded all 4 e-mails to the project team which forwarded it to Engineering and they'll analyze it and investigate.
Thanks Dominik, I really appreciate it, and it reinforces my confidence in Cablecom.
BTW: we have multiple CGN boxes (carrier grade NAT) and monitor usage so we can extend capacity if needed.
Personally, I didn't experience any performance issues. Only MTU-related issues.
Cheers David
On Mon, 29 Jun 2015 18:30:39 +0200, David Schweikert david@schweikert.ch 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.
-
Angehrn, Dominik -
David Schweikert -
gall＠switch.ch -
Jeroen Massar