IPv6 latency issue

When opening both IPv4 and IPv6 simultaneously, some apps and web pages experience severe latency, How can we easily and conveniently solve this problem in Luci? I have opened OPENWRT's MSS CLAMPING, but it seems that it does not work

Do you want to continue using IPV6?

Of course, if it's not for the delay caused by simultaneously opening them, why not open IPv6

They really need a sticky for IPV6 and navigating it in LuCI.

It causes a lot of issues when not configured correctly and some ISPs don't use it at all.

:spiral_notepad: Here is a problem...
:spiral_notepad:Another problem

:spiral_notepad:And another

I only went back 24 hours...

:spiral_notepad:Someone that totally understands IPV6 gives up on it.

1 Like

Have you tested your network's v6 compatibility with a site like test-ipv6.com or ipv6-test.com?


See, that is exactly what I'm talking about:

We should all have a diagnostic tree, with that being the first step, when dealing with IPV6.

I'm half inclined to request all IPV6 fields be on the same page with an explanation under all of them.. Instead of hunting around looking for things to config.

And if someone has configuration fatigue, because this is their first time using OpenWrt, one option to disable all of IPV6 right up front providing some time to decompress before learning a new network protocol language.

Because some ISPs have poor IPv6 uplinks and browsers try to use IPv6 first, then (if something goes bad), after timeout, switch back to IPv4. Essentially we have two totally different incompatible Internet protocols and client software has to choose which one to use.


I'd try

ping 2001:4860:4860::8888

Both ping google, the first will do it over IPv6 the second of IPv4 - if IPv6 has a problem, it should show up in the ping.

1 Like
  • Setting up a [legacy] technology that's been discontinued for years - I wouldn't call an issue
  • The OP didn't have an issue, they wanted to know how the technology passes packets between IPv4 routers, IPv6 routers and vice versa (the discussion was lengthy because I was confused the OP was using 6to4)
  • I'm not sure if a legacy 6to4 tunnel service is a good analogy of someone having issues, e.g. compared to a user with native IPv6 service from the ISP
  • I'm really lost at this notion that pings to Google IPs somehow reveal how actual traffic and service will work during actual Internet usage to other non-Google networks
  • If it's not native IPv6, you have to consider the latency of the traffic on the IPv6 network, the router that translates from v4 to v6, de-prioritization of IP Protocol No. 41 packets by the IPv4 ISP, etc. :wink:

I have no latency issues here on: 6to4, 6in4, and native IPv6, on multiple ISPs and devices.

1 Like

This should be a challenge,

You linked the last post in a thread. It wasn't clear what "challenge" you were referring to. I think you're saying that there's an issue setting up dynamic IP address on Wireguard?

That's not specific to IPv6 - and the OP solved it the way most users do, with Static IPs from HE via 6in4 (there are other solutions in the forums too). This is a known limitation of Wireguard's design.

You still have to consider (latency-wise): WG VPN CPUs, the translation, routing to HE over IPv4 by the ISP (and possible de-prioritization of the Protocol No. 41 packet along the way - same as 6to4), etc.

Maybe I missed why you linked the thread?

If only that was the only issues in that thread. :zzz: :zzz: :zzz:

Look, if you want us to understand your arguments, you will need to make them explicitly, just linking to a thread without context is a waste of everybody's time including yours.


I agree with @moeller0 - I'm unable to identify a single "latency issue" from all these linked threads.

  • One issue appeared to be no public IPv6
  • One issue seems to be DNS
  • As noted, the other seems to be asking how 6to4/6in4 passes traffic between v4/v6 routers (i.e. no issue; but I think the OP did mention latency here, but would never acknowledge how Proto 41 traffic actually traverses the v4 network)
  • Lastly, one seems to be dynamic IP setup on Wireguard

Maybe you can provide details of the "IPv6 latency issue" you're referring to

Are you intending to ask for the same things with IPv4, or maybe you can explain what's special or different - to require this special treatment?

Is this still remnants of old IPv6 Transition Fears and Stigma???

  • IPv6 has been out for years, time to learn.
  • Time for ISPs to pay a few hundred and register some IPv6 space with their RIR
  • Time for small ISPs to upgrade old routers and edge equipment - and support IPv6
1 Like

All I did is say it does not work with the majority of ISPs and websites which leaves people frustrated and in the dark about implementation and it needs a sticky. Twenty years plus and it is still a quagmire.

I'm not blaming the forum. I'm not blaming you personally.

I am so sorry I suggested a sticky that starts with a simple test to see if one's ISP even does IPV6.
Why you guys are taking IPV6 personally, as if you invented it and it is your project baby, baffles me.


I am dissapointed that a couple of you spent more time putting me in my place, in this thread, rather than actually help the OP.
Or is this the solved answer that supports my position IPV6 is a quagmire of issues?

Citation needed... this is a rather bold claim, so can you back it up with more than anecdotal data?

I do not think I am doing this, and I lay no claims on IPv6, I do have issues with what I consider un- or at least underfounded claims of IPv6 not cutting it. While certainly not perfect it works just as well as IPv4, albeit different in some aspects.

Yeah, that is not how public fora work... you make wild claims, you should be prepared to back them up or expect some scrutiny. Or just ignore posts you consider unhelpful, but trying to chastize others for not liking your posts rarely improves much.


If you think I'm going to get in a pissing contest with you in this forum you are mistaken.
This is my last post on this subject.

Fair enough, I just note that you seem to consider


as equivalent... for me I want to see proof for the former claim, the latter seems trivially true. Yet what to do/recommend by default pretty much depends on what the true state of IPv6 is in the field.

Okay, I'll try to clean up what I was suggesting:

IPV6 has many implementation issues that are beyond the skillset of moderately informed IPV4 users imagine.

IPV6 has been pushed for over 20 years and the infrastructure is, practically, missing.
People think it is better and they need to get it working and it is better but it takes more skills than the average person has.
No one really needs IPV6 and it would be nice if there was a sticky explaining what a person will need to become versed in to make it run smoothly.

Something like: "So you want to add IPV6 support" here is a list of configurations needed and does your ISP even support it is the first step; here is how to find out.

Then list every field that affects IPV6 so people can look at it and go "I'd love to do some more configuration and embrace possible problems because the route to website x does not use it. I'm fine with all my work just being translated into IPV4 most of the time"

Or to look at the configurations and inherent issues even perfect setups will have and think to themselves "nah, I'm fine".

This aspect is wrong, unless I'm this hypothetical no one, but somehow my passport has a different name on it. There are many cgNAT users and those numbers are only increasing, for those (e.g. me), IPv6 is the only option to get a public IP address, to get any incoming connections:

Additionally, at least around here, data centres have started charging extra for IPv4 addresses - yes, you can still get root- or v-servers with IPv4 addresses, but you have to pay for that privilege, while an IPv6 prefix is part of the base price. While you might need to pay that extra tax for hosting public resources, there are many use cases that are cost sensitive and only need to accommodate a short list of users (e.g. friends and family, where you can insist on IPv6-only and help them getting it working).

Around here (.de), IPv6 suddenly started becoming available natively among all larger ISPs (including mobile ISPs) around 2013-2015. Early on you might have had to opt-in (selecting a non-default APN or giving their customer support a call to enable it), but nowadays it is usually provided by default.

In general, there are two large blocks of users:

  • those whose ISP doesn't hand out IPv6 addresses, offering IPv4-only
    no problem with OpenWrt here, you only get link-local and ULA addresses on the LAN side, but no IPv6 connections are attempted to the outside (no globally routable prefix announced).
  • those whose ISP is supporting IPv6, more or less correctly
    in many cases the OpenWrt default configuration will just work here, transparently. Clients will get global IPv6 addresses and can connect to remote IPv6 hosts. many users might not even notice IPv6 being there.

There are two problematic use cases:

  • the one where the ISP is doing stupid things, offering partial- or borderline broken IPv6 support, this can cause issues (and delays), but if an ISP is this incompetent in 2024, they will mess up many other aspects of their operations as well.
  • multi-wan setups are a bit more complex, not in theory, but in practice, as it requires either both ISPs to cooperate (transit of the alien prefixes, if they do that, it's easy) or things like NAT66.

At least the former of these should go extinct by the passing of time, as IPv6 is more and more prevalent.

On average, around 60% of my monthly traffic is IPv6 based, it works today and it's there to stay. The IPv4 address shortage isn't going away, it's just getting more severe - and any hypothetical 'prettier' alternative to IPv6 would take another 30 years to get deployed in the field (and it's safe to assume that isn't going to happen, ISPs and backbone operators have already paid for their IPv6 infrastructure and it's also available in almost all modern customer routers- and endpoint devices, maybe not on-by-default, maybe not working perfectly, but it's there and in wide spread use).