[tahoe-lafs-trac-stream] [Tahoe-LAFS] #867: use ipv6
Tahoe-LAFS
trac at tahoe-lafs.org
Wed Sep 14 19:08:05 UTC 2016
#867: use ipv6
-------------------------+-------------------------------------------------
Reporter: warner | Owner: ClashTheBunny
Type: | Status: assigned
enhancement |
Priority: major | Milestone: undecided
Component: code- | Version: 1.5.0
network | Keywords: ipv6 firewall twisted foolscap
Resolution: | test-needed
Launchpad Bug: |
-------------------------+-------------------------------------------------
Comment (by warner):
Good points. Twisted's endpoint language uses `tcp:` for IPv4-based TCP
ports, and `tcp6:` for IPv6-based ones.. they didn't add a `tcp4:` for
anything, which is a bit inconsistent, I guess. I kind of like the idea of
redefining `tub.port=`'s `tcp:` to mean both, but I wonder if it'd be
confusing, since then we can no longer claim it's exactly an Endpoint
string.
Oh also, maybe we should only do the dual-`tcp:`+`tcp6:` thing when we're
automatically setting up the listener (with `tahoe create-node
--hostname=ABC`). In other cases, let the user be explicit (which might
mean that the `--port=` argument to `tahoe create-node` needs to accept
multiple ports too.. maybe `tahoe create-node --port "tcp:1234 tcp6:1234"`
?).
Also also, endpoint strings can include paths (to TLS certificates, and
unix-domain sockets), and on a sufficiently ill-advised system, those
might include spaces. So maybe whitespace as a delimiter isn't such a
great idea after all.
I thought of another use case where you might want multiple listening
ports (listening on a public v4/v6 address *and* a Tor hidden-service's
locally-forwarded port), except that in that case I think we decided the
Tor/I2P listeners would be added independently, instead of being listen in
`tub.port`.
--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/867#comment:36>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage
More information about the tahoe-lafs-trac-stream
mailing list