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.
Here is a problem...
Another problem
I only went back 24 hours...
1 Like
Have you tested your network's v6 compatibility with a site like test-ipv6.com or ipv6-test.com?
3 Likes
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.
2 Likes
I'd try
ping 2001:4860:4860::8888
ping 8.8.8.8
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.
I have no latency issues here on: 6to4, 6in4, and native IPv6, on multiple ISPs and devices.
1 Like
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. 
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.
2 Likes
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.
Edit:
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.
There.
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
and
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).
8 Likes
Well said. I believe that cgNAT is one of the main uses cases that makes IPv6 really important to home users.
Anyway IPv6 is indeed much more complicated to configure than IPv4. If the default configuration just works, life is good. But if you need to troubleshoot it, then there are so many IPv6 concepts that are really hard to grasp (router announcements, relay x server, prefix delegation /56 vs /64, etc). While I have a good understanding about IPv4, I still do not fully understand many of the IPv6 configurations available in OpenWrt. Luckily there is a ton of documentation about this, but sometimes they are hard to follow and may require a significant learning curve.
Back to the topic: while I have IPv6 enabled in my network, I have had some issues with my ISP using different routes for IPv6 (compared to IPv4). Specifically in one case my ISP did not have an IPv6 route to a server in my country. The route went abroad and then returned (latency of ~220ms), while in IPv4 the latency was ˜2ms. I've also have many problems with DNS resolving different CDNs for IPv4 and IPv6. While DNS resolved a CDN with an IPv4 very close to my location (~2ms), with IPv6 the CDN was resolved to a location far from where I live (still inside my country, but with ~30ms of latency).
So while I agree that IPv6 is important and should be used by default, I still see the following issues that hopefully will be mitigated as this technology matures:
- On users' side (any home router), if IPv6 does not work "out of the box", troubleshooting it may be quite difficult due to its complex configuration when compared to IPv4.
- On ISP side, at least in my experience, IPv6 routes are still not as optimized as IPv4 routes. Also due to DNS issues CDNs are often resolved to different locations for IPv4 and IPv6. These two issues together (IPv6 routes and DNS resolution not optmized) may result in a higher latency using IPv6 when compared with IPv4.
4 Likes
This can cut both ways, there was a time my ISP had shorter less congested routes for IPv6 than IPv4 (for some target servers), but they surely can be different which can be surprising when encountered the first time...
1 Like
Same here, my ISP has some weird MPLS network and depending on the dynamic /64 prefix you get delegated from them routing can be worse over IPv6 than IPv4
sudo traceroute -6 -eA --back 2001:4860:4860::8888
traceroute to 2001:4860:4860::8888 (2001:4860:4860::8888), 30 hops max, 80 byte packets
1 2800:bf0:174:11d7::1 (2800:bf0:174:11d7::1) [AS27947] 0.253 ms 0.244 ms 0.224 ms
2 2800:bf0:1fff:f4a0::1 (2800:bf0:1fff:f4a0::1) [AS27947] 9.372 ms 9.295 ms 9.250 ms
3 fd00:0:0:8a4::1 (fd00:0:0:8a4::1) [*] 2.037 ms 2.047 ms 2.229 ms
4 ::ffff:10.201.222.36 (::ffff:10.201.222.36) [*] <MPLS:L=49710,E=0,S=0,T=1/L=48725,E=0,S=1,T=1> '-5' 2.059 ms 2.093 ms 2.070 ms
5 ::ffff:10.201.222.24 (::ffff:10.201.222.24) [*] <MPLS:L=50148,E=0,S=0,T=1/L=48725,E=0,S=1,T=2> 1.966 ms 1.938 ms 2.388 ms
6 2800:3f0:8060::1 (2800:3f0:8060::1) [AS15169] '-9' 16.783 ms 2607:f8b0:82a4::1 (2607:f8b0:82a4::1) [AS15169] '-9' 89.231 ms 2800:3f0:804f::1 (2800:3f0:804f::1) [AS15169] '-9' 13.472 ms
7 dns.google (2001:4860:4860::8888) [AS15169] '-12' 87.703 ms dns.google (2001:4860:4860::8888) [AS15169] '-11' 15.240 ms dns.google (2001:4860:4860::8888) [AS15169] '-12' 98.977 ms
sudo traceroute -eA --back 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 homelab-router.lan (10.1.0.1) [*] 0.248 ms 0.364 ms 0.327 ms
2 186.33.134.1 (186.33.134.1) [AS27947] 6.517 ms 6.465 ms 6.398 ms
3 10.224.11.10 (10.224.11.10) [*] 3.372 ms 3.324 ms 3.257 ms
4 10.201.222.36 (10.201.222.36) [*] <MPLS:L=49710,E=0,S=0,T=1/L=49535,E=0,S=1,T=1> '-5' 2.457 ms 2.404 ms 2.339 ms
5 10.201.222.24 (10.201.222.24) [*] <MPLS:L=50148,E=0,S=0,T=1/L=49535,E=0,S=1,T=2> 2.272 ms 2.209 ms 2.378 ms
6 * * *
7 dns.google (8.8.8.8) [AS15169] '-11' 13.039 ms 13.220 ms 13.221 ms
But I don't care since browsers will pick whatever is faster 
2 Likes