Re: [tor-bugs] #4297 [BridgeDB]: Teach bridgedb how to handle descriptors with IPv6 addresses

["Tor Bug Tracker & Wiki" <torproject-admin@xxxxxxxxxxxxxx>]

#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 aagbsn):

 Replying to [comment:12 karsten]:
 > Replying to [comment:10 aagbsn]:
 > > 3. Make ipv6 addresses persistent in BridgeDB's database.
 > >   The one place where the Bridge address seems to matter is in
 Bucket.py. Presently BridgeDB does not store ipv6 addresses in its
 database; probably an oversight. One solution would be to add a new table
 in BridgeDB's database for or-addresses in order to accommodate variable-
 length or-addresses.Presently Bucket.dumpBridges() just writes an
 address:port on each line, and each line represents a single bridge.
 Bucket.dumpBridges() could be modified to write multiple lines per bridge.
 Will it be a problem that a single bridge may be represented by multiple
 lines without any indication that this is the case?
 >
 > Storing IPv6 addresses in the database probably makes sense.
 >
 > With respect to file buckets, hmm.  We don't use file buckets right now,
 do we?  That means we'll have to speculate how a hypothetical user would
 want the files to look like.  I could imagine that a single line per
 bridge with `"<ipv4 address:port>[ <ipv6 address:port>]*"` would be a
 useful format, but I'm not even a hypothetical user.  The single-line-per-
 bridge format also makes sense for #5482 where we're going to add
 stability and reachability information to file buckets, and those are per-
 bridge, too.  What does arma think about this all?

 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 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.
 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 )

 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

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4297#comment:13>
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