Wow.. this thread certainly got long.
Pardon me while I take this into a more philosophical direction (and even ramble)...
Thinking about this more and more, I think one of the problems I'm having is that people use the generic terms "L2" and "L3", but those terms are meaningless in a vacuum. L3 can't exist without a defined L2. In addition, neither of the terms have any meaning without a defined L1.
"L3" means the network layer. Most of the L3 firewalls/routers discussed in this thread would be better called "IPv4 routers" because they require IPv4 network addressing in order to do any routing. A few also do IPv6 routing and dabble with IPSec. In most of these cases, they are also L2 devices, because they are intelligent enough to route L3 packets to other L2 devices.
My mental block is that I don't think of my PC as "192.168.0.1." It only assumes that identity when it's using IPv4 _and_ that happens to be the address DHCP assigned. I could very easily program my DHCP server to give a new IPv4 address to each machine every few minutes! As well, I can just turn off IPv4 and be completely dependent on IPv6!
I think the IPv6 issue is more concerning than the random IPv4 issue. IPv4 can be somewhat controlled and contained with DHCP. IPv6 can't be.
So, ignoring IPv4 addresses that might change and ONLY focusing on IPv6... and assuming that the L3 firewall/router has at least the pfSense level of ipv6 support... what good is a L3 router/firewall that depends on IPv6 addressing when IPv6 addressing can't be predicted? Privacy extensions are an accepted part of the IPv6 standard, which means that IPv6 addresses are DESIGNED to not be predictable!
In fact, I sampled 20 devices on my network to see what happened with DHCPv6. (The only two devices I have that don't support IPv6 weren't included.) Of those 20 devices, ZERO used the DHCPv6 address to access the internet. In some cases (android devices) the DHCPv6 server was ignored. In the rest, the device used it's own SLAAC address or a privacy extension address for outside access. There's no way to route or firewall single machines when I can't predict which IP address they'll use!
Oh, in one case (a windows machine) I even assigned it a static ipv6. It still generated a temp IPv6 for outgoing access.
In all cases where a DHCPv6 assigned or static IPv6 was accepted by the client, I could use that address for traffic going TO that client... it just wasn't usable for traffic coming FROM that client. At least this allows port forwarding to still work.
The solutions...
In the short term, with tools like pfsense, this type of thing can only be handled with generic network/subnet addressing. That means routing and firewalling have to occur at the network level, and not at the host level. While my tests show that nothing uses a DHCPv6 assigned address for outgoing access, at least they always used an address in the same /64 network. For most folks, this is what they already do anyway, so it's no big deal.
It should be noted that this means that anything except for a "default route" or "default firewall rule" will require different subnets... which means having to get an IPv6 prefix larger than /64 from your ISP. For some, that's doable. For others, it's not. It's also important that even if your ISP allows it, there aren't many router/gateway products that also support it easily. pfSense does. Sophos products do NOT. Some DDWRT/Tomato variants do, but usually require going into "advanced" settings pages or even modifying scripts.
Extending that idea... if you need all traffic on the same subnet (either because of ISP /64 limitations or for legacy "broadcast" apps), at least with pfSense, a person could use L2 vlan's bridged together to "appear" as a single subnet, and use firewalling at the interface level.
In the longer term, I think the soft/firmware for routers and firewalls is going to have to be re-designed with the problems of IPv6 planned for. We're trying to shove IPv6 concepts into IPv4 mentalities, and it just doesn't work. IPv4 assumes one IP address for each interface. IPv6 has no such limitation. It's fairly normal for routed/firewalled interfaces to be NAT'd in IPv4. That isn't the case for IPv6. IPv4 addresses can be predicted, but that also isn't the case for IPv6.
One possible way to deal with the difficulties of IPv6 routing/firewalling might be to fall back to L2. At least at the L2 layer, I have a single address for a single interface that can be predicted. It might even be considered to use ipv6 DUID's for routing purposes. (At least a DUID can be re-assigned in case a machine gets replaced.) Then again, this is trying to fit the new IPv6 problems into an older solution.
Similar to the above idea, perhaps a router/firewall should keep better track of NDP and use that data to massage firewall/routing rules. So, for example, if my router somehow knows that 2001::2:3 should have rule X applied, it watches NDP to learn the MAC address of 2001::2:3. Then, if the router/firewall notices, via NDP, that "2002::7:8" has the same MAC address, it would automagically use the 2001::2:3 rules for 2002::7:8 as well.
(You know, I actually like this last idea best of all. I could use DHCPv6 to get that initial IPv6, set firewall rules on the initial IPv6 address, and NDP could be used to associate any privacy extension addresses to the DHCPv6 assigned address. This does fall short with Android devices that reject DHCPv6 completely, however.)
Some of these ideas require more than just re-working router/firewall soft/firmware. Most of the routing and firewall "magic" actually happens in kernels, so perhaps the kernels need to be re-worked to handle IPv6 as a first class network, and not a red-headed stepchild.
By the way, if you read this far, thanks for "listening" to me ramble.
Take care
Gary
