When my upstream Fritz!Box reconnects it receives a new IPv6 address and a new IPv6 prefix (IPv6-PD) from my ISP. The downstream OpenWrt router is apparently notified about this change as its WAN6 IPv6 address changes accordingly, however the delegated IPv6 prefix is not updated and global IPv6 addresses further downstream will not be updated either.
If the WAN6 interface is restarted, i.e. odhcp6c is restarted, the delegated Ipv6 prefix is properly updated.
I tried to dig a little further into this and monitored the call of the dhcpv6.script, and indeed whenever the Fritz!box reconnects I see calls of it with the 'ra-updated' parameter. However the PREFIXES environment variable remains unchanged.
I am no expert but to me it looks like either
the Fritz!box is not pushing changes of the prefix downstream (not shure whether any standard requires this), or
the OpenWrt box is not processing such information whereas at startup of odhcp6c the prefix information is somehow pulled.
Accordingly possible solutions to this problem that I could think of would be
Config change: I am simply missing some detail in either my Fritz!box or OpenWrt config. Any advice appreciated as I am new to OpenWrt.
Bug Fix: if the update information is pushed downstream but is somehow ignored by the OpenWrt box (I have no evidence for this), then this would likely be a bug in odhcp6c.
Workaround: If the update information is not passed on there are two workarounds that I could think of:
within odhcp6c to check whether IPv6 addresses change and re-initialize IPv6-PD (i.e., pull this information from the Fritz!box)
within the dhcpv6.script to check whether the IPv6 address has changed, deduce the new prefix from the new address and set the PREFIXES environment variable accordingly or simply restart (i.e. kill) odhcp6c.
The latter would be a feasible although dirty solution, which I could implement myself. Any advice appreciated.
A big thank you for your post, mate - did you and Doc time-travel to leapfrog my thread I was just going to create!!?
I am having the exact same issue with the exact same setup (OpenWrt as cascaded router behind a Fritz!Box connected to the ISP via DSL-PPPoE) and finally came to the same conclusion as you around christmas - when the problem really manifested as I was online whole days and once during the day keep-alive connections broke down (IPv6 only!) and couldn't be re-instantiated until ~ 15 mins later.
TLDR:Here's my very hacky fix / workaround for this:
Create the file /etc/hotplug.d/iface/90-ipv6routefix with following contents:
#!/bin/sh
# source /lib/functions/network.sh
FUCK_INTERFACE="wan6"
FUCK_ACTION="ifupdate"
if [ "$INTERFACE" = "$FUCK_INTERFACE" -a "$ACTION" = "$FUCK_ACTION" ]
then
ifup "$INTERFACE"
fi
P.S.: I am as shocked as you seeing my profanity there now -- I guess I wasn't amused spending 3 whole days tracking this $/§"$?& issue down. ^^
Too Long - Maybe Don't Read - Here's a bit of a preamble that shows my burdensome route and may or may not help deduction of the issue:
At first I had an older model of Fritz!Box instead of the OpenWRT router. (A second, cascaded one to the better and newer Fritz!Box connecting to the ISP, mind you)
There were no issues with IPv6-delegation down to the most downstream devices (*).
(* - take this with a grain of salt, though. As it is very hard to come across / detect issues at all in day-to-day life (c.f. below), it may very well be that I just didn't notice any issues back then!)
At around late August / early September lightning shot the second Fritz!Box dead, and I decided to get a TP-Link Archer C7 so I could get OpenWRT on it and play around with it - a thing long being on my mind.
It then worked as expected, however I sometimes got weird connection issues ("no route to host" or whatever) that affected IPv6 only and I couldn't nail down further - as everytime I started to investigate the issue, IPv6 was working again as though nothing had happened.
At that time, I forced my Mumble Client to use an IPv6-only domain to connect to the server.
Every few weekends, at some point during the day - after hours of continous connection - Mumble lost the connection and told me the server doesn't react to TCP pings anymore. I couldn't IPv6-ping the server address anymore, then, too.
Switching Mumble to IPv4 worked instantaneously. And the problem didn't occur at all when using IPv4-only in Mumble.
It was during the Christmas holidays with some consecutive days of starting Mumble in the morning and shutting it down at night, that I could pinpoint the culprit:
After ~9 hours usage the connection broke up for some time - always around the same time of the day.
I could verify that this was the exact time the upstream router got a new delegated prefix from my ISP.
When I restarted the WAN6 interface in LuCI at this moment the Mumble IPv6 connection was reestablished immediately.
You guys have to know, here in Germany, consumer-grade DSL lines have a "Zwangstrennung" (i.e. a deliberate disconnection by the ISP forcing new IPv4 and IPv6 addresses) once every 24 hours.
While the IPv4 connection can be used as-is for these 24 hours, the IPv6 connection gets a new prefix delegation every ~12 hours (at least by my ISP).
FWIW here's my current OpenWRT firmware version - I plan to upgrade to 19-stable "soon-ish":
After I implemented my hacky workaround above at around Christmas I was going to create a thread for this but was too lazy to write everything down - up until today.
Thanks again @McFly for getting the ball rolling and analyzing it even further (and more to the point )
P.S.: This is a very delicate issue because you may not even realize you are affected. Without using a IPv6-only domain for Mumble I would have seen a little hiccup in disconnection and immediate reconnection ONLY. (Second time via IPv4 of course)
Also Netflix, Youtube, Steam, Google, browsers and all kind of other apps and services are either buffering enough beforehand or straight off fall back to IPv4 directly - so you often will not even realize that your IPv6 connection is broken since an hour or so.
I looked a little bit further into this and I am still not sure what the root cause is, i.e.
whether the Fritz!box is simply not pushing changes of the prefix downstream, or
whether the OpenWrt box is not processing such information whereas at startup of odhcp6c the prefix information is somehow pulled.
However, I am pretty sure no communication between the boxes is filtered.
I also looked into the source code of odhcp6c, but couldn't spot any related issues. (Though I spotted some obvious memory leaks related to calls of realloc() and putenv(), which are presumably just accepted as changes in the environment shouldn't occur to often. Apart from some general reservation against memory leaks I don't think those really matter.).
In the meantime SergeantNukem's workaround turned out to be a viable option (thanks for posting that). Here is a slightly enhanced version of his hotplug script (as pulling down/bringing up the interface is only necessary when ip addresses are updated instead of at any 'ifupdate'. /etc/hotplug.d/iface/99-ipv6_fix_prefix_delegation:
__INTERFACE__="wan6"
__DEBUG__="FALSE"
if [ "$__DEBUG__" == "TRUE" ]
then
date >> /tmp/debug-hotplug-iface.log
env >> /tmp/debug-hotplug-iface.log
fi
if [ "$INTERFACE" = "$__INTERFACE__" -a "$IFUPDATE_ADDRESSES" = "1" ]
then
/usr/bin/logger -p user.notice -t \
hotplug "address change detected, resetting interface WAN6..."
/sbin/ifup WAN6 # ifup implies ifdown
fi
I have a bit of a tangential question - I'm trying to set up an OpenWrt router (RT) behind a FritzBox (FB).
FB has IPv4 and IPv6, with a /56 prefix. I've enabled options on FB to allow IPv6 prefixes from other routers, plus assign a prefix and IPv6 address to clients via DHCPv6.
RT receives an IPv6 address and prefix (/62) on lan, and can assign them to clients.
However, neither RT nor its clients can actually talk out via IPv6 (but the can internally).
I'm just wondering if you could provide me with your configs?
So while my workaround helps somewhat - as it allows an immediate re- connection via IPv6 - it is still broken obviously, as the connection should not be terminated in the first place.
As it stands now, the IPv6 connection is inferior to IPv4 - but IPv6 is supposed to make everything better, right?
From an engineering point of view - I am quite clueless right now what "the right thing to do" for OpenWRT would be?
Looking at my IPv6 addresses on direct clients I see that - after a new prefix delegation - they receive a new global IPv6 address. They still keep the old one - as valid, just not preferred anymore.
However, as the ISP pushes a new prefix, packets from those older addresses (with the "wrong" prefix) are exactly the ones that will not get routed outside anymore (no route to host).
But my Mumble client started the connection with the old address (containing the old prefix).
Is OpenWRT supposed to still accept packets from "old addresses" and internally mapping them to its new prefix so that the upstream router will send them out?
In fact the ISP could have delegated the old prefix to another customer meanwhile...
--> What is the right thing to do for OpenWRT (regarding IPv6 RFC and sysadmin best practices) for this to work correctly??
The OpenWRT configuration was quite a hassle - particulary because I don't understand what the Use builtin IPv6-management flag does -- at the WAN4 interface for example it doesn't make any sense at all (or am I wrong?)...
Since the upgrade to 19.xx (see above) they moved this flag to somewhere else. One weekend I played around with it and disabled it as often as possible - IIRC it didn't make any difference.
I cannot check my config right now unfortunately, but IIRC you disable DHCPv6-Service and NDP-Proxy and switch the Router Advertisement-Service to "server mode". This way all clients will derive their own address from the advertised prefix (via SLAAC) and use that.
My setup is even more complex as I use a Raspberry Pi with PiHole as DNS blackhole:
It will serve IPv4 via DHCPv4 (i.e. DHCPv4 at OpenWRT disabled)
OpenWRT: Set the IPv4 DNS to the pi-hole
OpenWRT: Set the IPv6 DNS to the pi-hole
OpenWRT: You need to enable the 'O' flag in RA so clients will get the DNS server via (stateless) DHCPv6 from the pi-hole (you have to enable IPv6 / SLAAC support in pi-hole for this)
OpenWRT: But disable the 'M' flag in RA so clients will use SLAAC (see above)
Hello kind sirs! This issue also troubles me, for years now.
IMHO, the best solution is indeed to decouple ISP prefix from LAN addresses. LAN addresses should have an internal prefix, which should be remapped to ISP prefix when some package goes out.
Yeah, that's very much what IPv4 NAPT and IPv6 NPTv6 do. Before somebody yells at me, let me make clear that I'm not talking about security, I'm talking about decoupling LAN from ISP!
And yeah, we have ULA for LAN addresses. The problem is that if router doesn't provide GUA and only use ULA, with a standard ULA prefix, OSs are programmed to understand that no Internet IPv6 is available, and will use IPv4 always when possible. Devices require GUA so that IPv6 is priorized.
This all gets even worse when we're talking about multi-homing, because if devices receive GUAs with multiple prefixes it will fall on them to choose which WAN to use, not on the router, which breaks load balancing and failover.
I believe the best solution is to use NPTv6 with proper support for detecting and delegating dynamically changing prefix and remap addresses, I just don't know what prefix would be used on it.
)
