IPv6 connectivity, via 6RD, extremely poor performance.

Internet access discussion, including Fusion, IP Broadband, and Gigabit Fiber!
13 posts Page 2 of 2
by daniel15 » Mon Nov 14, 2022 5:29 pm
kgc wrote:See https://members.sonic.net/labs/ipv6tunnel/ it includes example configs.
How do we get access to this? I just see "This account (daniel15) cannot access IPv6 Tunnel services" when I go to that URL.
by nhbriggs » Thu Dec 08, 2022 3:16 pm
@willtam --

What Fastly says they're seeing is that when they respond with a packet that is as big as the MSS they see from me then it doesn't get back to me correctly. There are a few things I see that could result in this, and some possible fixes.

When Fastly responds with an IPv6 packet that is too large (but within the limits of the MSS they saw from my system) to fit within the IPv4 encapsulation:
  1. An ICMP6 Packet-To-Big response IS NOT generated by the 6RD gateway (Sonic's problem)
  2. An ICMP6 Packet-To-Big response IS generated but does not arrive back at the correct Fastly server (Fastly's problem)
  3. An ICMP6 Packet-To-Big response IS generated but is ignored (is not used to adjust the PMTU and MSS) by the Fastly server (Fastly's problem)
To fix the problem ONLY for TCP6 streams, if Sonic's 6RD gateway has the ability to adjust the client's MSS then it could adjust it down to no greater than the maximum that would result in an IP6 response that fits inside the IP4 encapsulation.

For protocols other than TCP6, if Sonic's 6RD gateway isn't generating ICMP6 PTB responses, can that be turned on?
by msiegen » Thu Dec 08, 2022 7:52 pm
We can rule out (1), as Sonic's 6RD gateway correctly generates packet-too-big messages:

Code: Select all

# ping -s 1452 -c 2 -n -M do 2602:24d:1ccb:e400::  
PING 2602:24d:1ccb:e400::(2602:24d:1ccb:e400::) 1452 data bytes
From 2001:5a8:601:2:157:131:0:45 icmp_seq=1 Packet too big: mtu=1472
ping: local error: message too long, mtu: 1472

--- 2602:24d:1ccb:e400:: ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1002ms
I would not be surprised if those are unintentionally dropped on the Fastly side though. Cloudflare wrote a whole blog post about the challenges of handling ICMP in a distributed architecture, and the ECMP load balancing they describe is standard throughout the industry.

Note that adjusting the MSS can be done anywhere along the path, so you can do that on your router without Sonic's involvement (search for MSS clamping). It would be nice if Sonic fixed it once for all customers, but with native IPv6 rolling out I don't expect 6RD to receive much new attention.
13 posts Page 2 of 2

Who is online

In total there are 21 users online :: 1 registered, 0 hidden and 20 guests (based on users active over the past 5 minutes)
Most users ever online was 999 on Mon May 10, 2021 1:02 am

Users browsing this forum: Google [Bot] and 20 guests