在电信光猫不可调的限制下，iStoreOS/OpenWrt作为二级路由常无法为终端分配有效IPv6地址。这份基于24.101版本的实战总结，完整还原从故障定位、模式修正到网关通告的关键步骤，提供可复用的配置清单与原理验证，解决‘有地址无路由’这一典型IPv6连通性问题。
智能速览
根本原因在于二级路由默认启用IPv6服务器模式，与光猫RA/DHCPv6服务冲突
核心修复是将LAN口路由通告和DHCPv6服务设为‘中继模式’并勾选‘始终通告默认路由’
必须清空ULA前缀、关闭IPv6 AAAA记录过滤、禁用WAN口IP动态伪装（NAT）
终端获得240e:/2408:开头公网IPv6地址但缺失fe80::开头的默认网关即属典型中继失败
通过odhcpd重启与br-lan全局IPv6地址刷新可清除旧配置残留
最终IPv6测试评分达10/10，证实内网设备已具备完整端到端IPv6访问能力
精华内容
当光猫拨号且IPv6已启用，二级路由不应争当‘发号施令者’，而应成为忠实的‘信息信使’——这一定位转变，是打通家庭IPv6的最后一公里。
故障定位
初始拓扑为电信光猫（拨号主路由）→ iStoreOS/OpenWrt（二级路由）→ 终端设备。现象明确：终端直连光猫可获公网IPv6，经OpenWrt则仅分配fdd5:开头的ULA本地地址，且ipconfig /all显示无IPv6默认网关。WAN口实测获取到240e:3a3:xxxx/128公网前缀，证明上游IPv6服务正常，问题锁定在LAN侧转发逻辑。
模式修正
进入LuCI界面‘网络→接口→LAN→DHCP服务器→IPv6设置’，将‘路由通告服务’与‘DHCPv6服务’均由默认的‘服务器模式’改为‘中继模式’。该操作使OpenWrt停止自行广播RA报文和分配地址，转而透明转发光猫下发的IPv6前缀与DNS信息。实测表明，切换后终端仍无网关，说明中继功能尚未完全激活。
网关关键项
在相同IPv6设置页中，勾选‘始终通告默认路由’。此选项强制OpenWrt向内网设备通告其自身链路本地地址（如fe80::xxxx%br-lan）作为IPv6默认网关。操作后终端立即获得该网关，test-ipv6.com测试结果由‘未检测到IPv6’变为‘IPv6状况评分10/10’，确认数据包可成功路由至互联网。
配套清理
同步执行三项必要清理：在‘全局网络选项’中清空自动生成的ULA前缀（fdd5:…），避免干扰公网地址优先级；于‘DHCP/DNS→高级设置’取消勾选‘过滤IPv6 AAAA记录’，确保DNS能返回240e:等公网域名解析；在‘防火墙→区域（WAN）’中取消勾选‘IP动态伪装（NAT）’，因IPv6设计原生不依赖NAT，启用反而可能阻断ICMPv6邻居发现。
服务生效
通过SSH执行两条命令确保配置即时生效：/etc/init.d/odhcpd restart 重启IPv6服务；ip -6 addr flush dev br-lan scope global 清除桥接接口上所有全局作用域IPv6地址。实测发现，若跳过地址刷新，终端可能仍缓存旧ULA地址，导致新网关无法及时应用。重启后终端IPv6地址稳定为240e:3a3:xxxx开头，且默认网关字段完整填充。
这套配置方案不是理论推演，而是针对‘光猫不可控’这一现实约束的精准解法。它把二级路由从IPv6的‘决策者’还原为‘传递者’，让家庭网络真正融入IPv6原生生态。未来随着更多网站启用双栈甚至纯IPv6，这种端到端的连通能力将成为基础体验。当所有设备都拥有唯一公网地址，远程访问、P2P传输与低延迟通信是否将迎来新的可能？
