Undernet IPv6 Interop [was: Enigmabox/cjdns]

[grarpamp]

On Tue, Oct 22, 2013 at 5:55 AM, Eugen Leitl <eugen at leitl.org> wrote:
> On Tue, Oct 22, 2013 at 05:23:45AM -0400, grarpamp wrote:
>> This is cjdns. Last I checked (and will again) I'm pretty sure they
>
> Yes. If people are not familiar with cjdns, here's a good
> intro https://github.com/cjdelisle/cjdns/blob/master/doc/Whitepaper.md
>
>> were using an IPv6 address scheme that would conflict with
>> other projects using proper private space. So if say you wanted
>
> I've asked about this a while back among a few IPv6 people,
> and it does not seem to be a problem. The keys/addresses are
> randomly generated and are all in FC00::/8.
>
>> to run an interface for each project and run/access/route
>> them all at once, you can't. Yes, less than 128bits
>> (say a /48) is pretty weak... but when you can't interoperate [1]
>
> 120 bits is a lot of space.
>
>> that leaves something to be said for each project to develop an
>> address layer so you can. There certainly won't ever be more
>> than 2^48 projects or 2^80 users.
>>
>> The undernets are getting bigger and having more projects.
>> They might want to be thinking about interop beforehand.
>> Otherwise, even though the tech under the hood might
>> be different, to the user they will appear as bunch of balkanized
>> communities, and a real pain to use any of them in parallel.
>
>> [1] Click on a link to a service on any net from a page on any net
>> and let your host do the routing to get you there. Where any
>> net = i2p/tor/freenet/phantom/cjdns/anonet/gnunet/etc.
>> At least four of these do have some IPv6 route capability,
>> but I thnk only a couple work together reasonably well.


Special-Purpose IP Address Registries
 https://tools.ietf.org/html/rfc6890
Unique Local IPv6 Unicast Addresses
 https://tools.ietf.org/html/rfc4193

FC00::/7 ------->||<----- L (locally allocated) bit
FC00::/8 1111 110.0 klmn opqr : ---- ---- ---- ---- : ---- ---- ---- ---- /48
FD00::/8 1111 110.1 stuv wxyz : ---- ---- ---- ---- : ---- ---- ---- ---- /48
                    |<---------- 40 RFC generated bits in here -------->|

The 8th MSB of the address has meaning per the RFC.

FC00::/7 - The whole of this block is reserved for [high probability]
unique local unicast addressing under some IETF guidance.

FC00::/8 - This is more or less effectively on hold pending the
outcome of its 'centrally allocated' discussion. So long as you
don't mind whatever the IETF may decide, there isn't much problem
using this block today since the local-ness of it is not in question.
Though using it in absense of further guidance can indeed cause
interop problems... see further below.

FD00::/8 - Allows you to generate your own /48's within it today.
Realworld networks don't allocate or use IPv6 addresses as crypto
identifiers like we do, so this block (mod /48) works for them.
And it works for us if we design ways to use the resulting 80 bits.

 Note: this block has apparently resulted in at least one informal
 self regulated registration body so as to prevent the unlikely
 event of a collision within 48 bits:
  https://www.sixxs.net/tools/grh/ula/
 (Before using their generator scripts, be sure they conform to
 RFC. You want people to be able to validate your Global ID process
 by pointing them to the RFC and your documented input data [faked
 MAC/timestamp as needed]).


With those clearnet things covered... crypto identifier interop and
routing is our own special use case to think about. When it comes
to routing the tunnel interfaces of multiple crypto nets on your
box... one crypto net (eg: CJDNS) blindly using all of FC00::/8
because they think they can get a fat 120 bits out of it *will*
conflict with other crypto nets that think and do the same thing.
And you can't route around it. That's the general problem here.

I have yet to time CJDNS's address generation speed and would welcome
someone to post some. Why? Because if generating into FC00::/8 is
quick enough now, crypto nets generating into FC00::/8 plus up to
an extra 4 fixed network bits [the aggregable 'klmn' above] would
still be tolerable at the up to 16x the current wall clock it takes.
The 'klmn' bits would then be cooperatively doled out to up to 16
crypto projects that maintain working code and are ready to begin
running a public instance. Need room for 32 projects, then lock
down 'klmno', etc. Be sure to make that choice beforehand to prevent
internal redesigns and flag days. 32 seems plenty to track whatever
the state of the art in crypto networks is.

If waiting on IETF for some formal extra bits scheme in FC00::/8
beyond today's FD00::/8 48's is a problem, and you want up to say
116 bits instead of 80... cooperate to 'self register' an 'stuv'
[above] worth of aggregable FD00::/8 (mod /48)'s and dole them out
similarly.

[Aggregable space makes it easy to prevent leaking packets onto
clearnet from any/all of the projects with one filter rule.]

Another way is to allocate your own single FD00::/8 (mod /48) block
and use those 80 bits like CJDNS is constrained to use 120 bits.

 If your internal native address space slides up beyond 80, but not
 more than 120, so does your generating time to match within that
 fixed /48... to the point that it could take more than a few days
 on reasonable hardware to perhaps even yield a match beyond 93.

 If your internal native address space is larger than the already
 non-interoperable yet reasonably IETF compliant limit of 120, say
 128/256/512... then you'd want to develop your own internal
 database/DHT address mapping registry/layer between that and your
 native wide addresses. This works for arbitrary widths from 81 to
 120.

To get about 5 more bits, you can further ignore IETF, pick some
unused /3 from here, and then use a method above. Be prepared to
flag day into another range if IANA allocates the one you picked.
 https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml


Decent case, even without any of the above tricks, is that every
crypto net can still have 80 bits worth of users and native spoofing
resistance. That's quite a bit. And users can still develop in-network
service CA/certs and application level protection like https/SSH
passwords on top of things if more is needed. (SHA1 certs are 160
bit).

Best case, you generate / truncate / map internal space as needed
to get up to and beyond the roughly 115 to 120 interoperable bits
reasonably available with IPv6 space.

Today there are at least 5 different crypto networks that can use
tunnel interfaces. A lot of people would like to test/run/browse/serve
on more than one at once, as well as run their VPN's and regular
internet connections. Designing in IPv6 tunnel interfaces will make
that much easier, to the point that it could [should, will] be a
standard expectation for all crypto networks. And without giving
some thought to interoperation, you'll balkanize these communities
before they start... instead of building a strong and inclusive
ecosystem among them all. As a bonus, you can use all the IPv6
applications that exist today over these tunnels. That's a very
powerful draw. And it frees up developer time to focus on the network
itself instead of also on its shims, addons, howto's, etc.

Worst case, you skip this seamless interop and instead develop with
socks5, library hooks and transparent proxies. That limits applications
and gets very complicated and delicate when running more than one
network.