Hello,
I’ve got a GL-2200 router recently and tried to setup PPPoE with IPV6 enabled. The version of firmware is 3.212, OpenWrt Chaos Calmer 15.05.1 e7067e3+r49254 / LuCI Master (git-20.356.08465-e96d522).
Note: my provider is ASAHI NET (NTT), so in order to utilise IPv6 address, I had to relay it into the LAN to use.
So, PPPoE does connect, but as for IPv6 - no luck. I’ve decided to look in OpenWRT configs and found out that some scripts from GL (I still can’t find one) are trying to assign an ifname for a WAN6 interface with '@wan" name, and it didn’t work, obviously.
I had to change it for physical eth0. The next thing is, those unknown init scripts are also overwriting DHCP configs for WAN6, using a wan interface for reference (why?):
Changed this to a real interface (wan6) that needs those precious prefixes and it started to work.
Questions:
Why @wan interface reference doesn’t work in the first place?
I’m not sure if it’s intended, but current stock firmware just doesn’t work with IPv6, if you are using PPPoE connection. I wonder if there are a way to determine which script is overwriting /etc/config/network and /etc/config/dhcp (section config interface wan6 and config dhcp wan6 specifically). Because for now I’ve created a separate interface and DHCP configuration in order to prevent it from being replaced. ← see answer below
odhcpd service is not applying my DHCP changes after boot, I had to manually restart it to get my IPv6 address relayed into LAN. Is it possible to autorestart DHCP after all init scripts or there is another way to do it?
Edit: I think I’v found a cause of override to wan: /etc/init.d/gl_ipv6:
set_wan()
{
local interface=`uci get glipv6.wan.interface 2>/dev/null`
if [ -n "$interface" ];then
uci set network.wan6.ifname="@$interface"
else
uci set network.wan6.ifname="@wan"
fi
^^ This conditional will always append @wan for wan6 interface (correct one is eth0).
set_lan_relay()
{
uci set dhcp.wan6.interface="$(uci get glipv6.wan.interface)"
...
^^ and here wan interface name will be a reference for dhcpv6 on dhcp wan6 (correct one is wan6).
Today, I ran into the same issue. Via the Web interface of my GL.iNet, I reverted to factory defaults, the mode is Router, changed the Internet to PPPoE, and enabled IPv6. I checked with Wireshark – both – the WAN and the LAN interface. I checked via LuCI.
GL.iNet → Web → LAN defaults to ‘native’ mode. However in OpenWrt, that does not set the default mode ‘server’ but ‘relay’. In Wireshark, on the LAN side, I see the IPv6 Router Advertisements state not Router but Proxy. In Wireshark, on the WAN side, I see relay-forwarded DHCPv6 messages of my LAN clients. This does not work with PPPoE services. At least those here in my country.
After changing the LAN mode to ‘NAT6’, in the GL.iNet Web interface, IPv6 connectivity works because everything is changed to ‘server’ in OpenWrt land. However, because it activates NAT6 as well, I see those silly ULA prefix + DNS server again.
Could the GL.iNet team check what is up? I use the latest snapshot for a AR300M16. The default LAN mode for a PPPoE in WAN should use ‘server’ in OpenWrt land. Or stated differently, with the current approach, IPv6 over PPPoE is broken.
Not sure, I understand. I answered some other threads, linked some because they are (or might be) duplicate. The thread starter has to double-check. Furthermore, I am not sure if DHCP/DHCPv6 and PPPoE/DHCPv6 get the same ‘native’ IPv6 mode.
Anyway, back to topic:
Is it known, that in PPPoE the IPv6 mode ‘native’ is actually proxy/relay/passthrough?
Is the mode ‘router’ coming to the GL.iNet Web interface or available in firmware 4.x already?
Your answer sounds like there is another bigger thread about this which I missed but is more up-to-date.
You were (un)lucky. In OpenWrt, ‘relay’ means that the requests are proxied to the upstream Internet Service Provider (ISP). I see that via a managed switch with port mirroring enabled, attached to the WAN port of my GL.iNet. Consequently, what you get, depends on your ISP, if you use mode ‘relay’.
Furthermore, it requires the ISP to provide IPv6 addresses via DHCPv6 (wrapped into PPPoE, if PPPoE was selected). This is not supported in general, actually the exception. Here in Germany, my two DSL ISPs do not offer IPv6 addresses (IA_NA) via DHCPv6. In Wireshark, this DHCPv6 option 3 is called ‘Identity Association for Non-temporary Address’.
With PPPoE, the trick is different:
The ISP sends a configuration request for IPv6 on the PPP layer (0x8057). My GL.iNet does not negate but acknowledges that, when I enable IPv6 in the Web interface of that GL.iNet. Then, the ISP sends a IPv6 Router Advertisements (IPv6 RA). GL.iNet has to extract the flags of that message. In my case, my GL.iNet would have to form its own IPv6 address via the IPv6 RA. And then, GL.iNet has to send a DHCPv6 message to get a prefix. In Wireshark, this is called ‘Identity Association for Prefix Delegation’. Then, GL.iNet (not the ISP) is handing out part of that very large prefix to IPv6 LAN clients.
All this works magically, when the default mode ‘server’ is set in OpenWrt. I have tested routers from 13 commercial vendors by now (all non-OpenWrt based). ‘server’ = router is the default behavior of all of them.
In contrast to that, with ‘relay’, GL.iNet went for the mode ‘pass-through’. Which is nice because I am sure it is useful for some ISPs out there (I do not know one @dxf, which ISP is that?). However, with ‘pass-through’, the GL.iNet is not a router on the IPv6 level. And it does not work with my two ISPs at all.
Does not work. I tested this, already, before I reported it back last year. Re-tested it just now, and still does not work. Furthermore, I did a code analysis, again. This hybrid mode is tied to ‘master=1’. However, I do not understand which and whether an interface could be master. Furthermore, I am not aware of any (other) IPv6 router which is able to detect IPv6 Pass-through mode and differ that from IPv6 Router mode automatically. Anyway, I recommend to ask the OpenWrt community (and/or the author of the software module odhcpd) to get a definitive conclusion.
By the way, the OpenWrt default of ra_management = 1 is not good either. Here in Germany, with dynamic IPv6 prefixes, you cannot have a stateful DHCPv6 server. Again, that should be the exception not the default. I had to go for ‘ra_management = 0’, which disables the M(anaged) flag in the Router Advertisements.
Please try this configuration, my local pppoe works fine
--- a/etc/init.d/gl_ipv6
+++ b/etc/init.d/gl_ipv6
@@ -166,16 +166,17 @@ set_lan_relay()
- uci set network.lan.ip6assign="64"
+ uci set network.lan.ip6assign="60"
uci set network.lan.ip6hint="0000"
uci set network.lan.ip6ifaceid="::1"
+ uci add_list network.lan.ip6class="wan6"
+ uci add_list network.lan.ip6class="local"
uci commit network
- uci set dhcp.lan.dhcpv6="relay"
+ uci set dhcp.lan.dhcpv6="server"
uci set dhcp.lan.ra="relay"
uci set dhcp.lan.ndp="relay"
uci delete dhcp.lan.dns 2>/dev/null
uci set dhcp.wan6="dhcp"
uci set dhcp.wan6.interface="$(uci get glipv6.wan.interface)"
- uci set dhcp.wan6.dhcpv6="relay"
uci set dhcp.wan6.ra="relay"
uci set dhcp.wan6.ndp="relay"
uci set dhcp.wan6.master="1"
I patched that script in set_lan_relay() the same way as you did, but as values I use:
uci set dhcp.lan.dhcpv6="server"
uci set dhcp.lan.ra="server"
uci set dhcp.lan.ra_management="0"
uci set dhcp.lan.ndp="disabled"
I am not sure about (better: have not double-checked) the consequences of the first option, the one about DHCPv6: uci set dhcp.lan.dhcpv6="disabled"? With above commands, the flag O(ther) is set in the Router Advertisements (IPv6 RAs). That means, LAN clients have to ask the DHCPv6 server for DNS but not an IPv6 address (IA_NA). That works. However, IPv6 clients exist which ignore IPv6 RAs and always ask DHCPv6 server for their IA_NA. Such clients can be considered broken – given them no IPv6 is better than creating chaos later, when the prefix changes. This is the way most of my other IPv6 routers are configured (on default). The DHCPv6 server is not stateful even if asked. I am not sure if that direct asking is blocked because of one of the other options or works and the DHCPv6 server still hands out IA_NA.
Same with IPv6 Prefix Delegation (DHCPv6-PD) in the LAN. I do not know if that works with the above. Furthermore, does that get blocked when I go for uci set dhcp.lan.dhcpv6="disabled"? The AVM FRITZ!Box, for example, allows DHCPv6-PD to be enabled optionally, without enabling the DHCPv6 server to hand out IA_NAs.
Consequently, there is still some double-checking and testing involved, especially because with OpenWrt 21.02 you have two branches now. I am still on OpenWrt 19.07. Although I love to help, it is not my job, to do all your testing. Again, this is something to chat with the OpenWrt community, I guess. I am not even sure the defaults on the Wiki match the defaults in code. Beside not being sure if they use good defaults.
Does not work, cannot access IPv6-only pages from an attached LAN client. Chaos on WAN side (hop limits). What exactly are you about to achieve? Please, tell me your ISP and country. I look-up if that really need IPv6 Pass-through. Nevertheless, you cannot have one configuration which catches all ISP on this world.
Found not much information how China Telecom is doing IPv6. I do not think a provider is going for IPv6 Pass-through at large scale. Either something is broken in your region or they use something else. Do you have a reference router, a router offered/supplied by your ISP in-between? If yes, that would explain it. However, if you replaced your router with your GL.iNet router, change it back double-check with the old router without GL.iNet around, how that does IPv6.
Found some spare time doing those tests. And, yes it does. Consequently, if the LAN client ignores the flags in IPv6 RAs but the IPv6 prefix is not static but dynamic, that LAN client receives an IPv6 which is not valid anymore when the prefix changes. If that LAN client does not support DHCPv6 re-configure, it is lost until the lease times out. Another flag was introduced to control that which is included in OpenWrt 19.07. Consequently, my proposal for the new default IPv6 LAN mode Native is:
uci set dhcp.lan.dhcpv6="server"
uci set dhcp.lan.dhcpv6_na="0"
uci set dhcp.lan.ra="server"
uci set dhcp.lan.ra_management="0"
uci set dhcp.lan.ndp="disabled"
That works for all clients honoring IPv6 RAs, whether it is a static or dynamic IPv6 prefix. By the way, several of my IPv6 routers like other OpenWrt based router or like the AVM FRITZ!Box offer more modes (like Stateful DHCPv6 and SLAAC-only) and/or allow more fine grained control over all those flags (like set the DNSv6 server, no RDNSS in RA, no SLAAC, or even no RA at all). I recommend to look at that and how they solved it. In the meantime, one can go for UCI and change the file /etc/init.d/gl_ipv6 and there set_lan_relay() himself.
Finally, DHCPv6-PD does not work out of the box, even not with .dhcpv6="server". Not sure what is broken there.
Did some long term traces over the weekend. LAN looks good now. My ISP tears down the PPPoE session every 24 hours (via PPP-LCP Termination Request 5 and then via a PPPoE Active Discovery Terminate PADT). And my ISP hands out IPv6 prefixes not statically but dynamically. That works on the LAN side just perfect. The previous IPv6 prefix gets invalidated – not exactly as described in RFC 9096 – but my macOS and Ubuntu computers mark the old prefix a deprecated. Great.
However, the WAN side is still a mess. And I do not find the culprit. My GL-iNet router is sending a ICMPv6 Router Solicitation nearly every hour, not within PPPoE. And indeed, I set-up another router in-front with PPPoE pass-through enabled, and the GL.iNet assigns an IPv6 address to its eth0. I can even ping and the GL.iNet from that net = outside. I can even access it (SSH, Web, …). That must be fixed before going live with that new native mode.
Furthermore, the mentioned tear down – on the WAN side – does not work really. It is more luck or better a-try-on-the-second-run that my GL.iNet copes with that tear down and gets a new IPv6 prefix. In any case, my GL.iNet looses a lot of time – is disconnected much more than needed – because it does not cope with that tear-down situation correctly. That should be re-visited when field testing with various Internet Service Providers (ISP). As ISP, I am using 1&1 in Germany. Should be the same for Telekom Deutschland – however, they tear down not after 1 but 180 days. A bit difficult to test right now.
