With IPv6, how to get both GUA SLAAC and a single ULA DHCPv6 address?

Started by espenu, July 07, 2026, 08:09:26 AM

Previous topic - Next topic
Quote from: drosophila on July 29, 2026, 02:46:57 PMMaybe not so different, and to (finally ;) ) answer your question, I did briefly consider NPT but since that relies on the subnet sizes being identical (LAN and ISP), I've decided it to be better to go NAT66. That way I don't need to care about what prefix size the ISP hands me, so an ISP change would be fully transparent and not even require any configuration change. I feel NAT66 is the superior choice for this type of setup, even if it's unusual and commonly frowned upon due to what feels like ideology these days. :)

Quote from: Monviech (Cedrik) on July 29, 2026, 03:01:11 PMThere is a very strong dogma that NAT66 is the devil itself (check out ipv6 reddit for example, they literally excommunicate people who even think about NATing IPv6).

In my opinion it just solves the same issue as NAT44 did, delegating the ownership of an IP address to a central device like a router. This is useful for Multi-WAN, dynamic DNS, VPN setups etc... and other kind of more specialized setups.

NPTv6 is harder to use, since e.g. in a SLAAC only network your router doesn't own the non-translated addresses and won't respond via NDP for them. There are ways to fix that but it's way more brute force than just using NAT66 instead.

I'm not quite in the camp of NAT66 being the devil. But it kind of breaks the intention of IPv6, and since my goal here is to have a working full dual stack while also learning proper IPv6, NAT66 feels like kind of a cheat.
By all means, it has its uses, it just doesn't align will my goals for this setup.

As I have understood it (and I'm still learning so I might be misunderstanding), the reason my setup doesn't work is due to the limitation in the Opnsense UI where setting up RA has to be done per interface, and it can't be tailored per prefix. So in this case both NPTv6 and NAT66 would be a workaround for an incomplete implementation (because it seems to have been an intentional design and not a bug).

The allure of perfection is quite strong for IPv6, if only the ISPs would have the same resolve and offer static IPv6 for all their customers like IPv6 intended...

That would be the most logical way to fix xD

ISP policy is the limiting factor at its root.
Hardware:
DEC740

Agreed that (at least arguably) the root issue is ISP policy, but very few of us here are in a position to be able to change that.

Looking at radvd, AdvAutonomous is set at the prefix level, so it should be possible to have a ULA VIP on an interface that does not get advertised for SLAAC (but can be used for DHCPv6), which is (I think) what the OP wants. I wonder if it could be done by adding a flag to the VIP (interface config) to say "[don't] use this for SLAAC", then have the radvd config generation set AdvAutonomous for the prefix accordingly. That seems less complicated than trying to handle all of it in the RA UI. Not sure how much appetite there'd be for something like this in the dev camp (Hi Cedrik!) though ;)

The Router Advertisement config generation has some magic that has always been there and cannot be easily untangled anymore.

This means different settings for different prefixes on the same interface are indeed not possible.

But it's also not really needed most of the time, the most common setups can all be done:

A: GUAs + ULAs for all hosts
B: Only GUAs for all hosts
C: Only ULAs for all hosts

It also doesn't matter if hosts generate more than a single address for either GUA or ULA, it's common to have SLAAC and DHCPv6 addresses and privacy extensions. For me it doesn't make much sense trying to be smarter than necessary here.
Hardware:
DEC740

The OP's issue is that they want to use static ULAs in their firewall rules. If SLAAC is in play, the addresses are not static, and that model breaks. They want "managed" for the ULA prefix and "assisted" for the GUA prefix (on the same interface).

If SLAAC is in play the addresses can be static too since they can be EUI-64 derived. SLAAC depends on the client configuration as well, like deactivating privacy extensions and other randomized SLAAC generation behavior, and only allow EUI-64 (or RFC 7217 stable addresses).

privacy/temporary addresses (RFC 4941 / RFC 8981) are entirely a host decision
Hardware:
DEC740

The OP stated why they don't want to disable privacy extensions too (for the GUAs, used for internet access).

I don't want to keep arguing about it, but I do think there's some merit in the OP's request. Whether there's enough demand for it to justify spending development effort on it, I'm not sure....

Maybe dnsmasq can do it. You can configure different RA pools on the same interface with different flags from what I can see.

But I never tested that.
Hardware:
DEC740