> Not sure if this is what you were describing, but my dhcpd server is a separate machine to the router.

That was not what I was describing. I was figuring that your DHCPv6 client (that talks to your ISP) and your DHCPd would be on the same machine, but maybe that's okay. How does your dhcpd server get its address? A DHCPv6 request to the router? If so, the following report might (might!) be useful to you:

So, while I DID find out about dhcp-eval(5), it doesn't look to me like ISC DHCPd will do what you want. I didn't see any parameters documented in the dhcpd.conf manual that looked like they were prefix-independent.

Probably your best bet is to template your dhcpd.conf and known_hosts files, then use your network manager's [0] "on address change" hooks to fill in the currently-assigned prefix, write out new files, and bounce dhcpcd.

[0] NB: NOT (neccessarily) NetworkManager (that nasty, wretched thing), but maybe like dhcpcd's run hooks.

The second line is the only one you need for NAT to work. The first is irrelevant to forwarded traffic. If you have no other rules then a) NAT will be applied to your outbound connections, and b) you'll have no firewall for the network behind the router.

NAT and firewalling might both done in netfilter via iptables/nftables rules, but they're completely orthogonal decisions. You can do either of them without the other.

> It is true that without the firewall's involvement the router would drop all traffic destined to the LAN. [0]

Which means this is completely wrong. It won't do this unless you do something to make it do this (i.e. put some rules into FORWARD that control what traffic is/isn't allowed). MASQUERADE just changes the source IP on outbound connections; it doesn't drop inbound connections.

> [0] Unless the router were "excitingly" misconfigured!

This is probably the pivotal difference lol. Most of the ISP-provided routers I've used either have a default-allow policy or auto-create firewall rules when you add a NAT forwarding rule. I don't honestly recall which because it's been like a decade, but I do remember that I didn't have to explicitly add a firewall rule.

> NAT requires a stateful firewall too.

Yes, you’re repeating what I’m saying. NAT forced router vendors to implement stateful connection tracking and it increased the security of everything behind them.

> So you don’t actually need anything different nor special to have the same level of security with IPv6 vs IPv4 + NAT.

This isn’t how it played out in practice though. Huge swaths of home routers had no firewall at all when you enabled IPv6 support because it would have taken slightly extra work to enable the v6 conn tracking.

UPNP is not enabled by default on my router nor has it been on the last few. I think that was common like 15 years ago before all of the gaming consoles figured out how to do STUN on their own.

I've had "native" IPv6 service for something like twenty years. I've not had a problem with accessing any of the internet.

If you're hinting that roughly half of the internet-connected servers don't have IPv6 addresses, then my reply is "so what?". Only idiots are suggesting that folks who aren't running an experimental lab (or ISPs that have the expertise required to set up the NATs needed to reach the IPv4 internet from v6-only service) go IPv6-only.