Options to stabilize prefix from DHCPv6-PD in 26.1?

Started by OPNenthu, March 21, 2026, 05:15:05 PM

Previous topic - Next topic
March 26, 2026, 06:32:16 AM #15 Last Edit: March 26, 2026, 06:38:03 AM by Monviech (Cedrik)
Your ISP looks weird I wouldnt use the proxy with them.

It proxies all prefixes that are contained inside the RAs. No way to exclude anything if RAs are proxied.

You couldnt even use radvd together with the proxy since with its constructor mode it also advertises all WAN side prefixes.

Mac addreses are not masked since the EUI-64 Addresses (lla, ula, gua) are generated automatically by clients, and it contains the MAC address anyway.

With any setup your ISP knows all of your devices, you would have to NAT66 to mask them completely.

If you dont trust the ISP and it does weird stuff get a different one essentially.
Hardware:
DEC740

March 26, 2026, 03:33:42 PM #16 Last Edit: March 26, 2026, 10:17:02 PM by OPNenthu
Thank you!  Good that I asked.

The EUI-64 issue is workable, I anyway disable them on web clients.  Mobile OSes have privacy features and MAC randomization already enabled.  The desktop/laptop machines get configured to use stable privacy addresses with privacy extensions on top.  (This is what breaks when those pesky RAs with preferred lifetime=0 come in.)

The ULA routes that the ISP tries to install are definitely not needed.  DHCPv6 is preventing them from being configured on the LAN, but the routes still show up on the WAN interface.

You cannot view this attachment.

I'm not sure if those are coming from DHCPv6 or from rtsold which is running in the background.  Is there a way to disable rtsold on WAN from the OPNsense UI?  In Linux I could use a sysctl to selectively disable it for an interface but in FreeBSD I think it's a global systctl (net.inet6.ip6.accept_rtadv=0) which would kill my internal network.

EDIT: I added the tunable to not accept RAs and the ULA routes still got added, so must be from DHCPv6.

--

It seems I might be alone with the prefix deprecation issue.  I'll give it some more time to see if any discussion develops around this before submitting a ticket, but am hoping to save the embarrassment of raising a nonsensical request :)
N5105 | 8/250GB | 4xi226-V | Community

https://www.youtube.com/watch?v=XI9NG068TwI

March 26, 2026, 11:07:12 PM #17 Last Edit: March 26, 2026, 11:33:49 PM by OPNenthu
Quote from: JavierĀ® on March 21, 2026, 11:25:09 PMHi everyone, I think this is a good way to use IPv6. I use OpenBSD with this configuration; it's very configurable.
If the prefix changes, it's easy to fix.
I don't know if Opnsense can configure something like that

https://eradman.com/posts/ipv6-strategy.html#:~:text=Use%20rad(8)%20to%20distribute%20the%20stable%20addresses,egress%20inet6%20from%20fd00:51::/64%20nat%2Dto%202603:7081:5506:d885::/64%20source%2Dhash.

I don't think we have an equivalent to 'nat-to ... source-hash' in the FreeBSD favor of pf.

If I'm not mistaken it can be approximated with a combination of stateless NPTv6 and privacy addresses on the clients.  With an EUI-64 address, NPTv6 will directly translate and expose the host bits.  As long as a privacy ULA is active on the client, it should be the one preferred for egress and NPTv6 will preserve the privacy bits.  There would be no way to mask the host bits at the firewall level unless regular Outbound NAT is used for the WAN address (?)

Am I on the right track?
N5105 | 8/250GB | 4xi226-V | Community

https://www.youtube.com/watch?v=XI9NG068TwI