Openwrt 21 - router as access point

I think if no ipv6 internet access is available ipv6 will use use link local addresses exclusively, which no endhost should try to use to reach the internet. I would not disable IPv6 on the primary router....

1 Like

No, at least not without tunneling ipv4 over an ipv6 link which is not normally the case.
If the isp does not provide ipv6 support then you should disable ipv6 everywhere as it will serve no purpose and can cause long delays connecting for many devices eg Android and Apple as mentioned before.

I actively disagree. OpenWrt core developers have stated their intent to develop into the future with the assumption that at least link-local IPv6 will be available. Anybody disabling IPv6 completely should be aware that they are running an increasingly under-tested configuration. IMHO it seems more future-proof instead to run the default configuration and post bug reports if problems do come up.

Disabling IPv6 as a diagnostic whether the wife's iphone issues are IPv6-related seems IMHO sane advice, disabling IPv6 completely "just because it might cause issues" however is IMHO less so.

5 Likes

Well yes I do see that point of view. By disable I mean stop all ipv6 dhcp and advertising onto the lan. That is the easiest to do anyway.
I would only remove ipv6 support when desperately trying to build an image for a legacy device with very limited resources.

1 Like

Dumb question but my Windows PC gets an IPv6 lease and works fine. Does that mean it gets IPv4 lease at same time? Otherwise how does it work?

I'm sure it works fine without any IP address, too.

Define works fine.

1 Like

Some OS designers strive hard to make OS's capable of running on IPv6-only networks. Not only is it possible, but it shows that the engineers took pains to test in that scenario. Some parts of the world are out of IPv4 addresses and are using IPv6-only on the new customer equipment. They then use carrier grade NAT to map the IPv6 addresses to IPv4 for the cases where the server has no IPv6 address advertised. In cases like that the customer won't see any IPv4 addresses at all.

So hang on a minute. Where ISP is IPv4 only and say router only gives out DHCPv6 leases. Does the client get internet connectivity?

If not in my case I presume my Windows PC gets IPv4 and IPv6 lease simultaneously and uses IPv4 to connect?

In all likelihood not, unless the router implements a translation from internal IPv6 to external IPv4... looks doable but you would need to have special reasons for doing that...

That is the default for modern operating systems, allowing both IPv4 and IPv6, while picking the viable version on a connection by connection basis. However if your ISP does not provision IPv6, OpenWrt will use link-local IPv6 addresses only and no standards compliant end device should (by default) even think about reaching the internet over those addresses.

It is still possible that your wife's issue is somehow IPv6 related, but it is not a slam-dunk smoking gun kind of situation. In all likelihood ISPs will switch more and more over to IPv6 (due to lack of IPv4 addresses) so getting your network IPv6-ready will not be wasted effort in the long run.

2 Likes

Absolutely not - at least without a lot of hard work and probably expense. You could possibly set-up/create some kind of translation, but why bother. Just ensure the client gets an ipv4 address and stop it from getting the ipv6 address in the first place. Translation is a non-trivial task as ipv4 and ipv6 are very different.

In the real world, ipv6 to the customer is not "rolling out" as fast as predicted due to address translation making it not as urgent, combined with the support issues ISPs would have with customers having houses full of ipv4 configured devices and the average customer having no technical knowledge or experience in the subject. An ISP helpdesk nightmare....

1 Like

I have actually done significant research into this (in the area of developing/supporting large public wifi networks with captive portals).
IF you have dhcp issuing ipv6 addresses (but no ipv6 Internet connectivity), both Apple and Android devices will "prefer" ipv6 and take a significant time to fall back to ipv4, if at all.
The smoking gun is that if dhcp for ipv6 is turned off, the problem goes away.

OK related follow on question.

Where OpenWrt hands out IPv4 lease and IPv6 lease but the latter is only link-local because ISP only supports IPv4 what happens with DNS requests say from a Windows PC that has acquired both leases?

Will DNS requests ever get sent out via IPv6 then and if so how is that handled?

And how does this all work in multiple AP context with gateway etc.?

AS I said, valid diagnostic advice. I maintain my position though that disabling IPv6 without evidence is being part of the problem, not part of the solution.

Great, but will this actually also apply to a private OpenWrt deployment without captive portal? As before disabling IPv6 address assignment for testing is a good proposal for diagnosis here.

Please elaborate whether that applies to the OpenWrt situation where without IPv6 uplink only link-local addresses or ULA will be used by endpoints? As far as I can tell from my mac, it tries to probe some apple addresses to figure out whether the network is reachable and should on normal Open Wrt without IPv6 uplink never get the impression the ULA would reach the internet (even if it erroneously would think the ULA would allow that in the first place).

Again windows clients will know that neither link-local nor ULA addresses can reach the internet (and the OpenWrt router will not propagate a default IPv6 gateway when it lacks IPv6 uplink). So as far as I can tell that situation simply will not happen. And in case it still does there is happy eyeballs to the rescue.

Again to be explicit, by all means try to disable to see wether your iphone problems are IPv6 related, but please do not hold your breath, it is by no means guaranteed that this is your root cause.

1 Like

DNS requests will primarily be sent to your router (unless you manually configured your endhosts to use different DNS servers)... and that would be reachable via IPv4 and IPv6. But the records it returns should contain (if they exist) both IPv4 and IPv6 addresses so the endhost can pick the best address to use (or can try both concurrently).

APs do not really matter here (if the act as pure APs and do not route themselves), your primary router's configuration however does matter.

1 Like

Yes, of course. A captive portal is just a special case of a firewall - but it is the client side of captive portal detection that causes the problem.

Indeed, this is the de-facto standard for captive portal detection (CPD url - sometimes called the Canary Test URL). The client operating system has built in support for this and generally uses a cut down "mini browser" to display any eventual portal login pages.

In this scenario (ipv6 dhcp but no ISP ipv6) the client device will attempt to dns resolve the CPD url. As it has an allocated ipv6 address DNS will fail and the device assumes it does not have an Internet connection. (if a captive portal was present it would get an ip address from DNS).

The de-facto standard for re-testing CPD is 300 seconds (but depends on the vendor) and is linked to the wireless SSID, not the layer 3 protocol.

So at best there will be a delay equal to the CPD re-test interval before a connection is possible, at worst, the client will never connect (again depends on vendor). As the "portal" browser is a special limited functionality browser, happy eyeballs may not apply.
Note: A special mini browser is used for security reasons as a "Captive Portal" could actually be a man-in-the-middle attack on the client.

@Lynx is not using a captive portal as far as I can tell, so I am not 100% convinced that his iphone issues are related to captive portal detection. But again this hypothesis that the problem might be related to IPv6 is easy to test...

He does not have to, all modern client operating systems have a built in CPD. It is the client
that drives this to determine if a captive portal exists.

As far as I am concerned, it is not a hypothesis but a verified problem with a valid solution.

Look with his internet being available all the time (modulo router reboots) the captive portal test will resolve quickly... showing (assuming the client OS tests both IP families) that IPv4 works, while IPv6 does not (but again given the set of addresses the client receives from the router and the lack of an IPv6 gateway the client should not even try IPv6 in his case).

Based on what data I might ask? Because I have seen networks in which an incompatibility between the routers WiFi and the clients WiFi resulted in spurious disconnects*, but just because I have seen that in other cases does not make me assume that this is the case here.

I fail to parse this sentence, sorry. I agree that if your root-cause analysis is correct your proposed remedy is one way forward; and I also agree that testing that hypothesis is a good idea. I would however wait calling it a "valid solution" until its applicability in @Lynx's case has been confirmed.

*) The problem is described as "intermittent iPhone connectivity problems".

Hey both, I am really appreciative of your insight here, and am learning more about IPv6 in the process.

I am interested in the mechanics of this. Say my Windows PC sends a DNS request then with link-local IPv6 lease will it try to send DNS request over IPv6 and if so how would the router handle that? Or will it know not to send DNS over link-local and instead use IPv4 for the DNS request?

Is there ever a situation in which DNSmasq receives IPv6 request but uses IPv4 for lookup and responds with IPv6 answer (or does that make no sense?).

Simple the router's DNS server (DNSmasq) is configured as caching forwarder by default IIRC. So if DNSmasq has the entry in its cache it will deliver it immediately otherwise it will ask on behalf of the requesting internal endhost. I see no reason why DNSmasq should not use IPv4 to query the upstream DNS servers while responding to your endhost via IPv6 (since the endhost in our model asked via IPv6).

Yes I think this is exactly what happens in your case, as there is no IPv6 upstream to query via IPv6; the only question I have is whether your clients actually try via IPv6 at all. That should be open to inquiry via concurrent packet captures on your router's br-lan and wan interfaces while doing nslookup calls from the client.

1 Like