[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #4297 [BridgeDB]: Teach bridgedb how to handle descriptors with IPv6 addresses
#4297: Teach bridgedb how to handle descriptors with IPv6 addresses
-------------------------+--------------------------------------------------
Reporter: ln5 | Owner: aagbsn
Type: enhancement | Status: accepted
Priority: normal | Milestone:
Component: BridgeDB | Version:
Keywords: ipv6 | Parent: #4563
Points: | Actualpoints:
-------------------------+--------------------------------------------------
Comment(by karsten):
Replying to [comment:13 aagbsn]:
> What do we do with bridges that listen on multiple ports or multiple
addresses? (Or both?) Do you mean, they should be on a single line? Do we
want to give out all the listening addresses and ports to a single client?
Doesn't that circumvent the whole point of having multiple addresses and
ports per bridge?
We're talking about buckets here, right? That means we export bridges in
the unallocated ring to a file to be mailed to people distributing them
''somehow''. I don't know if these people would prefer a single line per
bridge with all addresses/ports or one line per address/port.
Note that the number of addresses/ports per bridge is limited. Proposal
186 says there can be at most additional 8 addresses times 16 ports.
Linus' implementation only allows for 1 additional address with 1 port,
AFAIK.
> We want to avoid a scenario where single bridge operator could represent
a majority of bridges by listening on a few thousand ports. For that
reason, BridgeDB does not treat each address:port as a bridge, but selects
a valid address:port from the bridge returned by the bridge distributor
(https, email). Perhaps we should do something similar here, and write a
single line per bridge, along with stability and reachability information.
Without knowing how bucket files will be used, I could imagine that
selecting 1 IPv4 and 1 IPv6 address per bridge would be sufficient for
most use cases.
> Unfortunately, that information could be different for each address and
the current implementation does not ensure that the same requesting (ip,
email) will get the same address:port (Hmm. #5948 )
So, staying in the bucket case, two subsequent runs shouldn't include
different addresses for the same bridge in the file. We could simply pick
the first address for any given IP version or transport.
> BridgeDB will also need a patch to support 'is blocked' status for each
valid address (or even address:port, as a compact representation or in a
database - 65535 ports * 4 bytes * 8 address lines could add up in a
hurry) #5949
I wouldn't worry too much about database size here. But you're right that
blocking information should be at bridge:address:port detail. If that
makes things too complex, BridgeDB could only look at the bridge or
bridge:address part.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4297#comment:14>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs