Options to stabilize prefix from DHCPv6-PD in 26.1?

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

[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 :)

[OPNenthu]

Hi 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?

[OPNenthu]

@franco, I just noticed this https://github.com/opnsense/core/issues/10048

In your opinion should I just go ahead and configure my internal interfaces with static ULAs and use NPTv6 for outbound?  There are two issues that I don't know if the project will be able to accommodate in the short term (or at all, in the case of #1):

1. As per RFC4941 some client OSes (at least Windows 10 & Linux from what I've tested) take a literal interpretation that they should not revive a deprecated prefix.  So even if the same prefix is seen again on WAN and a fresh RA is sent with positive valid & preferred lifetimes, those clients will not regenerate temporary addresses.  This effectively breaks SLAAC, or at least a subset of it.

Impact: mostly workstations and clients that stay running for long durations without sleep or reboot.  In order to observe the issue, the prefix must be deprecated while the client is running and the client must be powered on long enough for the next temporary SLAAC address to be due for generation (usually each 24 hours by default in most OSes).

2. As per the GH ticket above, adding a ULA prefix as a VIP to the internal interface for RA distribution also breaks when WAN loses its prefix.  Thus VIP ULAs cannot be relied on for internal networking.

I think the combination of those means that, at present, the way for people with dynamic prefixes to get stable internal SLAAC is to not track the WAN at all, and to not use ULA VIPs.  Instead we have to statically configure the interfaces with ULAs and rely on prefix translation for internet access. 

Is this a fair assessment, and, is there anything I can add in GH at this time that could reasonably be accepted and developed by OPNsense to help with this?  (I understand dynamic prefixes are not a high priority for the project, so I don't mean to come off pushy here.  Just asking.)

Thanks for considering.