Page 1 of 1

6rd mtu issue

Posted: Thu Apr 08, 2021 3:43 pm
by dosilicon
I'm trying to diagnose exactly what's wrong with the 6rd tunnel and connecting via IPv6 to certain sites. This is on Fusion x2 service.

Issue: browsing with Firefox to youtube.com or netflix.com is very slow or times out due to what appears to be dropped frames when they exceed the 6rd tunnel's MTU.

The issue exists with Chrome as well however Firefox seems to use "stickier" connections whereas Chrome will abandon slow IPv6 connections much faster. This causes the page to load but covers the issue up.

I think my router is properly configured. wan_stf has an MTU of 1480, igb0(WAN) has an MTU of 1500, the IPv6 default route has an MTU of 1480, and RADVD advertises a route with MTU of 1500 for the LAN. All of this seems correct. All ICMP is allowed to the router and systems on LAN net (IPv6).

I observe IPv6 TCP connections to netflix using an MSS of 1440 in both directions. Then some request is made on the client side and presumably the server responds with a full sized packet which never arrives. I would expect a router along the way to send an ICMPv6 packet too big message back to netflix but I can only assume this isn't happening. The connection stalls and after a long time RSTs.

With that observation, is Sonic blocking icmpv6 at some point in the network? Is path MTU discovery working as it should?

If I clamp MSS down to 1420 then everything works great with IPv6. Unfortunately I'm not sure how to permanently do that on my router without also clamping IPv4.

Re: 6rd mtu issue

Posted: Mon Apr 12, 2021 10:54 pm
by dosilicon
Can someone from support take a look at this?
I am not longer able to load netflix over IPv6 at all even with MSS clamping. Youtube works now for whatever reason.

What I observe now is that when connecting to netflix (2600:1f14:62a:de85:d7:e7a1:8f7d:f6f5) my browser sends the TLS Client Hello, and the server responds with the third segment of the Server Hello. Wireshark complains about the missing previous segments. If I connect via IPv4, There are 3 segments of the Server Hello where the first two are fully loaded packets (1514 bytes). In IPv6, I never receive the two missing segments of the Server Hello and eventually the connections dies.

I would expect a Sonic gateway to send a Packet Too Big message to Netflix about these oversized packets. Either the Packet too big message is getting dropped by Netflix or is not being sent. I did an experiment where I connected to a host with native IPv6 and got it to send data that would be oversized on my side due to 6rd. The packet too big messages were received from 2001:5a8:601:2:157:131:0:45. So Sonic is handling such situations correctly in some cases. Can someone check if the Sonic to Netflix link is handling PMTUD correctly?

Re: 6rd mtu issue

Posted: Wed Apr 14, 2021 6:22 pm
by julianoster
It's the weirdest thing, but since the beginning I had to set an MTU of 1472 on my tunnel interface, with my WAN interface being ab 1500.

That's 8 bytes less than 1480, and therefore 8 bytes that are unaccounted for, including all the headers on the path from me to the tunnel server. I wonder whether that's a misconfiguration at Sonic somewhere (because 8 bytes also happens to be the size of the tunnel header, and maybe a filter or something somewhere on the path was set incorrectly with that in mind), or whether there's some other internal tunneling layer that's transparent to us.

Re: 6rd mtu issue

Posted: Fri Apr 16, 2021 7:39 pm
by uzlonewolf
I haven't tried with Sonic's 6rd because tunneling is ugh gross, but back when I did this with at&t the only reliable way I could get LAN clients to use the correct MTU was to turn it down in radvd's RAs. Having the router adjust the MSS just didn't work for me. Once I set radvd to advertise the smaller MTU everything just worked. Well, as well as 6rd works anyway :? I'm currently switching to Sonic from cable and it hurts losing real IPv6.