WAN IPv6 Privacy Extension Tunables don't appear to be working

[Tuxgal]

My ISP supports delegation of a /60 IPv6 prefix. I have configured the WAN interface DHCPv6 settings in OPNsense with:

- This prefix size of 60
- Request Prefix Only - Enabled
- Send Prefix Hint - Enabled
- Optional Prefix ID - 0

With this, I am able to successfully obtain a /64 for my WAN interface. It does however use the EUI64 format using the MAC address of the WAN interface to generate the lower 64 bits of the IP. Since this reveals the MAC address and is fixed, I wanted to

I am able to use the Optional Interface ID setting to control the value of the lower 64 bits to not reveal the MAC address.

However, I was hoping to rather use the IPv6 privacy extensions to randomize this value periodically and automatically. I found the net.inet6.ip6.use_tempaddr and net.inet6.ip6.prefer_tempaddr tunables which as I understand should handle this automatically. However, setting both to 1 doesn't seem to have any effect on the lower 64 bits of the WAN interface's IP.

Could anyone share pointes if they have been able to get IPv6 privacy extensions working with their WAN interface?

[meyergru]

It does not work that way (tm).

IPv6 privacy extensions enable additional IPv6 addresses, that are being used for connections going outside. They are independent of the (static, often EUI-64-derived) so-called management address, which is always kept to make a machine reliably addressable going from outside in.

That is, you probably will not see the privacy extension address in the web UI.

That being said, IPv6 does not use NAT, so even if you check via outbound connections, say, calling https://wieistmeineip.de, you will not see the WAN IPv6 address of your OpnSense, but instead the IPv6 GUA of your client, so it all depends on this client's settings, not on OpnSense's.

Also, while you might think that the client does IPv6 privacy extensions, because you do not see the EUI-64 part of its MAC address, this need not be true for Windows, because that uses a technique called "randomize identifiers" as well.

So, in short: In order to have what you (probably) want, you need to enable privacy extensions on your clients, not on OpnSense itself.

To check if Pricavy Extensions are in effect on OpnSense, you can call "curl ifconfig.me" from the CLI.
They most probably are not, because they work only with SLAAC, which is not in effect on your WAN (it uses DHCPv6) and also, because you used a trick, namely a new mechanism that allows to use a part of the IA_PD /56 prefix instead of a single IA_NA address for your WAN. You also set the EUI-64 part to an arbitrary address and this is statically configured, so no SLAAC (and thus, no privacy extensions) are in effect for WAN.

[Tuxgal]

It does not work that way (tm).

IPv6 privacy extensions enable additional IPv6 addresses, that are being used for connections going outside. They are independent of the (static, often EUI-64-derived) so-called management address, which is always kept to make a machine reliably addressable going from outside in.

That is, you probably will not see the privacy extension address in the web UI.

That being said, IPv6 does not use NAT, so even if you check via outbound connections, say, calling https://wieistmeineip.de, you will not see the WAN IPv6 address of your OpnSense, but instead the IPv6 GUA of your client, so it all depends on this client's settings, not on OpnSense's.

Also, while you might think that the client does IPv6 privacy extensions, because you do not see the EUI-64 part of its MAC address, this need not be true for Windows, because that uses a technique called "randomize identifiers" as well.

So, in short: In order to have what you (probably) want, you need to enable privacy extensions on your clients, not on OpnSense itself.

To check if Pricavy Extensions are in effect on OpnSense, you can call "curl ifconfig.me" from the CLI.
They most probably are not, because they work only with SLAAC, which is not in effect on your WAN (it uses DHCPv6) and also, because you used a trick, namely a new mechanism that allows to use a part of the IA_PD /56 prefix instead of a single IA_NA address for your WAN. YOu also set the EUI-64 part to an arbitrary address and this is statically configured, so no SLAAC (and thus, no privacy extensions) are in effect for WAN.

Thanks for the quick response.

Yep, I understand there is no NAT involved with IPv6 and I am clear on this part. Hence I didn't mention anything about NAT in my question :)

Also, I understand each client can enable privacy extensions independently which will control the lower 64 bits of its IP. So I want to leave this part also on the side.

My question was mainly about OPNsense's own IP when it connects to any servers, rather than clients behind the OPNsense router. OPNsense connects to servers and devices on the internet to search for packages, download updates, etc. Even any commands I might run from the console/shell could trigger these connections.

Could you please clarify what you mean by additional addresses? And any pointers on how would I be able to see information about these addresses, possibly in action?

[meyergru]

I already told you how you can see which IPv6 your OpnSense uses when making outbound connections and why it will not use IPv6 privacy extensions. Normally, you can see all IPv6 addresses using "ifconfig" from the CLI.

[dseven]

My question was mainly about OPNsense's own IP when it connects to any servers, rather than clients behind the OPNsense router. OPNsense connects to servers and devices on the internet to search for packages, download updates, etc. Even any commands I might run from the console/shell could trigger these connections.

None of those things should be privacy-sensitive really, though. I don't believe that there is any mechanism to accomplish what you seek (assuming your ISP doesn't support SLAAC for your WAN interface), and I can't see development of a solution being a high priority since the potential value is rather limited.

[Tuxgal]

I already told you how you can see which IPv6 your OpnSense uses when making outbound connections and why it will not use IPv6 privacy extensions. Normally, you can see all IPv6 addresses using "ifconfig" from the CLI.

I have shared all the addresses I see and which prefix it is derived from (the /60 which is working as intended). I just see one GUA.

However my question is more for the privacy extension tunables (RFC 4941 and RFC 7217) and what they do really?

net.inet6.ip6.use_tempaddr=1 and net.inet6.ip6.prefer_tempaddr tunables=1 doesn't have any effect on these addresses. If they don't affect these addresses, in which scenario are they even used then?

My question was mainly about OPNsense's own IP when it connects to any servers, rather than clients behind the OPNsense router. OPNsense connects to servers and devices on the internet to search for packages, download updates, etc. Even any commands I might run from the console/shell could trigger these connections.

None of those things should be privacy-sensitive really, though. I don't believe that there is any mechanism to accomplish what you seek (assuming your ISP doesn't support SLAAC for your WAN interface), and I can't see development of a solution being a high priority since the potential value is rather limited.

Well then what's the purpose of RFC 4941 and RFC 7217 which as I understand are the ones these two tunables control?

[dseven]

Well then what's the purpose of RFC 4941 and RFC 7217 which as I understand are the ones these two tunables control?

Those pertain to SLAAC, but you're not doing SLAAC on your WAN interface - you're doing DHCPv6 with a delegated prefix, and assigning a subnet from that to your WAN interface.

[Tuxgal]

Well then what's the purpose of RFC 4941 and RFC 7217 which as I understand are the ones these two tunables control?

Those pertain to SLAAC, but you're not doing SLAAC on your WAN interface - you're doing DHCPv6 with a delegated prefix, and assigning a subnet from that to your WAN interface.

The DHCPv6 is for obtaining the /60 prefix in my case. Each of my VLANs I am able to manage a combination of DHCPv6+SLAAC if needed to hand out /64 prefixes from this larger /60. Why is the WAN restricted to just being DHCPv6 only ? There is already an option to customize the interface ID which does change the lower 64 bits of the address. So I don't see why it is not possible to support these privacy extensions in a SLAAC mode for the WAN interface IPv6 assignment.

[dseven]

So I don't see why it is not possible to support these privacy extensions in a SLAAC mode for the WAN interface IPv6 assignment.

Ask your ISP - they would have to provide SLAAC support (advertise a prefix, router, etc)

[Tuxgal]

So I don't see why it is not possible to support these privacy extensions in a SLAAC mode for the WAN interface IPv6 assignment.

Ask your ISP - they would have to provide SLAAC support (advertise a prefix, router, etc)

Apologies if my question sounds repetitive, but could you help me understand how this is an ISP issue? The ISP has handed out a /60 to OPNsense in this case. It is OPNsense which carves out a /64 from this prefix to assign to either one of the VLANs or to the WAN interfaces, or if it chooses even do a further delegation to downstream routers. Note that I am not even requesting an IP for WAN interface directly from my ISP's DHCP server. So there is no ISP DHCP server involved in the WAN interface IP assignment.

In fact, OPNsense can control these assignments cleanly for the LAN interfaces as it chooses already using DHCPv6 or SLAAC or a combination. But the same parity doesn't exist today for the WAN interface IP assignment other than the ability to just set a hard coded value for the lower 64 bits using the optional interface ID setting and the ISP doesn't care. The ISP only cares about the addresses for the endpoints to be from the /60 prefix.

My request is not to let me choose an entire /60 prefix of my choice, but just control the lower 64 bits of the address that OPNsense picks to comply with the privacy extension RFCs. I am still clearly missing how the ISP can even help here.

If I had my linux workstation connected directly behind my ONT, I should be able to do what I am suggesting here for instance.

[Patrick M. Hausen]

Privacy extensions are defined for SLAAC only. No SLAAC, no privacy extensions. Simple as that.

RFC 4941 is very explicitly titled "Privacy Extensions for Stateless Address Autoconfiguration in IPv6".

And RFC 7217 "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)".

What gives you the idea privacy extensions are even a thing in any other context/setup?

[Tuxgal]

What gives you the idea privacy extensions are even a thing in any other context/setup?

I get that it is part of SLAAC, not debating this part.

Let me explain, how I understand this and please feel free to chime in what I am missing or misunderstanding.

1. ISP delegates a prefix (in my case a /60) to OPNsense. I know I am using DHCPv6 since that's the only one that my ISP supports, but this could be either DHCPv6 or SLAAC and should not matter for this discussion.

2. OPNsense chooses how to manage this prefix:

a) For LAN interfaces, OPNsense supports managing this prefix using either DHCPv6 or SLAAC or a combination. The choice here is independent of the DHCPv6 vs SLAAC choice made in step 1

b) For the WAN interface, OPNsense provides the option to request either an IA-NA (where my ISP ends up assigning a /128 directly) or an IA-PD which allows assigning one /64 from the larger prefix obtained in step 1 (similar to how it's being done for the LAN interfaces but in a limited way). For this discussion, I am focusing purely on the IA-PD method and not IA-NA. In other words, enabling the Request Prefix Only option.

I can share my setup (with dummy addresses to mask my real IP) to illustrate this scenario better:

Code Select Expand

Prefix delegated by my ISP - 2600:1700:1234:5670/60

Interface IPs (sharing only IPv6)

wan              - 2600:1700:1234:5670:aaaa:bbbb:cccc:eeee/64 (PD Interface ID 0)
vlan0.0010       - 2600:1700:1234:5671:aaaa:bbbb:cccc:dddd/64 (PD Interface ID 1)
vlan0.0011       - 2600:1700:1234:5672:aaaa:bbbb:cccc:dddd/64 (PD Interface ID 2)
vlan0.0012       - 2600:1700:1234:5673:aaaa:bbbb:cccc:dddd/64 (PD Interface ID 3)

All I am saying is in the context of the WAN interface, there is not sufficient control provided by OPNsense today on managing the host portion (lower 64 bits) of the IP that does get assigned to my WAN interface in this scenario.

I can freely and directly control the lower 64 bits to a hardcoded value but nothing more than that is possible today.

OPNsense doesn't provide me an option to use SLAAC to manage the lower 64 bits, which would allow me to apply/enable the privacy extensions. Hence, my argument that there is no ISP involvement here for managing IP allocations from a sub-prefix (/64) when the ISP has already delegated the parent prefix (/60) to OPNsense.

[dseven]

FWIW, my ISP actually *does* support SLAAC as well as a delegated prefix prefix via DHCPv6 (at the same time). I haven't tried fiddling with tunables to see if privacy extensions would do anything "useful" (with respect to things like downloading updates), though.

Conceptually, I think it probably could be possible to implement something *like* privacy extensions in the mechanism that OPNsense uses to assign a subnet of the delegated prefix to the WAN interface, but, as I suggested earlier, I don't think there'd be enough potential value in it to warrant the effort to develop it. OPNsense is open-source. Knock yourself out implementing it, and submit a PR when you have it working - if the developers like it, they may adopt it!

[Patrick M. Hausen]

I can freely and directly control the lower 64 bits to a hardcoded value but nothing more than that is possible today.

Yes, but what else would you expect?

OPNsense doesn't provide me an option to use SLAAC to manage the lower 64 bits, which would allow me to apply/enable the privacy extensions.

Of course OPNsense can use SLAAC on WAN if the WAN interface is of a type that supports SLAAC. Like plain Ethernet connected to an upstream router that performs RA. OPNsense cannot "do SLAAC" on its own. SLAAC only works in the context of an upstream gateway sending router advertisements.

If that is not the case what should OPNsense do in your opinion? Invent "someting"? There is no standard for that so there is nothing to implement.

My opinion, of course.

Also (just to throw in some OSI terminology ;-): privacy extensions are for end systems. OPNsense is an intermediate system.

[Tuxgal]

I can freely and directly control the lower 64 bits to a hardcoded value but nothing more than that is possible today.

Yes, but what else would you expect?

The full privacy extensions support that allow changing the host part of the addresses periodically to a random value, without having it set to some fixed custom value :)

OPNsense doesn't provide me an option to use SLAAC to manage the lower 64 bits, which would allow me to apply/enable the privacy extensions.

Of course OPNsense can use SLAAC on WAN if the WAN interface is of a type that supports SLAAC. Like plain Ethernet connected to an upstream router that performs RA. OPNsense cannot "do SLAAC" on its own. SLAAC only works in the context of an upstream gateway sending router advertisements.

If that is not the case what should OPNsense do in your opinion? Invent "someting"? There is no standard for that so there is nothing to implement.

My opinion, of course.

Yes I agree, the RA and upstream gateway parts are lacking. But it also means, we need to give up on privacy extensions for OPNsense itself when it is viewed in a role where it is not a router (i.e. connecting to package repositories, downloading plugins, checking firmware updates, etc.) when using prefix delegation.

Also (just to throw in some OSI terminology ;-): privacy extensions are for end systems. OPNsense is an intermediate system.

OPNsense is unfortunately not an intermediate system when it acts as an end system for the scenarios I listed above like connecting to package repos, checking for firmware updates, etc. where it performs roles than just being a router. I would say pretty much any time it needs to use the GUA WAN IP assigned on its interface in IPv6 (assuming no NAT), this applies. So we lose privacy extensions support in these scenarios.

I was doing further searches on this topic and I came across this post from last month where the exact same concern is being pointed out - https://forum.opnsense.org/index.php?topic=44448.msg224885#msg224885

FWIW, my ISP actually *does* support SLAAC as well as a delegated prefix prefix via DHCPv6 (at the same time). I haven't tried fiddling with tunables to see if privacy extensions would do anything "useful" (with respect to things like downloading updates), though.

Conceptually, I think it probably could be possible to implement something *like* privacy extensions in the mechanism that OPNsense uses to assign a subnet of the delegated prefix to the WAN interface, but, as I suggested earlier, I don't think there'd be enough potential value in it to warrant the effort to develop it. OPNsense is open-source. Knock yourself out implementing it, and submit a PR when you have it working - if the developers like it, they may adopt it!

I am probably considering a simpler solution would be to have some cron job of sorts that merely updates the "Optional Interface ID" value with a random value periodically which would have a similar effect. But it does bring down the interface entirely IIUC, and sends a full DHCP request once again possibly.