Stop relays publishing descriptors containing NoListen IPv6 ORPorts

Trac:
Parent Ticket: #24403 (moved)

added component::core tor/tor ipv6 milestone::Tor: unspecified needs-proposal-or-tor-dev-email parent::24403 priority::medium reachability severity::normal status::new tor-relay type::defect version::tor unspecified labels

Trac:
Summary: Enforce emutually exclusive logic for IPv6 ORPort flags to Enforce mutually exclusive logic for IPv6 ORPort flags

Actually I am not sure if the correct action here is to just correct the descriptor and continue with a warning in logs (in cases of dual stack relays where v4 is correctly set-up, but just v6 is not configured properly) or better terminate and exit until everything is either corrected, either removed entirely from the config.

Thinking on the really long term when IPv6 will take over or at least be mandatory in Tor, so we don't have to go back to this. After all, it's broken config / setup in terms of relay ports, it's not bad to exit on mistakes at such important config parameters.

Let's see what others think about it.

Replying to s7r:

...

This is one rare and strange setup of using IPv6 in a way it is not intended, but we should still make sure that:

if ORPort [IPv6:address::x]:port NoListen was set in torrc, and there is no following ORPort [IPv6:address::y]:port NoAdvertise or [::]:port NoAdvertise (as in use all available IPv6 addresses) is set, warn in the log and do not build the descriptor using the NoListen address, since the daemon is not listening on any address from the v6 class.

Here's another way of expressing that rule:

on a relay, for each IP family, the number of configured advertised addresses must be less than or equal to the number of configured listening addresses

This will require a tor man page change. The spec only talks about advertised addresses, so there's no need for a spec change.

check if the logic is applied for IPv4 also, even it's impossible to experience this in IPv4 since UnreachableIPv4 doesn't exist and can't possibly exist.

UnreachableIPv4 does exist in the current Tor network. It's called "not Running", and it means that the relay is not in the consensus.

Here are our current address rules:

descriptors can have multiple advertised IPv4 and IPv6 addresses

but our tor implementation only puts the first configured address from each family in the descriptor

there must be at least one advertised IPv4 addresses in a descriptor
authorities take the first advertised address from each IP family on each relay, and test it for reachability
if all of the tested addresses from a relay are reachable, authorities put the tested addresses in the consensus

Rule 2 may change to require dual-stack or IPv6-only in the far future. So we shouldn't lock in IPv4 in any other rule.

Otherwise we fill the descriptor with useless data and also have the directory authorities chase green horses.

You're right: there's no point in advertising two addresses that go to the same port. If we do want a configuration like that, the appropriate way to do it is with a (null) pluggable transport.

I think we have this since forever, but not marking this as a backport given the rare cases when it can occur and the state of current IPv6 adoption.

I agree, no backport on this one, it's too risky.

Replying to s7r:

Actually I am not sure if the correct action here is to just correct the descriptor and continue with a warning in logs (in cases of dual stack relays where v4 is correctly set-up, but just v6 is not configured properly) or better terminate and exit until everything is either corrected, either removed entirely from the config.

Thinking on the really long term when IPv6 will take over or at least be mandatory in Tor, so we don't have to go back to this. After all, it's broken config / setup in terms of relay ports, it's not bad to exit on mistakes at such important config parameters.

Our general policy with address config errors is to break as early and as severely as possible.

We used to try to cope by gracefully degrading to IPv4. But relay operators asked us to send a stronger signal, so they know when their IPv6 configs are broken.

I'm not sure there is a bug here. As per https://lists.torproject.org/pipermail/tor-relays/2019-February/016994.html it seems this setup is actually working.

I fully agree that IPv6 is intended to provide end to end connectivity, but in practice there are a number of ways (and reasons) for network traffic to move from IPv4 to IPv6 and vice-versa. This setup is one of just them. While this case runs counter to what IPv6 intends to achieve, it does work... Moreover, a relay in an IPv6 only network that is through router tricks still reachable on a IPv4 address seems a sensible case to me.

The assumption here seems to be that IPv4 and IPv6 are strictly separate worlds, but they are not. Therefore I'd be inclined to say pretty much anything advertised could be valid because pretty much anything can be made to work at network level and it's impossible for Tor to know about that. Isn't that why connectivity testing is done?

I'm not sufficiently into the internals of Tor to know if anything there may prevent any of this from working. But in that case I might even argue that's actually a bug.

(A warning like 'You are advertising IPv_X_ but not listening there' would still be useful for troubleshooting.)

Trac:
Username: AVee

Replying to AVee:

I'm not sure there is a bug here. As per https://lists.torproject.org/pipermail/tor-relays/2019-February/016994.html it seems this setup is actually working.

Negative. This rare setup is working because the IPv6 address is assigned to a HAProxy daemon, which translates it to IPv4 and forwards it to the IPv4 address behind NAT, where is also the ORPort 0.0.0.0 listening.

This is of course transparent to the directory authorities since HAProxy handles the conversion from v6 to v4 they can't know that the relay there is not actually listening on a v6 address.

But this does not mean the bug doesn't exist. It's possible with current ticket not fixed to only state a v6 address to advertise, and NONE to listen, which is not good.

And the action should be to exit as loud and as fast as possible as teor says.

I fully agree that IPv6 is intended to provide end to end connectivity, but in practice there are a number of ways (and reasons) for network traffic to move from IPv4 to IPv6 and vice-versa. This setup is one of just them. While this case runs counter to what IPv6 intends to achieve, it does work... Moreover, a relay in an IPv6 only network that is through router tricks still reachable on a IPv4 address seems a sensible case to me.

The assumption here seems to be that IPv4 and IPv6 are strictly separate worlds, but they are not. Therefore I'd be inclined to say pretty much anything advertised could be valid because pretty much anything can be made to work at network level and it's impossible for Tor to know about that. Isn't that why connectivity testing is done?

They are separate worlds actually, totally separate. But there were some solutions engineered to make transition from v4 easier and faster and to allow existent v4 network to adopt v6 without rebuilding from 0.

Again, of course whatever relay operators choose to do at their network level does not concern us, as long as the relay is reachable and can be used. Like in this case, the bug is not that this particular operator chose to use HAProxy to translate v6 traffic to v4 and forward it to the NAT IPv4 address - regardless this is not recommended - this does not affect Tor.

The bug is that you can build a descriptor with an address from a class (v6 class) when you are not listening on any address of that class, at all. This opens the door for many mistaken setups, and also fills descriptors with useless data that make directory authorities chase green horses.

I'm not sufficiently into the internals of Tor to know if anything there may prevent any of this from working. But in that case I might even argue that's actually a bug.

(A warning like 'You are advertising IPv_X_ but not listening there' would still be useful for troubleshooting.)

As stated above, it is preferred to exit as fast as possible on such misconfigurations. There are such warnings for mismatches when you listen on something and advertise something else, but such a warning cannot work in this ticket because it breaks logic:

The correct message here should be "You are advertising IPv6 address xxxx:xxxx but you are not listening on ANY IPv6 address" -- this is irrational because this shouldn't be possible in the first place.

In this particular case, if only ORPort 0.0.0.0:9050 was set, and it was just HAProxy that listened on the IPv6 address and forwarded to the NAT IPv4 address ORPort, while indeed strange and not recommended, would be totally transparent to Tor / directory authorities and would of course not be a bug. But it wouldn't be possible because there would be no IPv6 address in the descriptor. In this setup, the relay is only v4 reachable actually, but HAProxy is reachable also on IPv6 and converts traffic to IPv4 and forwards to the IPv4 ORPort.

Since you can have only a line: ORPort [ipv6:address]:9050 NoListen and no following IPv6 ORPort with NoAdvertise, this is a bug as in config parameters are not properly sanitized.

Hope this clarifies what this ticket is about.

The right solution to achieve such tunneled / encapsulated setups is to have another torrc parameter Advertise6to4OrportAddress <IPv6 address>:<port> that will tell Tor to include this IPv6 address in the descriptor without binding to any IPv6 address because traffic to that IPv6 address : port is translated to v4 and forwarded to the IPv4 ORPort. At least this is the way it would make sense to me, but more opinions required here.

Do you agree on this? Firstly, this example shows a relay which is functioning correctly on both IPv6 and IPv4. Secondly, if this change is implemented this relay would not start up anymore.

Right there is my main issue with this, it simply isn't true this config is always invalid. The change as proposed would break a currently correctly functioning relay. I don't think that's a good thing to do. Also, in my mind at least, it pretty clear what's going on in this config. If you use NoListen you need to make sure traffic to that ip/address reaches your relay in some way. Tor should not have a opinion on the how, as long as it works. And that's what the reachability check is for.

If you really want to go further there should still be a way to get a setup like this running anyway. The Advertise6to4OrportAddress config parameter would work for this specific case. A more generic solution would be a YesIHaveSeenTheConfigWarnings flag. You could have a category of "this is probably wrong, are you really sure" warnings on which Tor fails to start until the flag is set. That way errors are still caught early (and loudly), but 'weird' setups can still be made to work. That mechanism could then be applied to any common source of config errors...

Trac:
Username: AVee

I can see a good argument for reducing the size of the consensus.

The argument for making connections direct is not very strong, because tor already supports NAT using the NoListen/NoAdvertise flags.

I can also see a good argument for allowing operators to configure their relays the way that they want:

a relay in an IPv6 only network that is through router tricks still reachable on a IPv4 address seems a sensible case to me.

The argument for using a pluggable transport instead of an IPv6 redirect is not very strong, because that needs extra client configuration.

Let's take a step back:

Here are our goals:

support IPv4 and IPv6
encourage more IPv6 relays
make the votes efficient for authorities to create
make the consensus efficient for clients to download
make relay connections efficient
make Tor easy to maintain

Allowing an IPv4 and an IPv6 advertised address to redirect to the same underlying port:

makes 1 and 2 better for a few relays
makes 3, 4, and 5 slightly worse, all over the network

Rejecting this rare case:

makes 1 and 2 worse for a few relays
makes 3, 4, and 5 slightly better, all over the network
makes 6 a tiny bit worse, because it requires a little bit of extra code and documentation

Adding a special flag or option for this rare case:

makes 1 and 2 better for a few relays
makes 3, 4, and 5 slightly worse, all over the network
makes 6 worse all the time, because extra flags and options need code and tests and documentation

Tor uses a proposals process to make design decisions like this. Here is our proposals process: https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt

A good proposal will talk about the alternative designs, and give reasons why each design would be better or worse for tor users, relay operators, and the tor network.

Trac:
Keywords: N/A deleted, needs-proposal added

Replying to teor:

Here are our goals:

support IPv4 and IPv6

encourage more IPv6 relays

make the votes efficient for authorities to create

make the consensus efficient for clients to download

make relay connections efficient

make Tor easy to maintain

Allowing an IPv4 and an IPv6 advertised address to redirect to the same underlying port:

makes 1 and 2 better for a few relays

makes 3, 4, and 5 slightly worse, all over the network

Can you explain to me how this makes 3 and 4 worse, compared to the same relay running a normal dual stack? Unless i'm missing something here about the internals of Tor (which could well be the case) any progress on 2 will have a negative impact on 3 and 4.

Or are you just referring to the impact of potential misconfigurations?

As for 5, setups like this add extra handling on the network level and will introduce some latency. However we can't know the reasons for operators to do this, it might still be better then the alternatives they have. You could take a stand here and say 'We only want proper no tricks IPv6', basically saying 5 is more important then 2. I'm inclined to say that some impact on 5 is fine if it helps 2, also because I'm assuming relay operator know to keep the impact on 5 within reasonable limits.

Rejecting this rare case:

makes 1 and 2 worse for a few relays

makes 3, 4, and 5 slightly better, all over the network

makes 6 a tiny bit worse, because it requires a little bit of extra code and documentation

The way I see it this is the original case being made by s7r, which boils down to this: A. There is a high probability of this specific configuration being incorrect. B. The impact of such an incorrect configuration (on 3 and 4) is high enough to block it altogether.

I'm skeptical about A being true, but that's just gut feeling. I simply don't expect operators to use NoListen by mistake. (Note that there wasn't a misconfiguration in this case, just confusion because it seems to take days to test IPv6 reachability.)

If there is a way to quantify how often this happens that would be really useful. (Although I suspect we can't tell the difference between faulty IPv6 connectivity, firewall issues and misconfigurations like this.)

Regardless of me being skeptic here, if we fix A we fix the root cause. So something that makes it highly unlikely this is done by accident would be a better fix imho. This is why I think a loud but overridable warning would be a good solution.

But that leads to a bigger picture, anything that makes it easier to detect common misconfigurations as early and loudly as possible would be useful. Would it be useful to discuss more generic solutions to this in a separate issue/proposal? To reduce the impact on 6 it might even be possible to come up with something which doesn't impact the main codebase at all. Would a proposal in that direction be useful?

Tor uses a proposals process to make design decisions like this. Here is our proposals process: https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt

I've skimmed it, if this goes any further I'll make sure I'll properly read it ;-)

Trac:
Username: AVee

Replying to teor:

Allowing an IPv4 and an IPv6 advertised address to redirect to the same underlying port:

makes 1 and 2 better for a few relays

makes 3, 4, and 5 slightly worse, all over the network

Rejecting this rare case:

makes 1 and 2 worse for a few relays

makes 3, 4, and 5 slightly better, all over the network

makes 6 a tiny bit worse, because it requires a little bit of extra code and documentation

I would also reject this case (redirecting IPv6 to IPv4).

It adds unnecessary complexity to the Tor code and network setup to be worth it. (At least in my opinion) the costs would be more than the benefits.

Why not just listen on IPv6 as well instead of giving "IPv6" which is really a tunneled IPv4 socket?

Replying to AVee:

Can you explain to me how this makes 3 and 4 worse, compared to the same relay running a normal dual stack? Unless i'm missing something here about the internals of Tor (which could well be the case) any progress on 2 will have a negative impact on 3 and 4.

Not teor, but I believe this would:

Add overhead to IPv6 connections as they would be routed to IPv4. On top of this, you won't really have true IPv6 sockets as much as IPv4 sockets routed to an IPv6 address.
Possibly make the consensus harder to calculate with a non-standard configuration.

Replying to neel:

Replying to AVee:

Add overhead to IPv6 connections as they would be routed to IPv4. On top of this, you won't really have true IPv6 sockets as much as IPv4 sockets routed to an IPv6 address. Agreed, although the actual impact of this overhead depends on a lot of factors. If done correctly the impact can be minimal. Note that the same is true for IPv4 portforwarding, which we all accept as a valid way of making a node reachable.

Possibly make the consensus harder to calculate with a non-standard configuration. I assume that's not the case. For the outside world it doesn't work or look any different, so as such it should not have any impact outside of the configuration of the node itself. Again, this is not different from IPv4 portforwarding.

Trac:
Username: AVee

Not really. IPv4 is scarce, limited resources. NAT is a hack to get around this, and it's quite useful because THERE IS NO OTHER WAY to have multiple boxes if you have just one public IPv4, as most providers default to.

In IPv6 however, this is not the case. In addition that this is not the case, it is also NOT RECOMMENDED by any RFC to do this. With what you are saying, just because you think it's ok "as long as it works and the relay is willing to do it" you contradict all the RFCs.

Nobody is happy about NAT. In fact, everyone indicates to avoid it. That is why IPv6 came along. NAT is just a necessary evil, a hack that was made so things can go on. Obviously we don't have a choice in NOT supporting it. But we do have a choice for IPv6, and we should. Have you ever questioned why IPv6 does not support NAT? Not because it was hard to implement of course, but because it's evil and is best to be avoided. There's nothing that we can do for the legacy IPv4 internet, but let's not turn IPv6 into the same.

Why would you want to pretend to listen on an IPv6 address if you have no open socket for it? It just doesn't make any sense. How is that better than just listening on IPv4? All this ticket recommends is, if you are willing to set an IPv6 NoListen address, also set a NoAdvertise one, if you're willing to redirect and tunnel that somehow it's still OK but at least don't advertise an address class if you have no listening socket for it. Basically follow the industry standard RFCs and recommendation + prevent users to make accidental mistakes and fill the consensus with garbage. Right now I configure an IPv6 NoListen ORPort and that gets filled in the consensus, and I spend resources of directory authorities trying to test if it is reachable and also eat up even more space by having to be assigned with an additional UnreachableIPv6 flag. All this because something we say in the manual (mutually exclusive flags for torrc options) are not properly sanitized at start-up.

teor I'm not in any way questioning your opinion and expertise in implementing things, but can you please revise the keywords of this ticket and confirm if it's really needs-proposal?

I mean, we basically want to fix a misbehaving thing. Some thing that we say in the manual should be is not enforced at start-up, that's all. And as per my comment above, I don't think this should be up for debate. There's not enough data to build a proposal or to analyze it. I mean, how is it useful to have only an IPv4 address but advertise two sockets and use strange ways to make them both reachable, when IPv6 was brought to enforce end-to-end connectivity and eliminate the need for unnecessary evils like NAT.

Replying to s7r:

teor I'm not in any way questioning your opinion and expertise in implementing things,

Thanks, but you're allowed to question my opinions and expertise. I make mistakes, and it's better than we pick them up early.

but can you please revise the keywords of this ticket and confirm if it's really needs-proposal?

I don't know how Tor should behave when it's configured to advertise an address, but there's no corresponding listening address. I think there are some good arguments for the current behaviour, and for the behaviour you're suggesting. I don't think I have enough information to make a good decision here.

So I want to know what other Tor developers think. Some of them have more experience with IPv6 and routing.

That's why I want someone to email tor-dev@lists.torproject.org with a summary of the current behaviour, the issues with that behaviour, and the proposed fix.

If you'd like, you can do that in the proposal format - proposals can be short: https://gitweb.torproject.org/torspec.git/tree/proposals/282-remove-named-from-consensus.txt

Or you can write a freeform email.

But we can't make progress on this issue until there is developer consensus.

Trac:
Keywords: needs-proposal deleted, needs-proposal-or-tor-dev-email added

Replying to s7r:

We're running in circles here. You don't need to explain IPv6 to me, I've had native IPv6 since 2011 and tunnels before that. You don't need to argue the case that IPv6 is intended to bring full end-to-end connectivity back, I agree and would love to see that happen.

In IPv6 however, this is not the case. In addition that this is not the case, it is also NOT RECOMMENDED by any RFC to do this. With what you are saying, just because you think it's ok "as long as it works and the relay is willing to do it" you contradict all the RFCs.

Let me quote an RFC then: 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. https://www.ietf.org/rfc/rfc2119.txt

We should stick to that. We must not make it impossible to do this as 'there may exist valid reasons in particular circumstances' to do this. And even if you feel no valid reason could ever exist, Tor is not the IPv6 police so it still isn't up to us to enforce anything there.

The proof of the pudding is in the eating. We have one example of this config. It may not be optimal, it may be utterly different from how I would have done it. But it worked, therefore it is valid, therefore it should be allowed.

(On a more philosophical note, I feel it would be counter productive as well. You add extra barriers to people trying to get a Tor relay running as well as for people trying to get experience with IPv6. Allowing them to do it in a sub-optimal way and learn from that is far more useful then trying to force them to get it right the first time around.)

Why would you want to pretend to listen on an IPv6 address if you have no open socket for it?

The Tor man page explains that nicely (emphasis mine): NoListen: By default, we bind to a port and tell our users about it. If NoListen is specified, we don't bind, but advertise anyway. This can be useful if something else (for example, a firewall's port forwarding configuration) is causing connections to reach us.

In this case HAProxy was the 'something else'...

All this ticket recommends is, if you are willing to set an IPv6 NoListen address, also set a NoAdvertise one, if you're willing to redirect and tunnel that somehow it's still OK but at least don't advertise an address class if you have no listening socket for it.

So the if someone uses HAProxy (or anything else) to redirect IPv6 traffic to IPv4 he should configure his node to still listen on a IPv6 port even though it will never see any traffic?

All this because something we say in the manual (mutually exclusive flags for torrc options) are not properly sanitized at start-up.

I guess you refer to this phrase in the man page: For obvious reasons, NoAdvertise and NoListen are mutually exclusive, ...

That only states a ORPort line that sets NoAdvertise cannot also set NoListen (and vice-versa). This rule was not violated in the config in question.

Trac:
Username: AVee

I'll summarize my take on this.

Assuming as fact:

Tor treats all incoming data the same independently of the socket it arrived on, so nothing breaks if data which was originally send to IPv6 arrives in Tor on an IPv4 socket (or vice-versa).
The load on consensus data, authorities etc. caused by an advertised address is the same for any functioning address independently of how the relay operator sets things up. I.e. forwarding IPv6 to IPv4 does not change descriptors, reachability checks etc.

Assuming as valid goals for Tor:

Any properly functioning relay added to the network is desirable, regardless of how the operator made it work. Tor does not enforce any opinion on network (or OS, or hardware) choices.
Being able to fully separate where Tor is listening and what it advertises is desirable because it gives relay operators maximum flexibility to set up their networking according to their needs.

Therefore:

It's OK to advertise an address family even when the node is not listening at that family because it can be made reachable in other ways.
The man page does not mention anything which would suggest otherwise, so there is no bug there.
The description of the NoListen flag clearly indicates reachability is expected to be achieved through other means, so there's no need for improvement there.
There is no indication this is a common source of configuration errors, so there is no need to take drastic measures here because it causes excessive load somewhere else.

That said, there are separate things which may be worth looking into (as separate issues):

The connectivity check for IPv6 seems to take several days, giving nodes a UnreachableIpv6 flag in the mean time. This causes operators to start looking for errors in their setup even though it is correct. It even causes operators to give up on IPv6 altogether.
If there specific configurations which are often causing invalid addresses to be advertised it could be worth while putting effort into preventing that. But that should (imho) be a more generic solution for all common errors, not something specific to this case.

Trac:
Username: AVee

You are suggesting behavior that does not have any logic, is confusing for operators and it also turns this ticket into a state that is hard to follow up. Don't you see the logical fracture with advertising a v6 socket but not listening on one? Why not just listen to v4, since that's your only open socket?

In this case I would like to have only a v6 socket open, and have only one NoListen IPv4 ORPort entry to be advertised. And I will use HaProxy to listen on that IPv4 addr:port and redirect to my IPv6 address. So I will be having in my descriptor both IPv4 (which is mandatory) and IPv6, and only listen on one IPv6 socket. You suggest this should be possible, right?

Otherwise why would we have different behavior for same thing, but only different versions?

Replying to s7r:

You are suggesting behavior that does not have any logic, I'm suggesting not to change the existing behavior. You are suggesting a change which makes a specific configuration illegal. Even though there is at least one working relay using that config. Can you answer this: Do you think it's a good idea to add restrictions which break currently running nodes?

is confusing for operators You'd need to prove that first. It isn't confusing for me. It also wasn't for the Charly Ghislain who, despite the complicated setup, got his config correct without issues (what was confusing for him was the fact that it took days before he got the IPv6Reachable flag). It seems to be confusing for you, but that cannot be a reason to disallow other to do this. Could you also answer this: Do you have any prove this is a common source of configuration errors?

Don't you see the logical fracture with advertising a v6 socket but not listening on one? Yes, I do. Which is why I know I need to do something somewhere in my network to make sure the advertised address actually works.

Why not just listen to v4, since that's your only open socket? Because I want my node to be reachable over IPv6 as well, as teor stated (goal 2) we want to "encourage more IPv6 relays".

In this case I would like to have only a v6 socket open, and have only one NoListen IPv4 ORPort entry to be advertised. And I will use HaProxy to listen on that IPv4 addr:port and redirect to my IPv6 address. So I will be having in my descriptor both IPv4 (which is mandatory) and IPv6, and only listen on one IPv6 socket. You suggest this should be possible, right? Yes that should absolutely be possible as well. Why not?

Otherwise why would we have different behavior for same thing, but only different versions? If that currently isn't allowed that would indeed be inconsistent. But then the rule should be: If the node does not have at least one listening ORPort it is not allowed to advertise any ORPorts, because the node cannot possibly be reachable. (I also expect IPv6 only nodes to become possible at some point.)

Trac:
Username: AVee

Two reminders:

A mailing list is a better place for this kind of discussion
I won't take any action on this ticket until there is consensus on a mailing list

Fixing #5940 (moved) should also fix this issue, we'll work out the details in an upcoming proposal.

Trac:
Summary: Enforce mutually exclusive logic for IPv6 ORPort flags to Stop relays publishing descriptors containing NoListen IPv6 ORPorts
Parent: N/A to #5940 (moved)

Apologies, I had the wrong proposal. IPv6 ORPort reachability checks should prevent this situation from happening.

Trac:
Parent: #5940 (moved) to #24404 (moved)

Trac:
Parent: #24404 (moved) to #24403 (moved)

moved to tpo/core/tor#29570 (closed)

Stop relays publishing descriptors containing NoListen IPv6 ORPorts

Child items 0

Activity