Beryl AX with firmware 4.4.5 still has this issue.
IPv6: When you enable it, the router assigns a ULA prefix but it has an issue instead of being in the ULA range fd00::/8 it assigns an address like: dd15::/48 it shouldn’t start with d. Due to this bug, IPv6 its pretty useless unless you use a native address. (This was temporary solved editing /etc/init.d/gl_ipv6). This happens when using Mode NAT6. (Solution was here: Strange ULA prefix in stock Beryl)
This solution no longer applies with firmware 4.x
@alzhao You commented in Feb. 2022 that this bug was gonna be fixed with firmware 4.x but it still happens
That is a possible solution for the private Network, but the guest network is still using the randomly, and incorrectly generated Address range.
After setting the Mode to Static IPv6, it does not use the new IPv6-PD (with or without reboot) and even when manually setting that new Adress Range in the advanced configuration menu (LuCI; adjusting the necessary settings like Prefix, DHCP, etc.) it only works until the next reboot, then it is changed back by an init script.
I do not want to have to fight my routers setup files to get an RFC-4193 compliant networking setup.
Please provide an option to toggle this replacement behaviour on and off.
I realize there are benefits to using “ddxx::” (like the traffic prioritization) but there are also potential future drawbacks. Standards exist for a reason.
Possible Solutions:
Option in the WebUI to enable/disable the Feature (maybe call it “Client IPv6 Prioritization” in the IPv6 section and add a small help text?). Let it default to on, and just set a variable that’s read by the init script and included in the check before replacing the “fdxx::” with “ddxx::” while it’s setting the IPv6-PD and Address Ranges
Only do the replacement in the standard NAT6 mode, but use the specified IPv6-PD (the fdxx:x:x:: /48) if the mode is set to “Static IPv6” (if i wanted to i could also always specify a “ddxx::” address range in the manual mode)
I would prefer the first option, as it is more expressive of what’s actually going on and the reasons for and against enabeling this “special treatment”
@lizh
I have already looked at the init scripts and found a few places relevant to this replacement and there are already checks for the current mode and other system variables in place. This should not be a huge issue, but rather a relatively simple fix to an annoyance that has come up multiple times before
