Undernet IPv6 Interop [was: Enigmabox/cjdns]
On Tue, Oct 22, 2013 at 4:51 AM, Eugen Leitl <eugen@leitl.org> wrote:
Just got word, Enigmabox has published source and put up first documentation on http://wiki.enigmabox.net/
This is cjdns. Last I checked (and will again) I'm pretty sure they were using an IPv6 address scheme that would conflict with other projects using proper private space. So if say you wanted 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] 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 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.
On Tue, Oct 22, 2013 at 05:23:45AM -0400, grarpamp wrote:
On Tue, Oct 22, 2013 at 4:51 AM, Eugen Leitl <eugen@leitl.org> wrote:
Just got word, Enigmabox has published source and put up first documentation on http://wiki.enigmabox.net/
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.
cjdns interoperates fine with dual-stack. The interesting part is L2 routing over own infrastructure, and eventual ASIC/FPGAfication of the router.
[1] Click on a link to 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.
On Tue, Oct 22, 2013 at 5:55 AM, Eugen Leitl <eugen@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.
participants (2)
-
Eugen Leitl -
grarpamp