[tahoe-lafs-trac-stream] [tahoe-lafs] #867: use ipv6

[tahoe-lafs]

#867: use ipv6
-------------------------+-------------------------------------------------
     Reporter:  warner   |      Owner:  ClashTheBunny
         Type:           |     Status:  assigned
  enhancement            |  Milestone:  undecided
     Priority:  major    |    Version:  1.5.0
    Component:  code-    |   Keywords:  ipv6 firewall twisted foolscap
  network                |  test-needed
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by ClashTheBunny):

 Replying to [comment:14 gdt]:
 > A few comments:
 >  * the URL of your git repo/branch should probably be in this ticket

 It's listed in my [comment:6 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.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/867#comment:15>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage