[tahoe-dev] [tahoe-lafs] #867: use ipv6

[Randall Mason]

On Feb 14, 2013 2:26 PM, "Greg Troxel" <gdt at ir.bbn.com> wrote:
>
>
> Randall Mason <clashthebunny at gmail.com> writes:
>
> > 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!
>
> It's great to see v6 progress.
>
> Are you talking about the WUI on http://127.0.0.1:3456/?  It makes sense
> to have that listen on ::1 as well.  But to me this is not that
> important, compared to the transport protocol, because hosts without
> INET in the kernel are very rare, whereas hosts without global v4
> reachability are very common.

This is exactly my priority.  Transport then WUI and sshfs.  Right now,
transport is working with IPv6 due to the awesome architecture of using
foolscap on top of twisted.  The WUI on the other hand is not associated
with foolscap and will be a totally sepearate change and require lot's of
changes because 127.0.0.1 being all over the WUI and command line.  Like
you said, only FreeBSD at this point I think allows you to compile out INET
from the kernel, so this is not a high priority.  I need this to work on v4
only hosts (like most Android phones) and on dual stack hosts to increase
connectivity.

>
> For the introducer, it seems to put all (global?) v4 addresses in the
> furl at creation.  It seems it should also put all global v6 addresses
> (omitting fe80::).   If an address is not present on the machine at
> boot, I don't see any reason to handle the situation differently v4 vs
> v6 (perhaps it should be an error, or not, but it's not really about 4/6).

I actually am leaving all addresses.  The fe80:: addresses are useful to
communicate over a local medium.  Picture the situation where you have two
hosts with external addresses at 1.1.1.1 and 1.1.1.2.  You can connect both
to a tunnel broker and have totally different IPv6 networks for them and
end up sending all your traffic over the tunnel.  If you try the ::1, then
fe80::, then the global address, you try in order of connectivity.  If you
end up with connectivity on a shorter path, that's much better.  ::1 will
be even faster than fe80.

>
> I would think that one could edit the introducer furl to add/remove
> addresses, if one wanted a v6-only node or a v4-only node, or just to
> omit some addresses.

This is what I did to make sure that v6 connectivity works.  I just edited
out 127.0.0.1 and my wlan0 v4 address to get only IPv6 connectivity
tested.  The clients actually connected automatically to v6 addresses, and
I don't know if that's chance or what, but I was so happy to see 10 nodes
and an introducer on v6!

>
> For storage and client nodes, it seems they should just try the
> addresses in the introducer furl in order until one works, not worrying
> about local addresses.

Yea, like I said, I don't know what it does, but I do agree that an order
would be a good idea.  I may have to do a good job of sorting addresses as:
v6 from most "local" to most "remote" then v4 from most local to remote.
The other option would be to prefer local over remote and then prefer IPv6
over IPv4.

ipv6:[::1],ipv6:[fe80::],ipv6:[2001::],ipv4:127.0.0.1,ipv4:169.254.x.x,ipv4:192.168.1.1,ipv4:1.1.1.1

or

ipv6:[::1],ipv4:127.0.0.1,ipv6:[fe80::],ipv4:169.254.x.x,ipv4:192.168.1.1,ipv6:[2001::],ipv4:1.1.1.1

I have a feeling of where I would do this, but I still need to think about
what way I'm going to do it.  I think the second way is the way I would
lean towards right now.

>
> The next question is which of the nodes global addreses should be passed
> to the introducer to be advertised.   It would seem that the default
> should be all global addresses, and a config option could limit
> addressfamily (like in ssh).   At some point it would be good to have
> an option to omit RFC1918 addresses, and perhaps to default to omitting
> them.

Yeah, this one is a toughie.  Right now it yanks out all addresses (as it
did with IPv4).  Like I said above, that is a good situation most of the
time.  The problem becomes that IPv6 addresses often have the MAC address
in the address for two addresses, the fe80 address and the
autoconfiguration address.  There needs to be an option to filter out all
addresses that contain the non-private v6 addresses, A.K.A. anything that
has the mac address in it.  The easiest place to do this would be when I'm
getting the IP addresses in iputil.py, but then I have to pass the
configuration paramater like 16 levels deep of function calls to get to the
place where I have both the MAC address and the IP addresses.  This is what
I think I'll do, but it's just tough.  I personally prefer not using the
privacy address because I like being able to always access my machine at
the same address in DNS and I use a firewall on all my hosts.  But if I
were a political dissident who is also a religious and racial minority with
a non standard sexual orientation in a country that doesn't really
celebrate any of those things, I can understand not wanting people coming
to my door and killing me with sticks because I used Randall Mason's Tahoe
IPv6 implementation!  I don't value privacy really for myself, but I am a
strong proponent of being able to choose your own level privacy.

>
> I'm not sure what order you are working on things, but in my view nodes
> being able to register a v6 address with the introducer (and connect to
> such addresses) is the most important thing, because it lets v6 nodes
> operate in a grid given a single v4-reachable introducer.

I think this is the case, but it is a really good test case.  The
introducer always just passes around the full furl of the host, so it's
going to pass the v6 addresses automatically.  I still need to add the ipv4
addresses in the old format (without the ipv4: in front) for backward
compatibility though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20130215/fe3a70da/attachment-0001.html>