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

[Greg Troxel]

Randall Mason <clashthebunny at gmail.com> writes:

> A quick note about this:
>
>> Avoiding mess is always good.  What happens currently with 169.254.0.0/16
>> addresses in Tahoe?  What about RFC1918 addresses?  What about 127.0.0.0/8?
>> Are they deprioritized so that connections happen to them in the last case?
>> What is the delay if the connection times out?  Does Tahoe only connect in
>> serial, as apposed to starting to open up x different connections and take
>> the first one that connects?  Does Tahoe use the order of the address in the
>> furl?  What's the current algorithm for IPv4 addresses and the justification
>> for it?
>
> Looking at foolscap, it does start a connection to every single
> address in the furl and takes the first one that succeeds.  All the
> interesting stuff happens in negotiate.py:

So that means there is no sense of ordering, which is fine.  But I still
think that in the normal case (meaning that unless someone *specifically
asks for something different*), only globally-reachable addresses belong
in introducer furls.

I think the real point though, is that what we're talking about is
taking an address, putting it in a message as data, and sending it to
some remote system.  This happens two ways in tahoe: the introducer furl
is written to a file, and then carried to nodes out of band (relative to
tahoe).  Then, nodes connect to the introducer and send addresses *as
data* which sends them back *as data* to other nodes.

I'm making that "carriage as data" point because the bit that I'm having
trouble explaining is that it is incorrect to use a LL address
(including trying to connect) other than on the link where it belongs.
It's therefore incorrect to send a LL address to another node which is
not on the link, or to send it not bound to the identity of the link.
So one shouldn't put them in DNS, and one shouldn't register them with
remote services.

Getting this all right is a large effort:

  - when putting LL in introducer furls, ensuring that they are only
    sent to on-link nodes

  - handling scopeid translation (manually?) when they arrive

  - only sending LL addresses to an introducer when the connection to
    the introducer is via a LL address

  - having the introducer if it has more than one interface be sure not
    to send a LL address from one interface to another interface

  - doing all of this right for all operating systems

and it buys almost nothing, compared to telling people to set up IPv6 in
a non-degenerate way.  The presence of all that code is cognitive load
for anyone trying to understand things.

You mentioned trying things in parallel in foolscap.  I think it's wrong
to try things that shouldn't succeed, because it creates spurious system
calls and spurious packets for all users, on the off chance that it will
help some theoretical person with a degenerate network.  Part of
software development is curating standards of what ought to be, which
means not implementing things that no one should use.  I don't mean to
support field-of-use restrictions, but I mean things for which you can
in good conscience say "Unless you are really 1 in 100 million, I don't
really understand your world, but what you have described cannot
possibly be a good idea."

I still don't understand why you think there is any real benefit.
Looking back over all the time I have used v6, LL addresses have been
used in NDP, in RIPNG, and in on-link find-peers kinds of things.  I
have never seen them used in any protocol that intends to be beyond the
local link.  Everyone who runs it goes to the effort of getting global
addresses - that's the point.

If what you're trying to do is figure out a way to run grids in an
autoconfigured system, then I think that sounds like cjdns or ad hoc
routing, and there will be a layer that provides something that acts
like global (or regional/site-local) addresses.  But that's not really
about tahoe - that's a separate area of networking research.  Tahoe
already suffers from including too much (a separate backup protocol, not
using the vfs interface), and it's madness to have it include a
networking layer too.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20130218/fdf2d1b0/attachment.pgp>