Device in question is an EspressoBin; both LAN ports are bridged, as is default. ULA networking is fine, but IPv6 over the WAN only works on the br-lan.2 network; no DHCPv6 requests appear from the br-lan network. There are some static DHCPv4 assignments on the br-lan network: could that be telling the system to not bother with DHCPv6 or SLAAC?
No. Most likely your ISP is handing out /64 and it's getting assigned to your WAN and there is no more prefixes to use on the LAN.
Absolutely zero reason to hand out /64, the absolute minimum is /60 and /56 is the right thing to do. See if you can call your ISP and request a /56 or if not that at least a /60
That's not the situation here: the allocation is a /48; the router is using a /56 on the WAN; the interfaces are getting /64. Guest VLAN works just fine; it's the unmarked default LAN that's not pushing out global addresses.
I assume you mean the router gets a /56 delegation using DHCPv6-PD on the WAN interface. A prefix larger than /64 should never be assigned to an interface, and usually you also don't use smaller prefixes than that since SLAAC requires exactly /64.
Make sure you have ip6assign of 64 on the LAN and enable RA in server mode on both guest and lan, don't give away a bigger assigent on guest for example
Unless you are planning to have downstream routers for additional subnets.
- WAN6 interface; with static IPv6 address on a /124, and a routed prefix of /56
- Both LAN & Guest (VLAN 2) are set to RA server, DHCPv6 server, NDP disabled, DHCPv6 stateful, and /64 assignment.
- Router is setup with a /60 ULA
- Both interfaces correctly allocate ::1 addresses to themselves, on both ULA & Global networks.
- Guest network works fully on IPv6, and registers DHCPv6 leases.
- LAN network works with ULA clients; but does not register DHCPv6 leases, or pass along Global traffic.
- Firewall: LAN & Guest are forwarded to WAN6; WAN6 is forwarded to LAN & Guest
- "Always announce default router" seems to have no impact on the outcome.
Does LAN firewall allow input to the router?
I doubt you want wan6 forwarding by default or allowed to forward to lan or guest.. basically you have no firewall (on ipv6).
But it does confirm that the thing I was concerned about isn't an issue. I was wondering if you were maybe rejecting input to LAN, and so neighbor discovery protocol and etc were not working.
Alright, turned that forwarding on WAN6 to "reject". https://centralops.net/co/Traceroute.aspx can't ping the internal interfaces anymore. Based on my debugging efforts against various IPv6 rulesets, here's my current set of rules; censoring out IPv4 sensitive content.
you're still allowing ipv6 any host in wan6 to any host in lan ports 1024-65535, same for guest, so basically zero filtering on inbound connections.
At this point my inclination is to encourage you to
firstboot and set things up from scratch. You shouldn't need to adjust the firewall at all, it should already do pretty much what you want. You allow outbound connections from LAN or guest, and any return traffic is handled by conntrack... If you have specific devices that need to allow inbound connections you open just that device and just that port to forward from WAN6 to LAN. You probably never want any inbound connections to a guest network.
Well, I deleted those rules you pointed out just now; and I'm inclined to agree with you. I've used OpenWRT for years on different devices; and was doing IPv6 stuff 10 years ago. But a lot of that was without the stuff that you do now in LUCI, or using FW3 & ODHCP to manage; that was with radvd + babel. It just seems really odd that IPv6 would work perfectly on a VLAN, but partially on default.
Do you see anything in the Status->System log, which might indicate where problems could be? (or use 'logread' from the console).
Yep, start with firstboot, config the LAN wireless networks, and the guest network/vlan and leave the firewall alone. See how it works. If you need to open your ipv6 firewall for inbound connections add specific inbound rules for specific ports to specific devices.
@geofb @dlakelan : I didn't see anything in the logs particularly alarming. Wiping & reloading the device is a non-starter: that thing took us months to get loaded correctly in the first place. Being less generous with the firewall rules works fine for the Guest network clients; so you all's concerns there are satisfied.
(ponders) The LAN interfaces / onboard switch logic of the EspressoBin may be wonky. br-lan is a bridge interface across 2 NICs; which is default for the system. I tried making that an unmanaged interface, and adding .0 & .1 VLANs; that didn't work. So something is messing with the default/untagged traffic.
Do you have igmp snooping enabled on one and disabled on the other? Or enabled at all?
Not enabled on either. I'm aware that causes issues with multicast.