Right now it doesn't seem straightforward (or even possible) to enable the use of privacy addresses for outbound connection from an OpenWrt device. If an IP was obtained via odhcp6c (which is also the only supported way to obtain an address using SLAAC on OpenWrt), it uses EUI-64 by default.
A recent paper has shown that this allows an adversary to track users of a network with dynamic IPv6 prefixes. All that is needed is a single device in the network with an EUI-64 address to track other devices, even if they use privacy addresses.
There are a few vectors that will leak EUI-64 addresses of OpenWrt routers and APs by default:
NTP
DNS (not an issue for APs)
For the router itself, the ip6ifaceid="random" option can be used to obtain a random IP from IPv6-PD (which is not the same as a privacy address). But this is not applicable to APs downstream as the odhcp6c equivalent ifaceid does not support random, and not to mention that it'd complicates inbound connections to them.
i like to ask, what is it good for ?
OpenWRT is router, not a consumer device
Downstream devices, like PC,Android ... will have they implementation of privacy
but router ?
sorry, but i don't see any reason
Because routers do interact with the Internet, via DNS (as the DNS caching server) or NTP. Some people might run ad-blocking DNS which connects to CDNs to download block lists, leaking its IPv6 address.
The paper linked above shows that it only takes one device using EUI-64 to allow user tracking across different IPv6 prefixes.
This IPv6 address will be used as a secret to generate IPv6 addresses for link-local addresses and autoconfigured ones. All addresses generated after setting this secret will be stable privacy ones by default.
This setting is only applied for addresses generated by the kernel. And it does not have any bearings on whether privacy addresses (RFC 4941) are used/generated, only whether those should be stable privacy address (RFC 7217).
OpenWrt does not make use of those addresses, since kernel-based SLAAC is disabled and that the choice was intentional as evident by this quote:
As such, support for privacy addresses would have to be wired into the OpenWrt components that perform RA processing instead.
If you're having issues configuring your device for IPv6 Privacy, feel free to ask for assistance; but as noted by another poster it's not clear why you actually need this on a router.
Those are link-local addresses (fe80::/10) and doesn't participate in the Internet.
The tcpdump you got is a router advertisement from your router to the "link" (using the link-local multicast address ff02::1) to enable other devices in your network to configure using SLAAC. It is not Internet traffic.
My router runs NTP, DNS and connects to GitHub to download subscriptions for Adguard Home.
Other APs within my house also connects to NTP servers to fetch their time.
I don't want the EUI-64 IPs used by my router and other APs for their outbound connections enabling others (eg. GitHub, ntp pool) to track other devices within my network.
Are any of these providers doing any such tracking? Are you connecting to the same providers from other devices in your network (other than the router and AP)?
You can solve the AP 'issue' by enabling the NTP server on the main router and then using that as the AP's time source. And if your ISP is doing ipv6 properly your router's WAN IP shouldn't actually be in the same subnet as your LAN allocation.
They actually do. You may need to re-review the RFCs. You mentioned the RA - so I'm not sure why you're under that impression.
I don't see the behavior you describe.
That's common sense, as the prefix is the same. Nonetheless, I'm not seeing this.
on reboot
(the 4213 is another RFC4213 interface below it - I just used it as a reference to take a screenshot in the same position - my IPs come from WAN6 - the default DHCPv6 client)
Not an EUI-64 address.
In this case IP is random. Don't confuse "random" and the RFC "privacy addresses".
In the case of GitHub and their CDNs, other devices sure do.
I don't know if they do that tracking, but it is certainly possible as evident by the paper linked in the first post, which is why I want to minimize such metadata from leaving the network.
That's what I just did, thanks for the tip. Still it would be nice to have privacy addresses in order to catch unknown leaks (this is why this post was originally in "Feature Request").
Routers must not forward any packets with Link-Local source or destination addresses to other links.
What I meant is that you will never see fe80::/10 addresses on the Internet, so it doesn't matter if they are EUI-64 or not. I think you might have misunderstood what I said to be that they are never used. They are, just not as addresses on the Internet.
That's not a given, my ISP actually rotates the prefix. The linked paper shows that the prefix rotation can be tracked if a previously observed EUI-64 address can be observed in the new prefix after the change.
It could be that your ISP is handing out IPv6 via DHCPv6, unlike mine which only hands out the PD and the main IP is obtained via SLAAC.
I was referring to RA and you ISP router knowing it - but OK, if you insist - I apologize for semantic differences.
The ISP will, but I understand and digress.
And if it rotates and you have an EUI-64?
(i.e. you're tracked)
That seems to be the point of the paper you posted - maybe I misunderstand.
DHCPv6 must be enabled to get a PD
The address is SLAAC on the interface pictured
I'm also able to test this downstream on devices I control
I'm not sure why you're insisting it doesn't work, but OK, cool. I'll setup a SLAAC instance again and test/screenshot if/when I have the time.
Perhaps you could share your configs?
Did you add the stable secret?
Did you add random to the interface config?
Was this in UCI?
EDIT:
Also, I received an IPv6 IP via SLAAC on wan6 when my ISP had enabled IPv6, and I still have DHCPv6 firewalled.
(Since the default is what you describe; but with proper configs I don't see you issue) Can you provide steps/config so I can attempt to reproduce your problem?
Yes, I can get a random IP on the router this way (and only the router), but as you have said, it's not the same as a privacy address (ie. it will never get rotated automatically, though it doesn't matter as much as my ISP is rotating the prefix, which should cause the random part to change too, but I will have to read netifd source to confirm this).
The only thing it ever does is to copy the suffix of your link-local address (your fe80::xxxx:xxxx:xxxx:xxxx/64) and paste it after the received prefix. You can make it so that you get a random link-local (via stable_secret, or better addr_gen_mode=3 which generates this value for you), which in turn will generate a "random" SLAAC address (it's doesn't even met RFC 7217 as the suffix won't change with the prefix unless the interface is recreated). But again, this is a random address and not a privacy address.
But yes, you can use this trick to avoid EUI-64 addresses via SLAAC, but you can not use this to get IPv6 privacy addresses, which is what I have been asking for in this Feature Request.
I'm confused by this statement - it was not my intent to convey what you seem to have interpreted.
Rotate what automatically?
I'm lost at what you want - as I get a new - random IP on each reboot.
You then proceeded to mention prefix rotation (i.e. has nothing to do with the OpenWrt)?
I think you're trying to say you want the IPs on a router to change while on/running. Since that doesn't make sense [on a router] to me for multiple reasons - and since your request now seems completely unclear to me, I'll move the thread back for you.
If I understand you correctly - I think I agree with @NPeca75.
I am behind an ipv4-only network and can not test, but I think my ISP gives me an IPv6/64 for my router and a /56 prefix for my network. I was under the impression that the router would use its /64 address (which is not part of the prefix)... so an attacker would need to sit close enough to see both prefixed network traffic and packets from the router and be able to correlate these.
Honestly the likely entity to do that is my ISP, and they already know this since they are supplying the address/prefix in the first place....
Sidenote, once one actually wants to use the internet fully (that is not only for consumption) one needs to set-up a server which typically means a somewhat stable address... Sure that server can still use privacy extension addresses for self-initiated outgoing addresses, but if the stable addresses are used over the internet, correlation is possible...
He seems to want that his router auto generates (and cycles through) "ephemeral" interface identifiers like some/many client OSs do, that way the router's outgoing connections will not easily "leak" IPv6 addresses that could be uses as stable identifiers for his prefix...
As I said above, I think my router uses a /64 that is not out of the prefix, so I am not sure that this threat does not actually require to observe the stable router address and traffic with the current prefix often enough to correlate these with each other...
Sidenote: RIPE actually tries to argue for stable prefixes (with IMHO decent rationale), at which point a home network can be identified via its prefix anyway....
Really if you need privacy, use TOR
That said, I am not against allowing privacy extensions for the router's own interfaces, I just do not think that this solves as much of the trackability-issue as one intuitively would think.
I can only see this working in a case where the OpenWrt is not being used as a router. While it shouldn't be an issue though, I don't see the OP's privacy concerns.
Since no EUI-64 address is used, the privacy problem I understood the OP to describe is solved by random interface addressing. So this is just merely a feature request for the ephemeral IP rotation by adding "privacy addresses".
I'm rusty on the RFC, but I'm nearly certain there's a reason this is not done on routers (and it may be that it applies to servers/services)- I just can't recall at this time (there's other threads on this).
I would guess that for "real" routers being able to access them from the outside is somewhat required... (even though the control plane would not need to use internet accessible addresses, these addresses would need to be static or at least fully predictable).
OpenWrt acts both as a router (when it forwards traffic between networks), and a host (for example when it sends DNS requests to the internet, and when it downloads packages with opkg from the internet).
I can't see any reason why OpenWrt can't be modified to use temporary SLAAC addresses (with privacy extensions) when acting as a host. I think it can be implemented using the Virtual routing and forwarding (VRF).
I tested it on one of my routers and it worked with ping anyway. (It seems dnsmasq and opkg can't bind to an interface which is required to select the VRF.)
I used the following script to create veth0 and veth1, and then configured veth0 as a new static interface, and verh1 as a new manual interface. (Veth0 could instead be bridged to the lan, or the veth interfaces could be replaced with a macvlan in case the ISP allows SLAAC.)
ip link add vrf-host type vrf table 20
ip llink set dev vrf-host up
ip route add table 20 unreachable default metric 4278198272
ip link add veth0 type veth peer name veth1
ip link set dev veth1 master vrf-host
echo 2 > /proc/sys/net/ipv6/conf/veth1/accept_ra
echo 1 > /proc/sys/net/ipv6/conf/veth1/accept_ra_from_local
echo 2 > /proc/sys/net/ipv6/conf/veth1/use_tempaddr
PBR can also be used (somewhat analogous). But - that sounds quite complex for a consumer router.
Sure, where's the "acting as a host button" (i.e. how does one configure that )?
As you quoted - I definitely agree with you, I just don't see the feasibility for a niche use case.
I also don't see the privacy issue described if using the random prefix. I agree the poster simply wants Privacy Extensions, but it's clear the exploit described in the paper is mitigated with random addresses on the interface.
This is just a fresh request for an additional feature at this juncture - nothing security related (aside from a desire to rotate prefixes more often).
I wonder what happens e.g. to a Wireguard interface whose IP changes constantly, and other kinds of services like replies to DNS inquires, etc. It'll be cool to test.
With privacy extensions a host will hold on to IPv6 addresses it used and will service open connections continuously with that address, only it will initiate new connections with the current privacy extension address. So if you start an outgoing wireguard session from a hoist using privacy extensions that IPv6 address will be in use as long as that wireguard session last (resulting in potentially trackable persistence*). If a host needs to act as reachable wireguard server it needs to run on a known static or predictable IPv6 address...
*) This "trackability" is inherent in networking/communication, to get information back there needs to be known return path/address, so all we can do is make tracking a bit harder making these revealed return addresses be used only for short durations... which arguably is a quantitative issue anyway, I think we all can agree that using persistent MAC addresses as IID is not ideal (trackable over space and time) AND non-trackable is impossible, so the question comes down to where in the continuum one is "happy" which walks and quacks like a policy question, and these often have multiple answers...
)?