Hi s7r, Thanks for bringing up IPv6 address privacy extensions. > On 30 Jan 2020, at 02:19, s7r <s7r@xxxxxxxxxx> 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-28c992d72bedaa9378a4f3627afb8694R816 (I still have to revise proposal 312 based on Nick's review, I hope to do that today or tomorrow.) T
Attachment:
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev