Hi s7r,
Thanks for bringing up IPv6 address privacy extensions.
On 30 Jan 2020, at 02:19, s7r s7r@sky-ip.org wrote:
There is another RFC (older), that is in use by Debian apparently: RFC3041. https://tools.ietf.org/rfc/rfc3041.txt
From: https://manpages.debian.org/buster/iproute2/ip-address.8.en.html see `mngtmpaddr`
RFC4941 is newer and with some improvements, however it does not mention its purpose is to update / deprecate RFC3041. Actually it mentions the differences / improvements.
Anyway, the point still fully stands, I just thought both RFCs should be mentioned. Bottom line still is temporary (expiring) but otherwise public and reachable IPv6 addresses in relay descriptor.
s7r wrote:
By briefly reviewing I've noticed something important is missing that should be a part of this proposal.
I am not sure under which section it should go under. I guess `3.2.2. Use the Advertised ORPort IPv4 and IPv6 Addresses`, or maybe it's important enough that we should make its own section.
In IPv6, besides publicly routable and non-publicly routable addresses (fe80:// etc.) which are documented in the proposal, we have temporary IPv6 addresses coming from Privacy extensions or RFC4941 IPv6 addresses.
https://tools.ietf.org/rfc/rfc4941.txt
These addresses are publicly routable, they can appear as reachable from the directory authorities or from directory data fetches, but they have limited lifetime and change over time. I am not sure if one such address becomes deprecated if already in use (say by Tor), as the RFC states MAY _if not in use by applications or upper layers_:
"As an optional optimization, an implementation MAY remove a deprecated temporary address that is not in use by applications or upper layers as detailed in Section 6."
But since this is implementation dependent, we cannot be sure about the behavior across different platforms that relays might run on.
It is up to the operating system if such addresses are used or not. In Debian they are disabled by default net.ipv6.conf.eth0.use_tempaddr=0 (unless some desktop packages that use network manager with different settings change it). In Windows (at least Windows 10) apparently they are enabled by default.
The question is, do we want such addresses in relay descriptors? I think such addresses will behave similar to dynamic IPv4 addresses, or even worse since these ones really change when they want, not just when we disconnect and reconnect the network interface. So maybe Tor should detect such behavior and log an error or something?
Actually I'll setup a vm this weekend and give it a native, static /64 IPv6 prefix, enable privacy extension to use temporary addresses and spin up a Tor process on it. Then disconnect the internet a couple of times and see how it behaves, how often it changes.
What do you think?
I read RFCs 4941 and 3041, looked at the tor directory spec, and did some analysis: * tor clients get new relay addresses within 4.5 hours * IPv6 privacy extensions rotate addresses every day (by default) * IPv6 privacy extensions remove old addresses after a week (by default)
(And applications have to opt-in to IPv6 privacy extensions addresses, by default, according to the RFC.)
Therefore, I don't think tor relays or clients will be affected by relays using IPv6 privacy extensions.
See my detailed analysis here: https://github.com/torproject/torspec/pull/105/files#diff-28c992d72bedaa9378...
(I still have to revise proposal 312 based on Nick's review, I hope to do that today or tomorrow.)
T