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

[espenu]

Maybe 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. :)

There 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).

[Monviech (Cedrik)]

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.

[dseven]

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 ;)

[Monviech (Cedrik)]

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.

[dseven]

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).

[Monviech (Cedrik)]

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

[dseven]

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....

[Monviech (Cedrik)]

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.

[espenu]

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

That would require full admin access to all clients though (I mean, I do have that, but it might not always be the case).
I'm not trying to be difficult (not intentionally at least 😜), it's just that Opnsense is such a great system and it would be so great if it was possible to handle this type of setup (which I think is a completely valid use case), especially since the underlying systems actually support it and it's "just" a UI limitation.

I understand that it might be a narrow use case so no one wants to spend dev time fixing it, and that's fair. I will then just have to find a different approach to the whole stup, but at least I've raised the question 😊.

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.

I read somewhere that the same limitation was also present in the Dnsmasq RA, but I haven't actually tried it the way you describe. I will see if it's possible as soon as I have time to sit down and experiment.
Thanks.

[funtowne]

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.

Out of morbid curiosity I set up DNSMASQ with SLAAC as the mode with the IP range of my ULA ffd0::1000 to ffd0::2000 (ULA truncated). I also set up ra-stateless for :: 

Clients only seemed to get the slaac-generated IPs; the dhcpv6 ULA range did not assign a DHCP ULA address in the range above.

Happy to be wrong here in case I did a misconfigure, but manually-entered ranges including a prefix appear to be ignored for the use case of only defining a ULA range for dhcp. ::1000 to ::2000 without the prefix worked as expected, but only for the GUAs.

I'll double check my work and maybe open a bug report if needed, as the info tip for defining IP ranges does show a prefix (if defined on an interface of course) as a valid input for an ip range.

[meyergru]

While you can syntactically do that and maybe the different RAs even get send out, I would not have expected it to work, because RAs are broadcasts, so they reach all clients. The mode flag determines if the clients should ask for DHCP offers. So, the clients will probably not request DHCP addresses once they see an RA that explicitely forbids them to.

I doubt that they would do that depending on specific ranges.

[funtowne]

While you can syntactically do that and maybe the different RAs even get send out, I would not have expected it to work, because RAs are broadcasts, so they reach all clients. The mode flag determines if the clients should ask for DHCP offers. So, the clients will probably not request DHCP addresses once they see an RA that explicitely forbids them to.

I doubt that they would do that depending on specific ranges.

Reaching all clients is fine and likely with OP is after (me too!).  The use case here is to have clients assign a ULA via both DHCPv6 & SLAAC, with SLAAC alone for GUA.  I can see the use case here given that ISPs do not keep GUAs and therefore internal addressing stable.  Other issues of course persist with client preference. 

I managed to have this same setup working with kea a while back and may resume it with one of the 3rd-party (non repo) ddns plugins that work with unbound to register leases.  Keeping BIND happy was just too much effort.  Here's the little plugin: https://github.com/JameZUK/os-kea-unbound/