29 Jun
2015
29 Jun
'15
6:30 p.m.
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
29 Jun
29 Jun
6:50 p.m.
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
11:42 p.m.
Hi Jeroen,
Thanks for writing back.
On Mon, Jun 29, 2015 at 18:50:47 +0200, Jeroen Massar wrote:
It's a quite expensive package (95.-/month)...
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.
Yes, I guess so too.
Cheers
David
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'?
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. 
2 Jul
2 Jul
10:14 a.m.
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
10:42 a.m.
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
11:03 a.m.
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
30 Jun
30 Jun
9:06 a.m.
On Mon, 29 Jun 2015 18:30:39 +0200, David Schweikert <david(a)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.
--
Alex
2896
days inactive
2899
days old
6 comments
4 participants
participants (4)
-
Angehrn, Dominik -
David Schweikert -
gall＠switch.ch -
Jeroen Massar