id summary reporter owner description type status priority milestone component version resolution keywords cc 155 handle IPv6 Brian Warner "[http://tahoe-lafs.org/trac/tahoe-lafs/ticket/867 Tahoe#867] is about supporting IPv6 in a tahoe grid. For that to work, we need v6 support in Foolscap. This depends upon getting v6 support in Twisted (for which you should look at [http://twistedmatrix.com/trac/ticket/3014 Twisted#3014], still open as of august-2010). Thanks to Zooko's persuasion in #60, FURLs with v6 addresses are likely to be tolerated (i.e. ignored) by current versions of Foolscap (0.2.6 or later, so everything since may-2008). In particular, any connection hint with more than one colon is ignored. So backwards compatibility shouldn't be a problem. The FURL syntax for a v6 address would be {{{pb://TUBID@ipv6:[fe80::1%lo0]:12345/SWISS}}}, and the syntax for a v4+v6 FURL would be {{{pb://TUBID@127.0.0.1:12345,ipv6:[::1]:12345/SWISS}}} or {{{pb://TUBID@ipv4:127.0.0.1:12345,ipv6:[::1]:12345/SWISS}}} . The new parsing rules will have a legacy-ipv4 rule that matches hints with a single colon, so anything else will be in the form {{{TYPE:ADDRESS:PORT}}}. (future schemes that don't have two-part address+port identifiers, like Tor hidden services or #151 I2P endpoints will need an extra colon, like {{{i2p::I2PHASH.b32.i2p}}}, to avoid being confused with legacy {{{IPV4ADDR:PORT}}} pairs). Once the Twisted work is done, the foolscap-side work is a new parser in source:foolscap/referenceable.py ({{{decode_location_hints}}}) to spot the v6 addresses, then work in {{{negotiate.TubConnector}}} to stop ignoring non-ipv4 hints and call {{{reactor.connectTCP6}}} or whatever the new API is. We'll also need code to parse the {{{Tub.listenOn}}} strports spec to handle v6, and something for {{{setLocationAutomatically}}} to take a v6 hint and construct a FURL from it. " defect closed major 0.12.4 network 0.4.1 fixed Zooko clashthebunny@…