How to Get Public IPv6 on Your Home Network

│ IPv6 Troubleshooting and Configuration Summary for OpenWrt as a Secondary Router

Background

Based on the author’s hands-on experience.
For reference.
Applicable to iStoreOS and OpenWrt.
Version: 24.10

1. Problem Overview

Initial State

• Network topology: Telecom ONT (PPPoE primary router) → iStoreOS/OpenWrt (secondary router) → End devices (PC/phone).
• Core issue: End devices behind iStoreOS/OpenWrt could not get IPv6 internet connectivity, while devices connected directly to the ONT or through another ordinary secondary router worked fine.
• Key constraint: Unable to modify any settings on the Telecom ONT. (The ISP won’t allow it, and changes may be remotely reverted…)

Root Cause Analysis

In a network where the ONT handles PPPoE and has IPv6 enabled, the ONT itself serves as the IPv6 Router Advertisement (RA) and DHCPv6 server. As a secondary router, iStoreOS/OpenWrt should act as a “transparent relay”, forwarding IPv6 information from the ONT to LAN devices as-is, rather than acting as a server itself. The default iStoreOS/OpenWrt configuration (LAN interface in “server mode”) attempts to assign IPv6 on its own, conflicting with the upstream and preventing end devices from obtaining valid public IPv6 addresses or routes.

2. Troubleshooting and Resolution Process

The troubleshooting followed a logical progression from basics to deep-dive, from configuration to services. The diagram below illustrates the core diagnostic path and resolution steps:

flowchart TD
    A[Problem: No IPv6 through OpenWrt<br>but direct ONT connection works] --> B{Check OpenWrt WAN interface status}
    
    B --> C{Does WAN have a<br>public IPv6 address?<br>(starting with 240e:/2408:)}
    C -- Yes --> D[Core issue: LAN interface mode misconfigured]
    C -- No --> E[Check physical connection & ONT IPv6 service]
    
    D --> F[Key fix: Modify LAN DHCPv6 settings]
    F --> G[Change mode from "Server" to "Relay/Hybrid"]
    G --> H[And enable "Always announce default router"]
    
    H --> I{Do end devices get<br>public IPv6 addresses?}
    I -- No --> J[Deep troubleshooting]
    I -- Yes --> K{IPv6 connectivity test<br>(e.g. test-ipv6.com)}
    
    subgraph J [Deep troubleshooting steps]
        J1[Check and clear ULA prefix]
        J2[Confirm IPv6 DNS filtering is disabled]
        J3[Check firewall rules<br>(disable WAN IP masquerading)]
        J4[Restart odhcpd service<br>flush stale addresses]
    end
    
    J --> I
    K -- Fail --> L[Run end-to-end ping tests<br>to locate the break point]
    L --> M[Adjust firewall or MTU<br>based on test results]
    K -- Pass --> N[🎉 Problem solved]

    style A stroke:#f66,stroke-width:2px
    style N stroke:#0a0,stroke-width:2px

Key Operations and Commands at Each Stage

1. Information Gathering

• Check iStoreOS/OpenWrt WAN interface: Confirm it has obtained a Telecom public IPv6 address (240e:3a3:…) via DHCPv6, proving the upstream signal is working. As shown below:

• Check iStoreOS/OpenWrt LAN interface configuration: Found that both Router Advertisement and DHCPv6 Service were set to “Server mode” — this was the root cause. As shown below:

• Check other settings: Found that IPv6 ULA Prefix was not cleared, and Filter IPv6 AAAA records was checked — both interfere with normal operation.

2. Core Configuration Fix

• Set LAN DHCPv6 to relay: Change Router Advertisement Service and DHCPv6 Service to “Relay mode” or “Hybrid mode”. After the fix:

  

• Clear ULA prefix: In Global Network Options, delete the auto-generated ULA prefix (fdd5:…) to prevent it from interfering with public address assignment.

  

• Allow IPv6 DNS resolution: In DHCP/DNS advanced settings, uncheck “Filter IPv6 AAAA records”.

  

• Adjust firewall: In Firewall settings, ensure IP Masquerading (NAT) is unchecked for the wan zone to reduce potential interference with IPv6 traffic.

  

3. Service Application and Debugging

• Run the following commands via SSH or TTYD terminal to restart the IPv6 service and flush stale addresses:

  /etc/init.d/odhcpd restart
  ip -6 addr flush dev br-lan scope global

• Discovering the missing piece: Although end devices obtained public IPv6 addresses (240e:…), ipconfig /all showed no IPv6 default gateway. This directly prevented packets from being routed out. At this point my PC showed:

      Connection-specific DNS Suffix  . : lan
      IPv6 Address. . . . . . . . . . . : 240e:3a3:xxxx
      IPv6 Address. . . . . . . . . . . : fdd5:3075:xxx
      Temporary IPv6 Address. . . . . . : 240e:3a3:xxx
      Temporary IPv6 Address. . . . . . : fdd5:3075:xxx
      Link-local IPv6 Address . . . . . : fe80::1ba8:xxx
      IPv4 Address. . . . . . . . . . . : 192.168.3.246
      Subnet Mask . . . . . . . . . . . : 255.255.255.0
      Default Gateway . . . . . . . . . : 192.168.3.1 (missing **IPv6 default gateway**)
   
  
  test-ipv6.com results:
  
  
   Your public IPv4 address is x.x.x.x
   
   
   Your ISP is CHINANET-BACKBONE xxxx
   
   
   No IPv6 address detected [more info]
   
   
   You are connected via IPv4 only and cannot access IPv6-only sites.
   
   
   Contact your ISP for information on how to enable IPv6 for optimal network performance. [more info]
   
   
   Your DNS server (possibly provided by your ISP) is already connected to the IPv6 internet

4. Final Resolution

• Go back to iStoreOS/OpenWrt LAN DHCPv6 settings and enable “Always announce default router”. As shown below:

  

• After saving and applying, end devices immediately received the correct IPv6 default gateway (fe80::…), and IPv6 internet connectivity was fully restored. As shown below:

      DHCPv6 IAID . . . . . . . . . . . : 10483xxxxx
      DHCPv6 Client DUID  . . . . . . . : 00-01-00-01-26-xxxxx
      DNS Servers . . . . . . . . . . . : 192.168.3.1
                                          fe80::xxxxxx%28
                                          240e:3a3:xxxxx
                                          fdd5:xxxxxx
   
  
  test-ipv6.com results:
  
  
   Your public IPv4 address is xxxxx
   
   
   Your public IPv6 address is 240e:3a3:xxxxx
   
   
   Your ISP is CHINANET-BACKBONE xxxx
   
   
   You are connected via IPv6, so we have added a tab showing whether you can reach other IPv6 sites. [more info]
   
   
   Your DNS server (possibly provided by your ISP) is already connected to the IPv6 internet.
   IPv6 readiness score
   10/10 This score indicates how well your system supports and handles IPv6
   Click to view test data

3. Final Working Configuration Checklist (iStoreOS/OpenWrt LuCI Interface)

Configuration Location	Setting to Modify	Recommended Value	Purpose
Network -> Interfaces -> LAN -> DHCP Server -> IPv6 Settings	Router Advertisement Service	Relay mode or Hybrid mode	Forward RA messages from the ONT instead of broadcasting its own.
	DHCPv6 Service	Relay mode or Hybrid mode	Forward DHCPv6 address assignment from the ONT.
	NDP Proxy	Disabled	Usually unnecessary in a simple relay setup.
	Always announce default router	Checked	Critical! Ensures end devices receive an IPv6 gateway.
Network -> Interfaces -> Global Network Options	IPv6 ULA Prefix	Clear	Avoid generating local addresses; prioritize public addresses.
Network -> DHCP/DNS -> Advanced Settings	Filter IPv6 AAAA records	Unchecked	Allow the DNS server to return IPv6 addresses.
Network -> Firewall -> Zones (WAN)	IP Masquerading (NAT)	Unchecked	IPv6 typically doesn’t need NAT; avoid unnecessary translation.

4. Core Principles Summary

1. Relay vs Server: In a topology where you cannot control the primary router (ONT), the secondary router’s IPv6 must use “Relay” mode. It acts as a bridge — only passing information through, not making decisions on its own.
2. Address assignment priority: The system prioritizes public IPv6 addresses (GUA). Only when relay fails and no public prefix is received will devices fall back to ULA local addresses (starting with fd or fdd). The fdd5: addresses seen initially were a clear sign of relay failure.
3. The importance of Router Advertisement: IPv6 depends not only on addresses but also on routing. The “Always announce default router” option ensures the router tells LAN devices: “I am your gateway to the IPv6 internet.” Without this, devices have addresses but cannot reach the internet.
4. Firewall differences: IPv6 is designed to favor end-to-end direct communication, so its firewall policies differ significantly from IPv4 (which commonly uses NAT). IP masquerading (NAT) is generally unnecessary and not recommended for IPv6.

5. Lessons Learned and Recommendations

1. Troubleshooting order: Follow the principle of “WAN first, then LAN; address first, then routing”. First confirm the upstream signal is present (WAN has a public IP), then troubleshoot internal forwarding (LAN relay configuration), and finally check routing and firewall.
2. Configuration backup: In iStoreOS/OpenWrt, once the configuration is working, immediately create a backup via “System” -> “Backup/Flash Firmware”. This allows quick recovery after future upgrades or resets.
3. Testing tools: Use the following tools for precise diagnosis:
   • ipconfig /all or ifconfig: Check local addresses and gateway.
   • ping -6 : Test IPv6 connectivity.
   • test-ipv6.com: Comprehensive one-stop test.
4. Potential optimization: Once the network is stable, consider changing Router Advertisement Service and DHCPv6 Service in the LAN IPv6 settings from Hybrid mode back to pure Relay mode to reduce iStoreOS/OpenWrt’s involvement, which theoretically provides better stability.

Through the steps above, the author successfully configured iStoreOS/OpenWrt as a proper IPv6 relay node in a restricted network environment, enabling all LAN devices to seamlessly access the IPv6 internet. This approach is broadly applicable to any scenario where iStoreOS/OpenWrt serves as a secondary router behind any brand of ONT (in bridge or router mode).