Since some major ISPs are only handing out /60 prefixes, does it make sense if I change the wiki page to use ip6assign='64'? People familiar enough with IPv6 can customize to their network setup (as they're likely already doing) and unfamiliar people can just use a workable default of 64.
2 Likes
It's not only wiki, but default LAN-interface as well:
# uci get network.lan.ip6assign
60
The default LAN ip6assign=60 does not immediately cause bad results for a ISP that is handling out /60 (or /64 or /56, if I read about odhcpd's behavior correctly).
Guest WLAN ip6assign=60 consumes the entire /60 if that's what an ISP hands out. This can cause an existing non-guest IPv6 network to stop working. (Guess how I found out. 
)
So my idea is to make the initial starting-point script on the wiki less error prone.
1 Like
I always change to /64 for all internal networks.
"IPv6 Assignment Hint" on Guest network I set different between main and Guest network.
Also I put my Nest Thermostats on the guest network, to keep their RAs off my main network.
As TokenBucket says, if the ISP is handing out /60 then creating Guest of /60 will cause bad things to happen. I can't think of a reason why an IPv6 subnet should default to anything other than /64
Some interesting reading: RFC 7368 IPv6 Home Networking Architecture Principles
1 Like
(Moved to the Talk about Documentation section.)
Looking more closely at the wiki page, it's clear that the script was never intended to provide IPv6 access to guests (since there's no DHCPv6 or SLAAC firewall rules). Thus, I removed the ip6assign=60 and dhcpv6/ra config from the script and instead added a new section on getting IPv6 working for guests.
So new copy&paste users should get reasonable defaults with no IPv6 and more advanced users can read further to optionally get IPv6 working.
2 Likes
Am I just extremely lucky with my ISP? It's handing me out a /48 prefix.
1 Like
Comcast (US cable provider) is /64 by default, /60 on request. “Who would ever need more that 16 subnets?” is right up there with “Who would ever need more than 640 k of RAM?”
I vaguely remember the recommendation being a /56 for the smallest delegation.
Edit: From the above reference to RFC 7368:
For a typical IPv6 homenet, it is not recommended that an ISP offers less than a /60 prefix, and it is highly preferable that the ISP offers at least a /56.
1 Like
No no no no no. The only reasonable defaults are those that make ipv6 work out of the box. /64 for a guest Network is fine, disabling ipv6 is not
4 Likes
I would agree that a reasonable default would be for IPv6 working for the Guest WiFI out of the box, but the wiki page was not doing that (it was instead breaking IPv6 for regular networks) and I don't have the expertise to rewrite the page to give IPv6 for the Guest WiFi out of the box. Thus, that's why I removed broken IPv6 for Guest WiFi out of the box and gave some additional resources for adding on IPv6 for Guest WiFi.
Please, if someone has better edits for the wiki page, please go ahead and overwrite my changes.
I'll take a look, can you post the link to the exact page you're discussing?
If I look at the original version, I think it should work fine with just the change ip6assign=64, and it will hand out SLAAC rules. There's no input required for SLAAC, it's just Router Advertisements output to the network.
I agree that the bit about avoiding access to the WAN side modem / ISP equipment is good. Can we just revert to enabling ra=server and ip6assign=64 and leave dhcpv6 out of it (for guest networks it seems unnecessary anyway).
Am I missing something?
I think that I previously tried using ip6assign=64 for the guest and lan networks and that did not seem sufficient to work -- some of my devices were not able to get IPv6 addresses. Once I added the Guest-SLAAC rule, IPv6 worked (though my memory could be wrong).
I don't know whether people expect DHCPv6 for IPv6 guest networks.
In my experience, that was not enough to work, but I'm out of my depth, so I'm probably not the right person to answer that question.
Yes, ok, I think those rules are needed for ipv6 to work. The weird thing is that they're not automatically part of the OpenWrt firewall. I see they are automatically part of the firewall for packets from WAN... but really they should be allowed as input from every network by default. IPV6 can't work without certain icmpv6 packets allowed.
The only reason ipv6 on LAN works is that by default it allows ALL input from LAN in the policy.
It seems to me if it's safe enough to be allowed from WAN by default, it's safe enough to be allowed from ALL zones by default. So, in some sense the right solution is to alter the default firewall to allow the relevant icmpv6 traffic.
I'd suggest to keep DHCPv6 enabled for guest networks, given that many users will follow this guide for IoT devices as well.
For the icmpv6 needed for SLAAC to work on guest network, I've asked similar question before with the firewall rules I think is necessary, please take a look if they look fine.
While one can debate if a "guest" WLAN should have the privilege of IPv6 connectivity, I think the guiding principle here would be to avoid the inevitable "Why does [device X] not work on my guest network?" because it somehow got an IPv6 address, prefers it, and fails. Easier to disable IPv6 at the firewall for a zone than it is to enable it.
We are going to see more and more ISPs with ipv6 only deployments, particularly WISPs, also DSlite deployments are common in Germany.
2 Likes