use ipv6

[warner]

Shawn Willden points out that IPv6 is a likely way to deal with the servers-behind-NAT problem (#169, #445, #49, #50), since a lot of ISPs offer v6 tunnel services these days, which effectively gives the server host a publically-reachable v6 address.

To make this work, we need a couple of things, probably in the following order:

• python must handle v6 addresses, in the socket module
• twisted must handle v6 addresses: connecting to them, reporting them when asking a socket who it is connected to, and enumerating them on listenable interfaces. The existing IPv4Address class must grow a corresponding IPv6Address partner.
• foolscap must handle them: putting them in connection hints (​foolscap#60 has some notes on formats), connecting to them, etc
• tahoe must handle them: formatting them into Welcome page listings, passing them through the Introducer without problems, logging them correctly

Let's collect pointers to other tickets (especially the twisted ones) and progress reports here.

[warner]

​twisted#3014 looks to be the main v6-in-Twisted ticket, and is moving very slowly (created two years ago). It looks like there's a bunch of v6 address lookup code already in place, but perhaps the actual make-a-TCP-connection code is not.

[warner]

​Foolscap#155 is the new v6-in-Foolscap ticket. Doesn't look too hard once the twisted ticket is done. That twisted ticket is still open, although I think there's been some good progress on it in the last month.

[davidsarah]

The relevant Twisted ticket now seems to be ​http://twistedmatrix.com/trac/ticket/5085, which is fixed.

[ClashTheBunny]

With progress by Marcus Wanner on ​Foolscap#155 I felt some motivation to work on IPv6 inside of Tahoe. Right now I've just done some of the ip_utils that are specific to IPv4 including some test cases that were missing. If my IPv6 work never makes it into Tahoe, my test cases would be useful to pull in.

You can follow my progress at and send pull requests to ​github. It's nothing much right now, but it's where I'm putting my work, so if anybody has anything to add, send it my way.

I asked on IRC and nobody else seems to be working on this, so let me know if you have something already done.

There may be some point to document a way to tunnel IPv4 over IPv6 until this work is done so that people can take advantage of IPv6 without the platform support within Tahoe. Something as simple as nc and some pipes.

[davidsarah]

Thanks! I don't think anyone else is working on this at the Tahoe end, so feel free to continue.

[davidsarah]

Screenshot from 2013-02-14

[davidsarah]

ClashTheBunny? wrote on tahoe-dev:

I've made some progress with IPv6. The first time a node is brought up it listens on both IPv4 and IPv6. I still have to figure out many side cases and test what is best when there is only IPv6, only IPv4, or both. It also needs to set the port correctly in the furl file after it is first run so that it listens to the correct protocol on the next runs. It's still communicating over IPv6!

Yay!

Re: the screenshot​, the "Connected?" column should probably show IPv6 addresses in the same format they appear in furls.

After these side cases are thought out, tests, tests, and more tests!

Excellent.

[ClashTheBunny]

How time flies. I've made some good progress on the IPv6 implementation and now need some good advice as to what to write new tests for. I could also use some code review. Everything implemented as far as I can tell:

• I've added a new boolean option "ipv6privacy" that will turn off all addresses that contain a MAC address
• The fe80::/10 addresses are silently dropped
• I've added a new boolean option "preferipv4" that will list address in an order that should prioritize IPv4 addresses when true. It will also listen on IPv4 interfaces only. I am pretty sure that this works, but it would be nice for some people to do some tests. I think this may need to be converted to a tri-state of ipversion = v4, ipversion = preferv4, and ipversion = preferv6. Suggestions welcome.
• IPv6 and IPv4 addresses are now listed in the "Connected?" column as they appear in FURLs.
• I detect if I'm listening on IPv6, and write my port file as an IPv6 port in that case. If IPv6 comes up the first time, may as well make it come up always. If it doesn't come up, you need to delete the port file and bring it up again.
• I've written a few tests, and updated others that needed updating, but as I said above, I would like some advice as to what else needs to be tested, and what should be assumed from foolscap's tests passing.

Things not complete that may be good to include in this:

• The webserver still is IPv4 only. It seems to be a larger update than this one because more of the low level stuff is done there and not handled by foolscap like here.
• I don't know exactly where logging of IP addresses happen, but I haven't seen any addresses logged yet. I've grepped around the code and didn't see anything, but a pointer to where this would happen would be nice.

Things required:

• foolscap from Marcus Wanner's ipv6 branch on github: git clone ​https://github.com/marcuswanner/foolscap -b ipv6
• Twisted 12.1
• My ipv6 Tahoe branch.
• IPv6 of course!

Remember, there are probably still bugs, so treat this as dangerous with data. I don't think I touched anything mission critical though, and all the old tests pass, so I wouldn't be too scared either.

[ClashTheBunny]

I converted preferv6 to a tri-state of ipversion = v4, ipversion = preferv4, and ipversion = preferv6. In a 7 node network with two nodes only reachable via IPv6, the upload succeeds on a "preferv4" host and a "preferv6" host, but fails on the "v4" host. So I know that v4 works as expected. I'm happy with the way preferv6 and preferv4 work. They advertise the right version first, but still work with either version.

I need to get some real testing done with Windows before 7 or another operating system that has a separate ipv4 stack from an ipv6 stack. If anybody is willing to try this, I would greatly appreciate it.

[gdt]

A few comments:

• the URL of your git repo/branch should probably be in this ticket
• Probably someone (you?) should file a separate ticket for making the WUI listen on ::1 (and presumably then the CLI interface could use that next, another ticket).
• whether a node is willing to use v4 vs v6 for outgoing connections should be separate from whether the node listens on v4 or v6 (foolscap)
• the concept of the port file seems a little off. nodes listen on an address/port pair, or rather a set of them. what port means now is "put this together with INADDR_ANY". But, it could be "put it with INADDR_ANY, and also with INADDR6_ANY". So probably the node config needs a config to list the address families on which to listen, defaulting to all OS-supported families. (For extra credit, test on a BSD system without INET in the kernel - I need to see if that still builds, and if not fix it.) I suggest "IncomingFamiles? = inet6, inet", being a set.
• for outgoing connections, the introducer furl, or data from the introducer, will have a list of addresses. I think it makes sense to 1) include a list of acceptable address families, defaulting to all OS-supported families and 2) have a way to express preference. For preference, I would start with v6, following the modern tradition. So I can see this being a "OutgoingFamilies? = inet6, inet" and it being a list rather than a set.

[ClashTheBunny]

Replying to gdt:

A few comments:

• the URL of your git repo/branch should probably be in this ticket

It's listed in my first comment, but it's here (for easier grep-ability): ​https://github.com/ClashTheBunny/tahoe-lafs/commits/ipv6

• Probably someone (you?) should file a separate ticket for making the WUI listen on ::1 (and presumably then the CLI interface could use that next, another ticket).

Yeah, I'm thinking that either we should make three tickets with this as the parent, or create two more tickets with those parts of the process. If we did three tickets, I would call mine "Tahoe-LAFS transport over IPv6" or something like that. I'll let zooko or David-Sarah figure that out, because they know more about the management of the project.

• whether a node is willing to use v4 vs v6 for outgoing connections should be separate from whether the node listens on v4 or v6 (foolscap)

Agreed. I'll look into how that works in foolscap. The problem is that there aren't many controls that I have. Right now I can specify which addresses are advertised and in which order. I can also specify if the listen port is TCPv4 or TCPv6. I don't think I can tell foolscap not to make connections to a certain address family, but as I said, I'll look into that.

• the concept of the port file seems a little off. nodes listen on an address/port pair, or rather a set of them. what port means now is "put this together with INADDR_ANY". But, it could be "put it with INADDR_ANY, and also with INADDR6_ANY". So probably the node config needs a config to list the address families on which to listen, defaulting to all OS-supported families. (For extra credit, test on a BSD system without INET in the kernel - I need to see if that still builds, and if not fix it.) I suggest "IncomingFamiles? = inet6, inet", being a set.

I don't know if the first case exists. I think I can specify INADDR_ANY and INADDR6_ANY. Linux automatically makes INADDR6_ANY also receive IPv4 connections if /proc/sys/net/ipv6/bindv6only is set to the default value of 0. In NetBSD I think this would be sysctl -w net.inet6.ip6.v6only=0. This INADDR_ANY and INADDR6_ANY translate to this in a tub entry:

0 or tcp:0 is any free port the OS will give us on only INADDR_ANY tcp6:0 is any free port the OS will give us on INADDR6_ANY, if your OS listens on INADDR6_ANY for INADDR_ANY connections also, you get both. This is Linux's default, I think every BSD, and I've heard that Windows 7 also, but Windows XP/Vista have seperate V6 and V4 stacks, so it only listens on INADDR6_ANY.

<any number> or tcp:<any number> listens on INADDR_ANY on that specific port tcp6:<any number> listens on INADDR6_ANY on that specific port, with the above caveats about stacks and listening on both.

Either way, I'll set up bindv6only on a test machine I'm running to make sure that the expected behavior works (or that ipv4 connections don't work!).

• for outgoing connections, the introducer furl, or data from the introducer, will have a list of addresses. I think it makes sense to 1) include a list of acceptable address families, defaulting to all OS-supported families and 2) have a way to express preference. For preference, I would start with v6, following the modern tradition. So I can see this being a "OutgoingFamilies? = inet6, inet" and it being a list rather than a set.

This is essentially what I did with ipversion above. I don't know if there is a real way of asking foolscap to actually prefer one over the other, but I do know that if I list IPv6 addresses at the end of the list of addresses advertised to the introducer, I, more often than not, get IPv6 connections. The opposite is also true, if I list them first, I rarely get IPv6 connections. If you look at the code that includes ipversion it's kinda a combination of these last two comments. I now understand that they can be split into two variables:

IncomingFamily? = inet or inet6, implementation details would then state that, depending on your OS and settings this will give you v4, v6, or both.

and PreferredOutgoingFamily? would do the previous reordering of addresses when advertising to the introducer my addresses.

I don't think I can tell the introducer that I support one type of address or another, but that would have to happen in foolscap. Also, it would be nice to file a bug against foolscap to have a true preference of family be possible. The bug tracker is currently down, so I keep making comments on Marcus Wanner's latest commit to his ipv6 branch of foolscap on github (​https://github.com/marcuswanner/foolscap/commit/d890c7739008103ebdd2ecdb5dab971ef9cee484). Right now I'm going to split my tri-state variable 'ipversion' into the two you suggested. We'll hope that foolscap is able to either be fixed or keeps it current behavior. I'll also make a comment in the code about how it works for me but there is no official way of doing this yet.

[ClashTheBunny]

Greg Troxel helped me understand some things about dual stack vs split stack v4/v6 implementations, it should now work in both cases. The configuration options are now outgoingfamily as either preferv6 or preferv4 and incomingfamily as inet, inet6, or both.

I still don't think that I can stop foolscap from connecting to IPv6 addresses that are advertised to it if I have IPv6 connectivity to that node. Outgoingfamily still chooses to advertise IPv6 addresses first or last based off of my experience with foolscap, but it still doesn't prevent connections over IPv6 or IPv4.

I just pushed these changes to github, so keep testing away everyone!

[gdt]

I forgot about foolscap's try-them-all-first-one-wins plan. Given that, I don't think it makes sense to fight the foolscap way. The usual reasons to try v6 first are to promote v6 adoption and to avoid NAT pain. The reasons to configure v4 first instead are because v6 is flaky or slow (due to infrastructure/routing, not protocol).

Longer term, foolscap should become aware of AF preference and support that somehow.

[davidsarah]

Given foolscap's try-them-all-first-one-wins behaviour, is there any real need for the preferv4 option? If the required v6 connectivity isn't available, then the attempted v6 connections should fail quickly (or am I wrong about that?) So the only reason to use preferv4 would be if the v6 connections can succeed but are not reliable in some way. But, in that case it would still be possible for a v6 connection to be made if preferv4 is set, and so setting that wouldn't solve the unreliability.

[gdt]

In a multi-AF world, foolscap not having a "only use this AF" runtime config is at least a misfeature if not a bug. But until foolscap gets that, I don't see the point in sorting.

[ClashTheBunny]

Updated branch to include tests for IPv6 in client tests and introducer tests.

Added option to include fe80::/10 addresses but is off by default and should not be documented. In the future, it will allow more flexibility with fewer changes. If somebody really wants an fe80 address to show up, they can read the source code and enable the option.

An option for end to end testing would be to turn off IPv4 in all of the regular tests. This would allow all of the other tests to be tested over IPv6, thereby testing IPv6.

All my new tests pass, including the tests that I added for IPv4 addresses.

[davidsarah]

Replying to ClashTheBunny:

Added option to include fe80::/10 addresses but is off by default and should not be documented. In the future, it will allow more flexibility with fewer changes. If somebody really wants an fe80 address to show up, they can read the source code and enable the option.

I think we prefer all options to be documented.

[gdt]

Replying to davidsarah:

Replying to ClashTheBunny:

Added option to include fe80::/10 addresses but is off by default and should not be documented. In the future, it will allow more flexibility with fewer changes. If somebody really wants an fe80 address to show up, they can read the source code and enable the option.

I think we prefer all options to be documented.

I think the point here is that including fe80::/10 is basically broken but there are perhaps reasons why someone would want to experiment. I think clashthebunny is talking about a variable to set in the sources, not command-line support. I would say that if there's a requirement to expose this in command-line and docs, then the option shouldn't exist. I haven't seen a valid use-case for it yet.

[T_X]

Seems like the ticket regarding IPv6 support in Twisted got closed 10 months ago:

​https://twistedmatrix.com/trac/ticket/3014

Does anyone know what else might still be missing? (and could update the ticket description with that?)

[warner]

The main remaining issue is that Foolscap needs to support it: ​http://foolscap.lothar.com/trac/ticket/155

The last time I looked at this, Foolscap was blocked on a different Twisted bug (​twisted#8014), which is preventing us from using a HostnameEndpoint to connect. We really want to use HostnameEndpoint because they handle A or AAAA records in DNS, so you can publish a normal hostname in your FURL and have clients connect over whichever of v4/v6 both ends support.

The consequence is that the process emits unhandled AlreadyCalledError failures when there are multiple connection hints and some of them don't answer right away. This happens all the time with automatically-generated FURLs, since they include non-routable (local) addresses and other unconnectable things. The errors cause Foolscap's unit tests to fail, and would show up as errors in the logs for a real application (probably causing Tahoe's unit tests to fail too, although maybe there we can constraint the FURLs to not hit this case).

I haven't seen any movement on that ticket since I filed it 5 months ago, but it's possible that other changes in Twisted may have fixed the problem. The next step will be to re-introduce the HostnameEndpoint change and see if the Foolscap tests pass or fail with the latest version of Twisted.

There are probably some other cosmetic things that need updating: we need to make sure the FURL parser can handle dotted-quad IP addresses, and Tahoe has a handful of places that want to display IP addresses that may need changes.

[dawuud]

Now that the Tahoe-LAFS server side supports endpoints and we have transport handlers for the client side it should be easy to get IPv6 working. I think the simplest possible solution would be:

• write a IPv6 handler (client side) which uses TCP6ClientEndpoint

• configure the node's tub.port= to be set to an endpoint string which uses TCP6ServerEndpoint

[warner]

I've updated ​foolscap#155 with notes about the new DefaultTCP parser plan. Twisted's HostnameEndpoint works now, and current Foolscap uses it by default. So the following should work right now:

• tub.port = tcp6:12345
• tub.location = tcp:HOSTNAME:12345 (where HOSTNAME has a valid AAAA record)

When ​foolscap#155 is done, the following should work too:

• tub.port = tcp6:12345
• tub.location = tcp:[2600:3c01::f03c:91ff:fe93:d272]:12345

We're not planning to enhance the (legacy) automatic-IP-address detection routine to include IPv6 addresses, since we've deprecated that in favor of human-provided hostnames. So I think once the foolscap ticket is closed and a new release made, (and any cosmetic status displays fixed), we can declare our ipv6 support as complete and close this ticket.

[lpirl]

Sorry for me not being sure about all the consequences of this: Does this mean foolscap can then – given IPv6 is configured properly – overcome NAT barriers? Thanks for any clarifying comments.

[warner]

Only if the machine has a publically-reachable IPv6 address. I suspect most home computers that have v6 addresses will still be blocked by a firewall of some sort. So unfortunately, no, I don't think enabling IPv6 will significantly help with the NAT barrier.

[lpirl]

Alright, thanks. So with full administrative control, it should be possible. At least – let's see!

[warner]

​foolscap#155 is done. I plan to make a new Foolscap release in the next couple of days (either named 0.12.4 or 0.13.0): once that's out, we can close this ticket.

[warner]

Oh, actually, this might need more work. I'm doing some manual testing, and it looks like our default behavior of listening on tcp:PORT only makes an IPv4 listening socket. I tried connecting to that (on a host with both IPv4 and IPv6 addresses bound to en0) with nc -6 IPV6ADDR PORT and it wouldn't connect. If I listen on tcp6:PORT then nc -6 works but nc -4 doesn't.

I think we might need to listen on both tcp:PORT and tcp6:PORT to allow A+AAAA hosts to accept both v4 and v6 connections.

If so, we need tahoe.cfg's tub.port= to accept multiple ports (or second-guess the user and automatically add tcp6: every time we see tcp:, which feels a bit wrong). We either need a delimiter (whitespace? comma?) or to accept multiple config keys (like tub.1.port= and tub.2.port= or something). And we need the default create-node behavior to produce both kinds.

And we need to see what happens if you try to listen on tcp6:1234 on a box that doesn't have IPv6 support: either catch+ignore the error, or test ahead of time and avoid it.

[warner]

I bet we should avoid using commas as delimiters in the tub.port= string. I can't find any existing Endpoints that use commas internally, but I wouldn't be surprised if some endpoint author down the line decides to use them, and then we'll have some parsing confusion. Whitespace seems like a better option right now.

[lpirl]

Replying to warner:

If so, we need tahoe.cfg's tub.port= to accept multiple ports (or second-guess the user and automatically add tcp6: every time we see tcp:, which feels a bit wrong). We either need a delimiter (whitespace? comma?) or to accept multiple config keys (like tub.1.port= and tub.2.port= or something). And we need the default create-node behavior to produce both kinds.

Although I am not sure to what extend we're willing to change the semantics of the config file but it's an option to rename tcp: to tcp4:, introduce tcp6: and use tcp: for trying IPv4 and IPv6. IMHO, most people probably don't care with which IP version data is carried. For those who do, there is the flexibility to configure it.

And we need to see what happens if you try to listen on tcp6:1234 on a box that doesn't have IPv6 support: either catch+ignore the error, or test ahead of time and avoid it.

Well, staying with the semantics above, tcp: (or any other auto-detected thing) could fail silently if at least one IP version works. Explicit configurations should fail loudly.

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

[lpirl]

Replying to 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.

I see, interesting. I can't judge on this. 0.02: Does it actually matter to have proper Endpoints (as a user: never cared)? Do Tahoe users ever come in direct contact with Twisted (as a user: don't want to)? But your point is definitely to consider and maybe a show stopper for tcp4:.

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

Yes, IMHO the automatic mode should always be default unless explicitly configured otherwise. tahoe create-node --port … could use the same delimiter as tub.port for consistency.

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.

Speaking of file system paths (mind Windows), there are not much delimiters we can use while maintaining full compatibility with all possible paths. It's probably inevitable to choose "just any".

[warner]

Replying to lpirl:

Does it actually matter to have proper Endpoints (as a user: never cared)? Do Tahoe users ever come in direct contact with Twisted (as a user: don't want to)? But your point is definitely to consider and maybe a show stopper for tcp4:.

Well, it's nice to be able to say "for more complex situations, read the Twisted endpoint docs, because --port is really just an endpoint string", and delegate all that documentation job to the Twisted folks.

Yes, IMHO the automatic mode should always be default unless explicitly configured otherwise. tahoe create-node --port … could use the same delimiter as tub.port for consistency.

Yeah. Ok, so I think we can say that --listen=tcp (which is the default) will mean "listen on both v4 and v6, whichever is available", and it can cause multiple endpoint strings to get written into tahoe.cfg.

Speaking of file system paths (mind Windows), there are not much delimiters we can use while maintaining full compatibility with all possible paths. It's probably inevitable to choose "just any".

Good point. We'll just document that some unusual endpoint strings won't work, if their internal characters are mistaken as tub.port delimiters.

[dawuud]

comma separated endpoint descriptor strings in tub.port; pull-request for your review ​https://github.com/tahoe-lafs/tahoe-lafs/pull/348

[warner]

looks good, I'll land it in a minute.

Still to do for this ticket:

• tahoe create-node --hostname= should detect if v6 is available, then write out a tub.port = with both tcp:PORT and tcp6:PORT. Or maybe we don't need to detect anything first? We must make sure the node won't crash at startup if v6 is not available, which means we need a host without v6 support to learn what sort of exception might get raised.
• Add something to the docs about v6, explaining A/AAAA DNS records, bracketed IPv6 address hints, and warning that the endpoints in tub.port cannot include commas (because we stole them for delimiters between multiple endpoints)
• wait for a foolscap release (with the bracketed-v6 parser) and bump the tahoe dependency to require it

[Brian Warner <warner@…>]

In b00c2d2/trunk:

test tub.port with multiple endpoints, add docs

I think the preferred way to listen on both IPv4 and IPv6 will be to use
"--port=tcp:PORT,tcp6:PORT". This is now reflected in the docs.

refs ticket:867

[dawuud]

I was testing out the IPv4 + IPv6 on a couple of servers... running an introducer + storage node on one and another storage node on the other. I noticed that it dOES NOT work to specify the following:

tub.port=tcp6:3456,tcp:3456

However it works fine if i specify the interfaces in both endpoint descriptor strings like so:

tub.port = tcp6:interface=2600\:3c01\:f03c\:91ff\:fe93\:d272:3456,tcp:interface=8.8.8.8:3456

2016-09-21T12:48:40+0000 [twisted.internet.defer#critical] Unhandled error in Deferred:

Traceback (most recent call last):
  File "/home/human/foolscap/src/foolscap/pb.py", line 537, in startService
    service.MultiService.startService(self)
  File "/home/human/virtenv-tahoe/local/lib/python2.7/site-packages/twisted/application/service.py", line 283, in startService
    service.startService()
  File "/home/human/foolscap/src/foolscap/pb.py", line 53, in startService
    d = self._ep.listen(self)
  File "/home/human/virtenv-tahoe/local/lib/python2.7/site-packages/twisted/internet/endpoints.py", line 470, in listen
    interface=self._interface)
--- <exception caught here> ---
  File "/home/human/virtenv-tahoe/local/lib/python2.7/site-packages/twisted/internet/defer.py", line 120, in execute
    result = callable(*args, **kw)
  File "/home/human/virtenv-tahoe/local/lib/python2.7/site-packages/twisted/internet/posixbase.py", line 478, in listenTCP
    p.startListening()
  File "/home/human/virtenv-tahoe/local/lib/python2.7/site-packages/twisted/internet/tcp.py", line 983, in startListening
    raise CannotListenError(self.interface, self.port, le)
twisted.internet.error.CannotListenError: Couldn't listen on any:3456: [Errno 98] Address already in use.
2016-09-21T12:48:40+0000 [-] Listener starting on 44617
2016-09-21T12:48:40+0000 [foolscap.pb.Listener#info] Starting factory <Listener at 0x7fd04ff73d90 on <twisted.internet.endpoints.TCP4ServerEndpoint object at 0x7fd04ff73dd0> with tub yi45keoq72z3ce3jrug2wxxwy4f6rc2l>
2016-09-21T12:48:40+0000 [-] Listener starting on 57245
2016-09-21T12:48:40+0000 [foolscap.pb.Listener#info] Starting factory <Listener at 0x7fd04ff73ed0 on <twisted.internet.endpoints.TCP4ServerEndpoint object at 0x7fd04ff73f10> with tub u4ppdne5ehcwacdz3ccivfm3usotpxgj>
2016-09-21T12:48:40+0000 [-] client running

i've posted a PR to fix the configuration docs here: ​https://github.com/tahoe-lafs/tahoe-lafs/pull/352

[exarkun]

IPv6 essentially works in Tahoe-LAFS now, as of dawuud's 2016 changes. There are some remaining usability nits but they don't block any actual functionality.

Also, I had to read 40+ comments on this ticket to figure that out.

So I'm closing this as fixed. If someone is concerned with the usability nits, they can file new tickets for them.

One ticket, one feature, one PR, one master merge, please. ;)