Opened 20 months ago

Closed 9 months ago

#29725 closed defect (wontfix)

Reset relay bandwidths when their IPv6 address changes

Reported by: juga Owned by:
Priority: Medium Milestone: sbws: 1.2.x-final
Component: Core Tor/sbws Version: sbws: 1.0.5
Severity: Normal Keywords: scanner
Cc: juga Actual Points:
Parent ID: #29954 Points: 1
Reviewer: Sponsor:

Description

We implemented this for IPv4, but not IPv6.

From https://github.com/torproject/sbws/issues/202:

on Jun 18, 2018

Split off #154.

When IPv6 is more than a few percent of relay load, sbws should reset relay bandwidths on IPv6 address changes as well. (Tor doesn't measure IPv6 entry bandwidth separately, but we want to.)

Here's what we'd need to do:

    Add a relay or_addresses attribute
    Add or_addresses to result
    Check any IPv6 addresses in or_addresses to see if they've changed

We should also store IPv6, since currently sbws is only storing IPv4 addresses.

Child Tickets

Change History (6)

comment:1 Changed 19 months ago by juga

Keywords: scanner added
Parent ID: #29954

comment:2 Changed 17 months ago by teor

Milestone: sbws: unspecifiedsbws: 1.2.x-final

It would be nice to make these changes in sbws 1.2

comment:3 Changed 9 months ago by teor

Actually, I don't think we should make this change for IPv6, because it will penalise relays that use IPv6 address privacy extensions.

IPv6 address privacy extensions make some machines change their IPv6 address regularly. (By default, once per day, with old addresses lasting one week). The rest of the tor network copes well with address changes at that rate. (See https://tools.ietf.org/html/rfc4941#section-3.5 .)

But if we make this change on bandwidth authorities, they will reset the bandwidth of relays that use IPv6 address privacy extensions, every day. Since sbws only measures the whole network once per day, any relay that uses IPv6 address privacy extensions won't get much consensus weight.

If we don't make this change, then when relays change networks, sbws will take a few days to measure their new bandwidth. That's ok. Network changes happen a lot less often than IPv6 privacy extensions address changes.

If sbws can ever scan the network once per hour, we could think about implementing this change.

What do you think, juga? Should we close this ticket?

comment:4 Changed 9 months ago by teor

(If we do close this ticket, we should add a comment to sbws, explaining why we don't reset bandwidths when IPv6 addresses change.)

comment:5 in reply to:  3 ; Changed 9 months ago by juga

Replying to teor:

Actually, I don't think we should make this change for IPv6, because it will penalise relays that use IPv6 address privacy extensions.

sorry, i'm not familiar with IPv6. You mention "IPv6" and "IPv6 address privacy extensions". Is it the "IPv6 address privacy extensions" a subset of "IPv6"?, or is it the same set?.

IPv6 address privacy extensions make some machines change their IPv6 address regularly. (By default, once per day, with old addresses lasting one week). The rest of the tor network copes well with address changes at that rate. (See https://tools.ietf.org/html/rfc4941#section-3.5 .)

But if we make this change on bandwidth authorities, they will reset the bandwidth of relays that use IPv6 address privacy extensions, every day. Since sbws only measures the whole network once per day, any relay that uses IPv6 address privacy extensions won't get much consensus weight.

Yeah, this sounds like a problem.

If we don't make this change, then when relays change networks, sbws will take a few days to measure their new bandwidth. That's ok. Network changes happen a lot less often than IPv6 privacy extensions address changes.

Not sure what you mean by "network changes"

If sbws can ever scan the network once per hour, we could think about implementing this change.

What do you think, juga? Should we close this ticket?

Given my little knowledge about IPv6, you can probably have a better opinion here :)

comment:6 in reply to:  5 Changed 9 months ago by teor

Resolution: wontfix
Status: newclosed

Replying to juga:

Replying to teor:

Actually, I don't think we should make this change for IPv6, because it will penalise relays that use IPv6 address privacy extensions.

sorry, i'm not familiar with IPv6. You mention "IPv6" and "IPv6 address privacy extensions". Is it the "IPv6 address privacy extensions" a subset of "IPv6"?, or is it the same set?.

IPv6 is a way for relays to connect to each other, and clients to connect to relays, like IPv4.

Some relays have an IPv6 address, all relays have an IPv4 address.

Some IPv6 addresses use "IPv6 privacy extensions". IPv6 privacy extensions can make some relays change their IPv6 address every day, or every week.

IPv6 address privacy extensions make some machines change their IPv6 address regularly. (By default, once per day, with old addresses lasting one week). The rest of the tor network copes well with address changes at that rate. (See https://tools.ietf.org/html/rfc4941#section-3.5 .)

But if we make this change on bandwidth authorities, they will reset the bandwidth of relays that use IPv6 address privacy extensions, every day. Since sbws only measures the whole network once per day, any relay that uses IPv6 address privacy extensions won't get much consensus weight.

Yeah, this sounds like a problem.

If we don't make this change, then when relays change networks, sbws will take a few days to measure their new bandwidth. That's ok. Network changes happen a lot less often than IPv6 privacy extensions address changes.

Not sure what you mean by "network changes"

Relays moving from one network to another network.

If sbws can ever scan the network once per hour, we could think about implementing this change.

What do you think, juga? Should we close this ticket?

Given my little knowledge about IPv6, you can probably have a better opinion here :)

Ok, I'll close this ticket.

Note: See TracTickets for help on using tickets.