Flint 2 - GL-MT6000 ipv6 problem native

Routers
1

:wrench: IPv6 Native vs NAT6 Issue on GL.iNet (STACK 4.8.4 / odhcpd)

:pushpin: Scenario

  • Router: GL.iNet (OpenWrt-based)

  • Connection: PPPoE

  • IPv6 fully enabled:

    • WAN IPv6 :check_mark:

    • Prefix delegation :check_mark: (/48 → /60 on LAN)

ipv6-prefix: 2a07:7e81:4829::/48  
assigned LAN: /60

:red_exclamation_mark: Problem

:red_circle: In Native IPv6 mode

  • LAN clients:

    • sometimes receive IPv6

    • but lose connectivity intermittently

  • Logs previously showed:

odhcpd: A default route is present but there is no public prefix on br-lan thus we don't announce a default route

:backhand_index_pointing_right: This means:

odhcpd does NOT advertise a default IPv6 route to clients (GitHub)

:green_circle: In NAT6 mode

  • Everything works perfectly:

    • stable IPv6 connectivity

    • no drops

    • no routing issues

:brain: Technical Explanation

:check_mark: How Native IPv6 works (OpenWrt)

OpenWrt uses:

  • odhcp6c → WAN DHCPv6 client

  • odhcpd → LAN DHCPv6 + Router Advertisement (RA) daemon (OneUptime)

:backhand_index_pointing_right: Clients rely on RA (Router Advertisement) to:

  • learn the default gateway

  • build routing

:cross_mark: What goes wrong

When this appears:

no public prefix on lan

:backhand_index_pointing_right: odhcpd behavior:

  • sees a default route :check_mark:

  • but does NOT detect a valid LAN prefix :cross_mark:

  • therefore:

:bomb: it stops advertising the default route

:backhand_index_pointing_right: Result:

  • clients may still have IPv6 addresses :check_mark:

  • but no valid route :cross_mark:

:bomb: → IPv6 connectivity breaks intermittently

:pushpin: Confirmed behavior

This issue is known in OpenWrt:

without a valid prefix, odhcpd will not announce a default route (Forum OpenWrt)

:fire: Why NAT6 works

:green_circle: NAT6 behavior

  • No RA required

  • No prefix delegation needed on LAN

  • Router handles all routing internally

:backhand_index_pointing_right: therefore:

  • clients don’t depend on odhcpd

  • no RA issues

  • no prefix validation needed

:bomb: In short:

NAT6 bypasses odhcpd completely

:warning: Key Observation

  • ISP → working correctly :check_mark:

  • Prefix delegation → working :check_mark:

  • WAN IPv6 → working :check_mark:

:backhand_index_pointing_right: So the issue is NOT ISP-related

:backhand_index_pointing_right: Real problem:

:bomb: Router Advertisement (odhcpd) inconsistency on LAN

:test_tube: Debug performed

  • ifstatus wan6 → valid prefix :check_mark:

  • ubus call dhcp ipv6leases → leases present :check_mark:

  • curl -6 → IPv6 working :check_mark:

:backhand_index_pointing_right: Core IPv6 stack is fine
:backhand_index_pointing_right: Distribution to LAN is unstable

:red_question_mark: Question

Why, despite:

  • valid prefix delegation :check_mark:

  • odhcpd running :check_mark:

:backhand_index_pointing_right: do LAN clients not consistently receive RA / default route?

Possible causes

  • odhcpd bug (RA / prefix handling)

  • timing issue with prefix delegation

  • LAN configuration (ra / dhcpv6 / ra_management)

  • PPPoE + IPv6 interaction

:bullseye: Goal

:backhand_index_pointing_right: Achieve stable native IPv6 (without NAT6)

:bomb: Final Summary

:backhand_index_pointing_right: NAT6 works because it bypasses RA
:backhand_index_pointing_right: Native fails because odhcpd does not reliably advertise the IPv6 default route

2

That’s odd… I had native IPv6 enabled on 4.8.3 (currently I'm using vanilla openwrt) and worked at first try with my ISP /48 PD and native IPv6 option. With openwrt I adjusted lan to take /64 subnet (some problems with my server that was assigned with different ipv6 address), but even with /60 subnet I don’t have major issues. Could be a bug in 4.8.4? Had you tried on 4.8.3?

3

Yes, look, it's a problem I've been having for a while. I thought this version would fix it, but it didn't, so I wanted to let everyone know. Keep in mind that the service has been restarted. The network resumed routing.

4

Hi

Could you please follow the guide and share your device with us via GoodCloud after the problem happens again so we can check it remotely?

Kindly note to send us the MAC address and the router password via private message so we can access it

image
image632×233 19.1 KB

6

I RESOLVE DEFINITIVE!!! DISABLE HARDWARE ACCELLERATION … but why? there is future fix?? thanks to staff to connect to my device

7

is 100% ONLY THIS PROBLEM –> hardware accelleration .. with your staff with my ipv6 native is ok icmpv6, mss, etc etc this only problem… please focus on this fix on future release…

9

Thank you for the update.

Please continue to contact our engineers through the ticket system via email, and we will follow up on the issue.