Start your 3-day free trial
Sign up to experience all premium features at no cost.
*Available only to new users. Each user is limited to one trial.
OpenWrt IPv6 Prefix Delegation: Network and Firewall Checks
Ryan Foster
October 11, 2026· 11 min read
OpenWrt IPv6 prefix delegation distributes an ISP-provided address block to downstream networks; it is different from obtaining one WAN address. Verify the delegated block, LAN advertisements, client routes and firewall direction separately, especially after the ISP changes your prefix.
Key Takeaways
- A WAN address is not evidence of an available delegated prefix.
- RA supplies router information; DHCPv6 does not replace the default-router advertisement.
- Router input rules and LAN forwarding rules protect different destinations.
- Preserve necessary ICMPv6 instead of disabling it to troubleshoot.
- Restoring configuration cannot force an ISP to reissue the previous prefix.
What does OpenWrt IPv6 prefix delegation require?
This procedure covers OpenWrt 25.12 stable with fw4/nftables, an ISP that supports DHCPv6 prefix delegation and one controlled downstream LAN. It follows official documents and standards; no complete end-to-end router test was performed. Verification tables describe expected behavior and failure responses, not author measurements.［1］
Use the network ownership and recovery checklist before changing a shared router. If OpenWrt is only a same-subnet secondary gateway, do not start another RA server on that LAN to imitate a routed downstream network. Identify which router actually receives the ISP delegation.
Review IPv4 and IPv6 addressing differences if you are treating an IPv6 address like an IPv4 port mapping. Public-address distribution and access to a private service are separate tasks; the home-gateway and internet-exit comparison explains that choice. This procedure does not create a remote-access service.
Step 1: Save the baseline and identify WAN, PD and LAN
Use wired management with working IPv4 access that does not depend on the IPv6 settings you will change. Open a fresh session and confirm a local recovery procedure. Save network, DHCP and firewall configuration privately off the router, including any service records or dynamic DNS settings that contain addresses.
In Network → Interfaces, identify the actual upstream IPv6 logical interface. It may be wan6; PPP setups can create wan_6 automatically. Inspect existing interfaces before adding another DHCPv6 client. Record the delegated prefix, its length and lifetimes, the assigned downstream prefix and the client addresses separately.［2］
| Object | What to inspect | What it does not prove |
|---|---|---|
| WAN address | Upstream interface address and route | That the ISP delegated space for LAN |
| Delegated prefix | IPv6-PD block and lifetimes | That LAN advertisements or firewall policy are correct |
| LAN assignment | A subnet taken from that block | That every client has a usable default route |
| Client address | Global, local and link-local addresses | That an external host can reach a service |
| Default route | Actual next hop and interface | That DNS and return traffic work |
If the ISP supplies no PD, stop this path and ask for its supported downstream configuration. Do not copy an unrelated static prefix or silently switch to NDP proxying, relay mode or NAT66. Those are different designs with separate assumptions. Documentation addresses such as 2001:db8::/32 are placeholders and must never be configured as real ISP assignments.
Step 2: Request OpenWrt DHCPv6 PD and assign one LAN subnet
On the existing upstream DHCPv6 interface, review Request IPv6-prefix of length and normally start with auto unless your ISP documents another choice. The UCI option is reqprefix; it requests a prefix and does not compel the ISP to provide a chosen size. Keep upstream prefix delegation enabled for downstream assignment.［2］
On the controlled LAN interface, set IPv6 assignment length to 64 (ip6assign: 64) for this single ordinary client subnet. A delegated /56 or /60 offers space for several /64 LANs; a single delegated /64 does not provide another independent /64 for every VLAN. Do not “fix” exhaustion by overlapping LAN assignments.
Use ip6hint only when you need a preferred subprefix identifier within available space, and ip6class only when deliberately selecting a prefix source. These controls cannot create an absent ISP delegation. Inspect the resulting allocation instead of assuming your requested hint was honored.［2］
Apply one change through LuCI and reread interface status. Do not repeatedly restart WAN hoping to recover a preferred prefix. If the upstream does not supply PD or the selected LAN receives no assignment, stop at that layer before modifying application or inbound firewall rules.
Step 3: Check advertisements, addresses and client routes
For this routed downstream LAN, review its RA-Service and DHCPv6-Service under DHCP server IPv6 settings. Use server roles appropriate to the existing client design; do not enable relay or NDP proxy modes merely because a forum example uses them. Keep these advertisements off the upstream interface.［2］［3］
RA conveys default-router information and can support SLAAC addressing. DHCPv6 can supply other configuration and, for supported clients, addresses; receiving DHCPv6 information alone does not establish a default IPv6 router. A client can legitimately have multiple global addresses, temporary privacy addresses and a link-local address. Classify them before deciding which source is used for a request.［4］
On OpenWrt, substitute the actual upstream interface for wan6. These are inspection commands, not sample output and not proof that your ISP supplies any particular prefix. Do not publish your home addresses or complete diagnostic exports without reviewing their privacy implications.［3］
ifstatus wan6
ifstatus lan
ip -6 address show
ip -6 route show
ip -6 rule show
On a Linux test client, inspect ip -6 address show and ip -6 route show; other systems provide equivalent address and route views. Check that a fresh client request uses a current global source and the intended router. Test client-to-router reachability, then router-to-upstream and client-to-upstream independently. Router success does not prove LAN forwarding.
How should the OpenWrt IPv6 firewall handle inbound traffic?
Protect the router with input rules and downstream hosts with forwarding rules. In fw4 configuration, a rule naming a destination zone concerns forwarding; without that zone, it normally targets the router. Review the actual generated rules and zone membership rather than assuming that an address match means the right direction.［5］
Keep WAN administration denied by default. Do not add a WAN input ACCEPT rule for LuCI or SSH, and do not permit all WAN-to-LAN forwarding to make a service reachable. Preserve the necessary DHCPv6 client traffic and ICMPv6 functions. ICMPv6 supports neighbor discovery and path-MTU/error signaling; indiscriminate blocking can break otherwise valid connections.［2］［4］［6］
If you intentionally publish a private service, first follow the restricted NAS access design. An authorized public test must name the exact current destination, protocol, port, source restriction and host firewall. A global client address is not permission to expose its management interface, and the absence of IPv4-style NAT does not remove IPv6 firewall protection.
Step 4: Recheck a changed prefix and use authorized external evidence
Observe a naturally occurring change, or renew/reconnect only the authorized test uplink during an approved window. Record old and new PD blocks, validity/preferred lifetimes and downstream assignments. Do not promise or force a prefix change by repeatedly disrupting an entire household connection.
Audit exact-address references in firewall rules, DNS records, allowlists, service bindings and monitoring. Prefer interface/zone-based policy where it expresses the intended permission without hard-coding the ISP prefix. A rule with an old literal address may stop matching; an overbroad replacement can expose other devices. Preserve source restrictions and update only references owned by this exercise.
Old addresses may remain valid for existing connections while becoming deprecated for new ones. Check advertised lifetimes, source selection and fresh connections rather than deleting all IPv6 addresses from clients. RFC 4861 and RFC 4862 describe advertisements and address lifetimes; the ISP and client determine the actual transition.［4］
| Check method | Expected observation | If it fails |
|---|---|---|
| Reread PD and LAN status | Current LAN subnet belongs to the actual delegated block | Check ISP delegation and allocation before client settings |
| Inspect client RA, address and default route | Current source and intended next hop are available | Check advertisements and the client's configuration |
| Make fresh authorized IPv6 outbound requests | Router and client both work on their respective paths | Separate source routing, forwarding, DNS and return failures |
| From an authorized independent IPv6 network, try router administration | No successful WAN administration session | Stop and remove the unintended input permission |
| Test a deliberately permitted service and one unpermitted port | Only the documented allowed service connects | Check router forwarding, host firewall, service bind and ISP filtering |
| Reconnect or reboot only the test router, then repeat | Saved intent survives and address references remain valid | Restore owned changes and reread current PD |
Use the client to check its visible public IPv6 exit, then distinguish that from inbound access. If a tunnel is also present, review unplanned IPv6 bypass. An outbound web response cannot prove that WAN administration is blocked.
Without an authorized external IPv6 vantage point, record inbound verification as not performed and do not claim public exposure acceptance. A failed external request alone also cannot locate the blocker: correlate it with router counters, host firewall and service state. Restrict observations to the approved hosts and ports; do not scan other users' networks.
Step 5: Restore configuration without pretending to restore the ISP
Undo only this exercise's reqprefix, LAN assignment and advertisement changes, plus its temporary service permissions or address references. Restore their recorded prior values through their owning configuration, preserving later unrelated edits. Reconnect over the independent wired management path before applying risky changes.
Reinspect the currently delegated prefix and LAN assignments after restoration. The ISP may retain the new prefix; restoring a configuration archive does not reserve or recover the old one. Reconcile DNS and exact-address rules with the current authorized addresses, then remove stale references only after confirming which services still use them.
Close temporary external test permissions, stop any test service you created, and verify it is no longer reachable from the authorized outside sample. Repeat normal LAN DNS and IPv4/IPv6 requests plus a fresh local management session. If restoration cannot be demonstrated, stop further changes and recover locally rather than weakening firewall rules.
Summary
- Verify WAN addressing, prefix delegation and LAN distribution as separate stages.
- Match advertisements and default routes to the actual downstream topology.
- Review input, forwarding and necessary ICMPv6 independently.
- Restore configuration intent and reconcile it with the ISP's current prefix.
FAQ
Does a global WAN address mean the LAN has a delegated prefix?
No. WAN addressing and prefix delegation are separate outcomes. Inspect the IPv6-PD block and the downstream assignment before expecting clients to receive globally routed addresses.
Can requesting /56 force the ISP to provide it?
No. The request is constrained by the ISP's service and allocation policy. Use its supported setting and stop if your topology requires more space than it delegates.
Why does a client have an address but no IPv6 internet?
It may lack a default-router advertisement, valid source selection, forwarding permission or an upstream return path. Check addresses and routes on both the client and router independently.
Should I block all ICMPv6 to hide the network?
No. Necessary ICMPv6 supports neighbor discovery and error/path-MTU signaling. Keep the documented protections and required message types instead of blanket blocking or blanket permission.
Does public IPv6 remove the need for a firewall?
No. Globally routable addressing identifies a possible route, while router and host firewalls decide whether new inbound connections are permitted. Verify the intended service boundary explicitly.
Will an old-prefix firewall rule update itself?
Do not assume a literal address will follow renumbering. Review address-based rules and DNS records, preserve restrictions, and update only the references whose ownership and purpose are known.
Can restoring a backup bring back my old ISP prefix?
It restores local settings, not the ISP's allocation. Reread the actual delegation after recovery and adapt legitimate address references to the prefix currently assigned.
Sources:
- OpenWrt — 25.12.0 release notes — https://openwrt.org/releases/25.12/notes-25.12.0
- OpenWrt — IPv6 configuration — https://openwrt.org/docs/guide-user/network/ipv6/configuration
- OpenWrt — IPv6 troubleshooting — https://openwrt.org/docs/guide-user/network/ipv6/troubleshooting
- IETF — RFC 4861 and RFC 4862, Neighbor Discovery and Stateless Address Autoconfiguration — https://www.rfc-editor.org/rfc/rfc4861 ; https://www.rfc-editor.org/rfc/rfc4862
- OpenWrt — Firewall configuration — https://openwrt.org/docs/guide-user/firewall/firewall_configuration
- IETF — RFC 4890, Recommendations for Filtering ICMPv6 Messages — https://www.rfc-editor.org/rfc/rfc4890
Sources checked 11 October 2026.
Related Articles:
